WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 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. -E so_file Определяет механизм (модуль), который будет динамично загружен на запуске memcached (версия 1.6 или позже). Если этот выбор не определяется, memcached пытается загрузить механизм по умолчанию, который обеспечивает тот же самый механизм кэширования, как используется в memcached 1.4 и предыдущих версиях. Чтобы загрузить механизм NDB, используйте этот выбор как показано здесь: -E /path/to/ndb_engine.so -e "configuration_string" Определяет возможности для использования загруженного механизма. Варианты даны как пары option=value, отделенные точками с запятой. Полная последовательность должна быть процитирована, что предотвращает возможность, что оболочка могла бы интерпретировать точку с запятой как сепаратор команды. Все варианты, которые будут переданы NDB memcached, должны быть определены этим способом, как показано следующим примером: shell> memcached -E lib/ndb_engine.so -e "connectstring=maddy:1186;role=dev" См. раздел 6.4 для списка параметров конфигурации NDB memcached. -t number_of_worker_threads Определяет число рабочих потоков, которые будут использоваться memcached. Поскольку memcached использует управляемую событиями модель, в которой каждый рабочий поток должен быть в состоянии насыщать ядро процессора, количество рабочих потоков должно быть приблизительно тем же самым, как количество ядер процессора, которые должен использовать memcached. В некоторых случаях добавление рабочих потоков не улучшает работу, если вы также не обеспечиваете дополнительные связи с NDB Cluster. Умолчание (4 потока memcached и 2 связи с кластером) должно нормально работать в большинстве случаев. -p tcp_port Порт TCP по умолчанию является портом 11211. -U udb_port Порт UDP по умолчанию 11211. Установка этого выбора к 0 отключает поддержку UDP. -h Напечатать справочную информацию. Для получения общей информации о параметрах командной строки memcached см. документацию http://code.google.com/p/memcached/wiki/NewStart. 6.4. Конфигурация механизма NDB Опции настройки NDB memcache. Механизм NDB поддерживает следующие параметры конфигурации для использования с memcache -e (см. раздел 6.3): debug={true|false} Позволяет писать трассировочную информацию отладки к stderr или в файл журнала memcached, как показано в этом примере: shell> memcached -E lib/ndb_engine.so -e "debug=true" Поскольку вывод отладки может быть довольно большой, необходимо позволить этот выбор только как диагностический инструмент, а не в производстве. По умолчанию этот выбор false. connectstring= connect_string Этот выбор берет в качестве его значения строку подключения NDB Cluster (см. NDB Cluster Connection Strings), указывающую на основной NDB Cluster то есть, NDB Cluster, в котором сохранена база данных конфигурации ndbmemcache, как показано здесь: shell > memcached -E lib/ndb_engine.so -e "connectstring=sam:1186;debug=true" Значение по умолчанию localhost:1186. reconf={true|false} Позволяет реконфигурацию онлайн (перезагрузку конфигурации, сохраненной в информационной базе данных ndbmemcache). Этот выбор позволен (true) по умолчанию. role=role_name Устанавливает роль, принятую этим memcached сервером. Роль соответствует ряду отображений ключевого префикса, описанных в базе данных конфигурации ndbmemcache, определенной role_name в таблице ndbmemcache.memcache_server_roles. Роль по умолчанию default_role. Пример показывают здесь: shell> memcached -E lib/ndb_engine.so -e "role=db-only" scheduler= scheduler_name:scheduler_options Этот выбор управляет некоторыми продвинутыми аспектами того, как механизм NDB отправляет запросы NDB Cluster. scheduler_name это планировщик по умолчанию, но также есть S-scheduler. Выбор S-scheduler принимает форму одной буквы, сопровождаемой числом, многократные опции S-scheduler отделены запятыми. В большинстве случаев, значение по умолчанию S:c0,f0,t1 достаточно. Эти опции S-scheduler описаны в следующем списке: c: Количество связей с NDB. Возможные значения находятся в диапазоне 0-4, 0 (умолчание) предписывает вычислить это число автоматически. Используя 1, 2, 3 или 4, вы задаете количество связей, которые будут созданы. f: Может быть 0 или 1: 1 включает принудительную передачу, по умолчанию 0 (принудительная передача выключена). t: Устанавливает таймер потока передачи в 1-10 миллисекунд (включительно). По умолчанию 1. Начальная конфигурация. Когда механизм 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. Возможные значения показывают в следующем списке: cache_only: Сервер ищет только в его местном кэше. ndb_only: Сервер ищет только в базе данных NDB. caching: Сервер смотрит местный кэш сначала, затем базу данных NDB Cluster. disabled: Команда GET выключена. set_policy определяет, как сервер интерпретирует команды SET, INSERT и REPLACE. cache_only: Сервер обновляет значение только в своем местном кэше. ndb_only: Сервер обновляет значение только в NDB Cluster. caching: Сервер обновляет значение в NDB Cluster, затем сохранит копию в местном кэше. disabled: Команды SET, INSERT и REPLACE выключены. delete_policy определяет, как сервер интерпретирует команду DELETE: cache_only: Сервер удаляет значение только из своего местного кэша. ndb_only: Сервер удаляет значение только из базы данных NDB Cluster. caching: Сервер удаляет значение из базы данных и из местного кэша. disabled: Операции DELETE выключены. flush_from_db определяет, как сервер интерпретирует команды FLUSH_ALL относительно данных, хранящихся в базе данных NDB Cluster: true: FLUSH_ALL удаляют данные из базы данных NDB Cluster. false: FLUSH_ALL не затрагивают базу данных NDB Cluster. Столбцы таблицы контейнеров. Колонки в таблице containers описаны в следующем списке: name: Название контейнера; первичный ключ таблицы. db_schema: Название базы данных (схемы), содержащей контейнерные таблицы. db_table: имя контейнерной таблицы. key_columns: Список колонок, которые отображены к ключу кэш-памяти. Большинство ключей это ключи с одной частью, но у ключа может быть до четырех частей, в этом случае многочисленные колонки перечислены и отделены запятыми. value_columns: Список колонок, которые отображены к значениям кэш-памяти. Это может также содержать список разделенных запятой значений до 16 столбцов. flags: В настоящее время не работает, это предназначается для хранения числового значения, которое используется в качестве параметра FLAGS кэш-памяти для всего контейнера или названия той колонки контейнерной таблицы, которая раньше хранила это значение. increment_column: Название колонки в контейнерной таблице, которая хранит числовое значение, используемое в операциях memcached INCR и DECR. Если установлено, это должно быть BIGINT UNSIGNED . cas_column Название колонки в контейнерной таблице, которая хранит значение CAS кэш-памяти. Если установлено, это должен быть BIGINT UNSIGNED. expire_time_column: Пока не сделано. Ключевые отображения. server_role_id числовой ролевой идентификатор сервера, который ссылается на таблицу memcache_server_roles. key_prefix последовательность, которая соответствует крайней левой части ключа кэш-памяти. Если эта последовательность будет пуста, то определенный префикс будет "префиксом по умолчанию". Префикс по умолчанию соответствует любому ключу кэш-памяти, который не соответствует некоторому более определенному префиксу. cluster_id это int, который ссылается на таблицу ndb_clusters. policy последовательность, которая ссылается на стратегическое имя в таблице cache_policies. container контейнерное имя, которое ссылается на таблицу 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 должен всегда резервироваться для основного кластера. Предопределенная политика кэша. "memcache-only": политика, в которой все операции по кэш-памяти должны использовать только местный кэш. "ndb-only": политика, в которой все операции по кэш-памяти должны использовать только NDB Cluster за исключением FLUSH_ALL, которая отключена. "caching": get_policy, set_policy и delete_policy = "caching". FLUSH_ALL отключена. "caching-with-local-deletes": get_policy и set_policy = "caching", delete_policy = "cache-only", FLUSH_ALL отключена. "ndb-read-only": get_policy = ndb_only, чтобы операции GET с кэш-памятью использовали базу данных, но все другие операции по кэш-памяти отключены. "ndb-test": аналог "ndb-only", но FLUSH_ALL включена (flush_from_db = true). Это единственная предопределенная политика с позволенной flush_from_db. Эта политика позволена по умолчанию для роли сервера по умолчанию, таким образом весь набор команд кэш-памяти может быть продемонстрирован. Предопределенные контейнеры. "demo_table": контейнер использует таблицу ndbmemcache.demo_table. "demo_tabs": контейнер использует таблицу ndbmemcache.demo_table_tabs. Предопределенные роли сервера кэш-памяти и их ключевые префиксы. "default_role" (role id 0). "": пустой префикс (умолчание) использует политику ndb-test с контейнером demo_table. "mc:" ключи кэш-памяти, начинающиеся с "mc:", рассматриваются согласно политике кэша memcache-only. "t:" ключи кэш-памяти, начинающиеся с "t:", используют политику кэша ndb-test с контейнером demo_tabs. "db-only" role (role id 1). "": пустой префикс (умолчание) использует роль ndb-only с контейнером demo_table. Префикс "t:" использует роль ndb-only с контейнером demo_tabs. "mc-only" role (role id 2). "": пустой префикс (умолчание) использует только местное кэширование для всех ключей. "ndb-caching" role (role id 3). "": пустой префикс (умолчание) использует политику кэша "caching" с контейнером "demo_table" для всех ключей. Управление версиями конфигурации и модернизация. Схема конфигурации версионная и номер версии сохранен в таблице ndbmemcache.meta. NDB Engine начинает процесс конфигурации, читая номер версии схемы из этой таблицы. Как правило, более новые версии NDB останутся совместимыми с более старыми версиями схемы конфигурации. Исполнительная настройка. Два параметра используются, чтобы настроить работу кэш-памяти NDB. Параметры сохранены в схеме конфигурации: "usec_rtt" конкретного кластера и "max_tps" роли сервера кэш-памяти. Эти значения в настоящее время используются двумя способами: чтобы формировать количество связей с каждым кластером и формировать конкретное постоянное число параллельных операций, поддержанных от каждой связи. Autotuning. Автонастройка использует предполагаемое время цикла обработки между узлами данных кластера и целевым уровнем пропускной способности, чтобы определить идеальное количество связей кластера и транзакций для каждого подключения для данной рабочей нагрузки. Автонастраивающиеся параметры описаны в следующих нескольких параграфах. usec_rtt: Время цикла обработки в микросекундах между узлами кластера. Значение по умолчанию 250, которое типично для кластера NDB на местном ethernet. Чтобы представлять кластер с более высоким временем ожидания между узлами более высокое значение должно использоваться. max_tps: Желаемая пропускная способность от сервера. Эта значение эвристическое, и ни в коем случае не выражает минимум или максимум на фактически полученной пропускной способности. Значение по умолчанию (100000) разумно в большинстве случаев. Эти значения используются, как описано в следующих нескольких параграфах, чтобы вычислить оптимальное количество связей кластера с данной способностью транзакций в секунду. Количество связей кластера. Планировщик NDB Engine пытается открыть 1 связь кластера на 50000 транзакций в секунду (TPS). Это поведение может быть отвергнуто при помощи строки конфигурации планировщика (см. раздел 6.4 ). Если планировщик не открывает вторую или последующую связь с кластером, например, потому что id узла недоступен, это не фатальная ошибка, это будет работать только с на самом деле открытыми связями. Количество транзакций для каждого подключения. Мы предполагаем, что транзакция занимает в 5 раз больше цикла обработки кластера. Мы можем получить общее количество транзакций в работе, деля серверное max_tps на 5 * rtt (в секундах). Эти операционные объекты равномерно распределяются среди связей кластера. Пример настройки. Следующий пример начинается со значений по умолчанию usec_rtt = 250 и max_tps = 100000 и принимает сервер memcached с 4 рабочими потоками. 100000 TPS/50000 = 2, сервер открывает две связи кластера NDB. Время транзакции в микросекундах = 250 мкс в 5 раз больше цикла обработки = 250 мкс * 5 циклов = 1250 мкс. Транзакции для каждого подключения в секунду = 1000000/tx_time_in_sec = 1000000/1250 = 800. Всего объектов Ndb = max_tps/tx_per_ndb_per_sec = 100000/800 = 125. 125 объектов Ndb/2 связи = 63 объекта Ndb на связь (округление вверх). (Округление вверх еще раз), каждый из 4 рабочих потоков получает по 32 объекта Ndb. Реконфигурация онлайн. Возможно повторно формировать отображения ключевого префикса управления механизм 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 следующее специальное поведение применяется: Каждый раз, когда ASCII-команды SET, ADD или REPLACE устанавливают значение, которое могло интерпретироваться как числовое, и контейнер определяет math_column, текстовое значение сохранено в столбце значений, а числовое значение также сохранено в математической колонке. Каждый раз, когда ASCII-команды INCR или DECR выполняются, текстовое значение столбца значений контейнера установлено в NULL. Каждый раз, когда выполняется команда memcached GET и столбец значений контейнера NULL, но математическая колонка контейнера не NULL, математическое значение возвращено клиенту. 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 в следующем списке: STATS NDB: Вернет статистику NDB API для каждой связи кластера NDB. Это те же самые внутренние статистические данные, которые доступны как переменные состояния системы от MySQL Server. См. NDB API Statistics Counters and Variables. STATS SCHEDULER: Статистика для планировщика S. Обо всех этих статистических данных сообщают на уровне связи кластера. cl%d.conn%d.sent_operations: Количество операций, посланных из передающего потока связи в узлы данных кластера. cl%d.conn%d.batches: Количество операционных блоков, посланных от передающего потока связи в узлы данных. Каждый блок содержит одну или более операций. sent_operations / batches может использоваться, чтобы вычислить средний пакетный размер. cl%d.conn%d.timeout_races: Это делает запись редкого состояния состязания, которое может произойти в передающем потоке. Это, как ожидают, будет 0 или будет очень низким по сравнению с sent_operations. stats reconf: Если NDB в настоящее время загружает новую конфигурацию, команда возвращает однострочное сообщение Loading revno , где revno номер версии загружаемой конфигурации. Иначе эта команда возвращает статистическое сообщение Running revno . revno начинается с 1, когда сервер memcached начинает работать и увеличено на 1 для каждой реконфигурации онлайн. 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).

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.