Глава 6. ndbmemcache: Memcache API для NDB Cluster

Эта секция предоставляет информацию о Memcache API для NDB Cluster, доступном с NDB 7.2.2, который позволяет получить доступ к данным NDB Cluster, используя протокол memcache.

6.1. Обзор

Memcached распределенный сервер кэширования в памяти, используя основанный на простом тексте протокол, обычно используемый для хранилищ данных значения ключа, с клиентами, доступными для многих платформ и языков программирования. Новый выпуск сервера memcached доступен на memcached.org.

Memcache API для NDB Cluster доступно с NDB 7.2.2. Этот API осуществляется как загружаемый механизм хранения для memcached версии 1.6 и позже, который использует архитектуру механизма хранения. Этот API может использоваться, чтобы обеспечить постоянное хранилище данных NDB Cluster, которое является доступным с использованием протокола кэш-памяти. Для сервера memcached также возможно обеспечить строго определенный интерфейс к существующему NDB Cluster, строя таблицы таким образом, что администратор может точно управлять тем, на какие таблицы и колонки ссылаются конкретные ключи кэш-памяти и значения, и какие операции позволены на этих ключах и значениях.

Стандартное кэширование memcached включено в дистрибутив NDB Cluster. Каждый сервер кэш-памяти, в дополнение к обеспечению прямого доступа к данным в NDB Cluster, в состоянии кэшировать данные в местном масштабе и служит (немного) запросам от этого местного кэша. Как с отображениями таблицы и колонки, политика кэша конфигурируема на основе префикса ключа кэш-памяти.

6.2. Компиляция NDB Cluster с поддержкой Memcache

Поддержка Memcache API строится автоматически, используя исходные тексты memcached и libevent, включенные в NDB Cluster, собирая NDB 7.2.3 или позже из исходного текста. По умолчанию make install устанавливает memcached в подкаталог bin каталога установки NDB Cluster и файл общего объекта ndb_engine.so в подкаталог lib.

Можно отключить использование связанного memcached, строя ndbmemcache при помощи опции -DWITH_BUNDLED_MEMCACHED=OFF, можно вместо этого использовать сервер memcached собственной системы и источники, установленные в path, при помощи опций -DWITH_BUNDLED_MEMCACHED=OFF и -DMEMCACHED_HOME= path. Можно также заставить использоваться версию системы libevent, а не версию из NDB Cluster при помощи опции -DWITH_BUNDLED_LIBEVENT=OFF.

Для получения дополнительной информации о вариантах CMake, касающихся ndbmemcache, см. Options for Compiling NDB Cluster.

Для получения общей информации о сборке NDB Cluster см. Building NDB Cluster from Source on Linux и Compiling and Installing NDB Cluster from Source on Windows. Для получения информации о сборке MySQL Server см. Installing MySQL from Source, а также MySQL Source-Configuration Options.

6.3. Опции командной строки memcached

Следующий список содержит опции командной строки memcached, которые особенно интересны, работая с ndbmemcache.

Для получения общей информации о параметрах командной строки memcached см. документацию http://code.google.com/p/memcached/wiki/NewStart.

6.4. Конфигурация механизма NDB

Опции настройки NDB memcache. Механизм NDB поддерживает следующие параметры конфигурации для использования с memcache -e (см. раздел 6.3):

Начальная конфигурация. Когда механизм NDB запускается, его самые важные параметры командной строки это строка подключения и роль сервера. Строка подключения используется, чтобы соединиться с конкретным кластером, названным основным, который содержит схему конфигурации. Таблицы в схеме конфигурации прочитаны, чтобы восстановить ряд отображений ключевого префикса для данной роли сервера. Эти отображения инструктируют сервер, как ответить на операции по кэш-памяти на конкретных ключах на основе крайней левой части ключа. Например, они могут определить, что данные хранятся в колонках определенной таблицы. Эта таблица может быть сохранена в том же самом кластере, как схема конфигурации или в другом. У сервера кэш-памяти могут быть связи с несколькими различными кластерами, и много серверов кэш-памяти могут соединиться с единственным кластером, но со множеством ролей.

Схема конфигурации ndbmemcache. Когда механизм кэш-памяти NDB запускается, он соединяется с кластером и ищет схему конфигурации ndbmemcache там. Если схема не найдена, он закрывается.

Схема описана (с полными комментариями) в файле ndb_memcache_metadata.sql.

Главное понятие схемы это отображение ключевого префикса. Это берет префикс ключа кэш-памяти и отображает его к определенной контейнерной таблице на конкретном кластере с конкретной политикой кэша.

Роль сервера определяется как ряд отображений ключевого префикса, которые осуществит сервер memcached.

Каждый раз, когда сервер memcached начат с конкретной ролью сервера (от параметров командной строки), эта роль сервера должна существовать в таблице ndbmemcache.server_roles.

В следующей таблице перечислены имена таблиц и описания для таблиц, которые принадлежат схеме конфигурации ndbmemcache.

Таблица 6.1. Схема конфигурации ndbmemcache

Имя таблицы Описание
meta Таблица метаданных описывает номер версии ndbmemcache. Это нужно рассмотреть как только для чтения.
ndb_clusters

Для каждого кластера вмещает числовой id и строку подключения. Столбец microsec_rtt используется для исполнительной настройки. Рекомендуется использовать значение по умолчанию этой колонки. Посмотрите Autotuning.

cache_policies

Отображает имя политики для установки правил get, set, delete и flush. Столбец policy_name используется в качестве ключа (нет никакого числового стратегического id).

Дополнительная информация о политике кэша может быть найдена в тексте после таблицы.

containers

Таблица контейнеров описывает, как сервер может использовать таблицу базы данных, чтобы хранить данные.

Дополнительная информация о политике кэша может быть найдена в тексте после таблицы.

memcache_server_roles

Таблица memcache_server_roles отображает ролевое имя к числовому ID и задает спецификатор max_tps, который используется для исполнительной настройки. Посмотрите Autotuning. Рекомендуется использовать значение по умолчанию.

У этой таблицы также есть столбец update_timestamp. Он может быть обновлен, чтобы позволить реконфигурацию онлайн. Посмотрите здесь.

Дополнительная информация о политике кэша может быть найдена в тексте после таблицы.

key_prefixes

Здесь крайняя левая часть ключа кэш-памяти соединена с cluster ID, контейнером и политикой кэша, чтобы сделать key prefix mapping.

Дополнительная информация о политике кэша может быть найдена в тексте после таблицы.


Политика кэша. Есть четыре стратегических типа: get_policy, set_policy, delete_policy и flush_from_db.

get_policy определяет, как сервер интерпретирует команды GET. Возможные значения показывают в следующем списке:

set_policy определяет, как сервер интерпретирует команды SET, INSERT и REPLACE.

delete_policy определяет, как сервер интерпретирует команду DELETE:

flush_from_db определяет, как сервер интерпретирует команды FLUSH_ALL относительно данных, хранящихся в базе данных NDB Cluster:

Столбцы таблицы контейнеров. Колонки в таблице containers описаны в следующем списке:

Ключевые отображения.

В следующей таблице перечислены имена таблиц и описания для неконфигуруемой регистрации ndbmemcache и всех контейнерных таблиц.

Таблица 6.2.

Имя таблицы Описание
last_memcached_signon

Эта таблица не часть схемы конфигурации, но является информативной таблицей регистрации. Это делает запись нового времени логина каждого сервера memcached, используя конфигурацию.

  • ndb_node_id интервал записи id узла API сервера.

  • hostname имя хоста сервера.

  • server_role роль, назначенная на сервер во время входа в систему.

  • signon_time метка времени, делающая запись времени запуска memcached.

    В случае реконфигурации онлайн signon_time делает запись времени последней реконфигурации, а не времени запуска. Это непреднамеренное последствие и могло бы считаться ошибкой.

demo_table demo_table контейнерная таблица, используемая с префиксом ключа по умолчанию в роли сервера по умолчанию. Это используется, чтобы продемонстрировать операции SET и GET, а также INCR, DECR и CAS с одним столбцом ключа и одним столбцом значений.
demo_table_tabs demo_table_tabs контейнерная таблица контейнера "demo_tabs", который используется с ключевым префиксом "t:" в роли сервера по умолчанию. Это используется, чтобы продемонстрировать один столбец ключа с многократными столбцами значений. В операциях по кэш-памяти столбцы значений представляются как отделенный табуляциями список.

Предопределенные объекты конфигурации.

Предопределенные кластеры. Единственная запись ndb_cluster предопределена, относясь к основному кластеру (где данные конфигурации сохранены) как cluster id 0. Id 0 должен всегда резервироваться для основного кластера.

Предопределенная политика кэша.

Предопределенные контейнеры.

Предопределенные роли сервера кэш-памяти и их ключевые префиксы.

Управление версиями конфигурации и модернизация. Схема конфигурации версионная и номер версии сохранен в таблице ndbmemcache.meta. NDB Engine начинает процесс конфигурации, читая номер версии схемы из этой таблицы. Как правило, более новые версии NDB останутся совместимыми с более старыми версиями схемы конфигурации.

Исполнительная настройка. Два параметра используются, чтобы настроить работу кэш-памяти NDB. Параметры сохранены в схеме конфигурации: "usec_rtt" конкретного кластера и "max_tps" роли сервера кэш-памяти. Эти значения в настоящее время используются двумя способами: чтобы формировать количество связей с каждым кластером и формировать конкретное постоянное число параллельных операций, поддержанных от каждой связи.

Autotuning. Автонастройка использует предполагаемое время цикла обработки между узлами данных кластера и целевым уровнем пропускной способности, чтобы определить идеальное количество связей кластера и транзакций для каждого подключения для данной рабочей нагрузки. Автонастраивающиеся параметры описаны в следующих нескольких параграфах.

Эти значения используются, как описано в следующих нескольких параграфах, чтобы вычислить оптимальное количество связей кластера с данной способностью транзакций в секунду.

Количество связей кластера. Планировщик NDB Engine пытается открыть 1 связь кластера на 50000 транзакций в секунду (TPS). Это поведение может быть отвергнуто при помощи строки конфигурации планировщика (см. раздел 6.4 ). Если планировщик не открывает вторую или последующую связь с кластером, например, потому что id узла недоступен, это не фатальная ошибка, это будет работать только с на самом деле открытыми связями.

Количество транзакций для каждого подключения. Мы предполагаем, что транзакция занимает в 5 раз больше цикла обработки кластера. Мы можем получить общее количество транзакций в работе, деля серверное max_tps на 5 * rtt (в секундах). Эти операционные объекты равномерно распределяются среди связей кластера.

Пример настройки. Следующий пример начинается со значений по умолчанию usec_rtt = 250 и max_tps = 100000 и принимает сервер memcached с 4 рабочими потоками.

Реконфигурация онлайн. Возможно повторно формировать отображения ключевого префикса управления механизм NDB, не перезапуская его. Это сделано, передав изменение схемы конфигурации, а затем обновив столбец update_timestamp конкретной роли сервера в ролевой таблице сервера кэш-памяти. Обновление метки времени заставляет триггер событий сработать, чтобы сервер кэш-памяти получил уведомление о событии.

Реконфигурация онлайн может быть отключена при помощи опции -e reconf=false в командной строке.

Реконфигурация онлайн может использоваться, чтобы соединиться с новыми кластерми и создать новые отображения ключевого префикса. Однако это не может использоваться, чтобы перезагрузить автонастраивающиеся значения на существующих связях.

Реконфигурация онлайн это опасная операция, которая может привести к катастрофам сервера кэш-памяти или повреждению данных, и используется экстенсивно в наборе тестов mysql. Однако это не рекомендуется для переформирования рабочего сервера.

Команда stats reconf может быть вызвана прежде и после реконфигурации онлайн, чтобы проверить, что номер версии конфигурации увеличился. Проверка реконфигурации также написана в файл журнала memcached.

6.5. Команды протокола Memcache

Механизм NDB поддерживает полный набор команд протокола кэш-памяти. Когда недавно установленный сервер начат с роли сервера по умолчанию и схемы конфигурации, необходимо быть в состоянии выполнить memcapable, инструмент проверки сервера кэш-памяти, и видеть, что все тесты проходят. После того, как конфигурация была настроена, например, отключив команду FLUSH_ALL, некоторые тесты memcapable, как ожидают, потерпят неудачу.

Операции GET, SET, ADD, REPLACE и DELETE. Каждая из этих операций всегда выполняется согласно политике кэша, связанной с префиксом ключа кэш-памяти. Это может воздействовать на в местном масштабе кэшируемый элемент, пункт, сохраненный в базе данных или на обоих. Если операция была отключена для префикса, разработчик, несомненно, должен будет проверить отключенную операцию, так как это может потерпеть неудачу тихо или с вводящим в заблуждение кодом ответа.

CAS. CAS в протоколе кэш-памяти, относится к значению compare and set, которое используется в качестве своего рода номера версии кэшированного значения и позволяет некоторое оптимистическое прикладное поведение.

Если контейнер будет включать колонку CAS, ndb произведет уникальный CAS ID каждый раз, когда это пишет значение данных, и сохранит его в колонке CAS.

Некоторые операции по кэш-памяти включают проверки CAS, такие как ASCII-обновление CAS, у которого есть семантика "обновляет эту значение только если ее id CAS соответствует id CAS в запросе". Эти операции поддерживаются NDB. Проверка сохраненного CAS ID против CAS ID приложения выполнена в атомной операции на узле данных NDB. Это позволяет проверкам CAS работать правильно, даже когда многократные серверы memcached получают доступ к той же самой паре ключ/значение.

Если проверки CAS ID используются, и дополнительные NDB Cluster API кроме memcached, используются, чтобы управлять данными, то приложения, использующие эти API отвечают за лишение законной силы сохраненных CAS ID каждый раз, когда они обновляют данные. Они могут сделать это, установив сохраненное CAS ID = 0 или NULL.

CAS ID произведен, используя схему, которая пытается препятствовать тому, чтобы различные серверы произвели накладывающиеся ID. Эту схему можно считать максимальными усилиями, но не гарантией уникальности. Схема строит начальный CAS следующим образом:

Часть 32-битного Cluster GCI от основного кластера во время запуска memcached используется для старших частей 64-битного CAS ID.

Часть уникального id узла кластера в основном кластере используется, когда полученная конфигурация используется для частей среднего порядка бит CAS ID.

Увеличивающийся счетчик в частях младшего разряда CAS ID по крайней мере 28 бит шириной.

В то время как механизм NDB производит одну последовательность CAS ID, механизм по умолчанию, используемый для кэширования в местных memcached-серверах, производит отличную последовательность. Не все комбинации поведения CAS и политики кэша были проверены, таким образом, любой разработчик приложений, желающий использовать CAS, должен полностью проверить, ведет ли особая конфигурация себя как надо.

FLUSH_ALL. FLUSH_ALL осуществляется следующим образом: Сначала механизм NDB проходит по всем формируемым ключевым префиксам. Для любого префикса, политика кэша которого позволяет сброс базы данных (flush_from_db = true), это выполняет просмотр каждой удаленной строки в контейнерной таблицы того префикса. Другие префиксы проигнорированы. Это может быть медленной операцией, если таблица большая, некоторые клиенты кэш-памяти могут получить тайм-аут перед завершением DELETE. После того, как вся база данных обработана, команда FLUSH_ALL отправлена стандартному механизму кэширования, который устанавливает флаг, лишающий законной силы все кэшированные данные.

INCR и DECR. Все INCR и DECR переданы к узлам данных NDB и выполнены атомарно там. Это позволяет многократным серверам увеличивать или уменьшать тот же самый ключ и гарантировать уникальное значение каждый раз.

Операции INCR и DECR имеют более ясную и более полезную семантику в двоичном протоколе кэш-памяти, чем в протоколе ASCII. Протокол двоичной синхронной передачи данных рекомендуется.

Протокол ASCII memcached вводит некоторые двусмысленности в обработке INCR и DECR и вынуждает механизм NDB работать в режиме dup_numbers, в котором value_column и math_column должны отразить друг друга.

Режим dup_numbers позволен для ключевых префиксов, которые отвечают всем следующим условиям:

В режиме dup_numbers следующее специальное поведение применяется:

APPEND и PREPEND. Операции memcache APPEND и PREPEND осуществляются как единственная транзакция, которая включает чтение существующего значения с монопольной блокировкой, сопровождаемое записью нового значения. Чтение и запись сгруппированы атомарно в транзакцию, но в отличие от INCR и DECR, которые могут работать на узлах данных, APPEND и PREPEND выполняются в memcached-сервере. Это означает, что многократные memcached-серверы могут передать APPEND и PREPEND то же самое значение, и что никакие обновления не будут потеряны, но это утверждение полагается на поведение при блокировании, которое могло вызвать увеличенное время ожидания.

STATS. Сервер может обеспечить много наборов статистики, надо использовать STATS KEYWORD из оболочки логина.

Все статистические данные, обычно доступные от ядра memcached 1.6 и механизма по умолчанию, доступны. Например, STATS, STATS SLABS и STATS SETTINGS в настоящее время поддерживаются, как описано в документации memcached. Некоторые специальные наборы статистики доступны из NDB, используя команды STATS в следующем списке:

6.6. Файл журнала memcached

Каждый раз, когда NDB инициализируется, он пишет сообщение включая метку времени и номер версии к его файлу журнала, как показано здесь:

12-Oct-2011 13:40:00 PDT NDB Memcache 5.5.15-ndb-7.2.1 started
[NDB 7.2.1; MySQL 5.5.15]

Это также регистрирует свою попытку соединиться с основным кластером:

Contacting primary management server (localhost:1186) ...
Connected to "localhost:1186" as node id 4.

При успешном получении начальных данных конфигурации механизм кэш-памяти регистрирует итоговое сообщение, описывающее конфигурацию, подобную тому, что показывают здесь:

Retrieved 3 key prefixes for server role "default_role"
The default behavior is that:
  GET uses NDB only
  SET uses NDB only
  DELETE uses NDB only
The 2 explicitly defined key prefixes are "mc:" () and "t:" (demo_table_tabs)
Server started with 4 threads.

Механизм кэш-памяти также регистрирует учреждение каждой дополнительной связи кластера, как показано здесь:

Connected to "" as node id 5.

Сообщение priming the pump... указывает, что механизм собирается предварительно наполнить пул операционных объектов (API Connect Records). Это сопровождается сообщением done ..., указывающим, сколько времени это заняло. Сервер не готов ответить клиентам, пока предварительная установка не будет закончена.

Priming the pump ...
Scheduler: using 2 connections to cluster 0
Scheduler: starting for 1 cluster; c0,f0,t1
done [0.579 sec].

Как только механизм NDB закончил инициализацию, memcached печатает сообщение, проверяющее, что механизм был загружен, и перечисляющее некоторые его особенности:

Loaded engine: NDB Memcache 5.5.15-ndb-7.2.1
Supplying the following features: compare and swap, persistent storage, LRU

Если реконфигурация онлайн позволена, механизм NDB регистрирует каждую реконфигурацию, наряду с резюме новой конфигурации, подобно тому, что показывают здесь:

Received update to server role default_role
Retrieved 3 key prefixes for server role "default_role".
The default behavior is that:
  GET uses NDB only
  SET uses NDB only
  DELETE uses NDB only.
The 2 explicitly defined key prefixes are "mc:" () and "t:" (demo_table_tabs)
ONLINE RECONFIGURATION COMPLETE

На закрытии memcached регистрирует завершение, планировщик NDB регистрирует свое собственное закрытие также:

Initiating shutdown
Shutting down scheduler.
Shutdown completed.

6.7. Известные проблемы и ограничения ndbmemcache

Эта секция предоставляет информацию об известных проблемах и ограничениях Memcache API для кластера NDB.

Проблемы с AUTO_INCREMENT. ndbmemcache обходит NDB для обработки столбцов AUTO_INCREMENT. Это означает что, когда вы вставляете строки, используя ndbmemcache в таблицу, имеющую столбец AUTO_INCREMENT, он автоматически не обновляется. Это может привести к ошибкам двойного ключа, когда вставки выполняются позднее с использованием SQL в клиентском приложении MySQL, таком как mysql.

Чтобы решить проблему, можно использовать генератор последовательности, как описано здесь.

Изменения схемы онлайн не поддержаны. Демон memcached не обнаруживает изменения схемы онлайн, после внесения таких изменений, его необходимо перезапустить прежде, чем обновленная схема сможет использоваться.

Доли секунды. Начиная с NDB 7.2.3, ndbmemcache поддерживает использование долей секунды с типами данных TIME, DATE и DATETIME как осуществлено в MySQL 5.6.4 и позже. ndbmemcache в предыдущих версиях кластера NDB не поддерживает доли секунды (Bug #16593493).