RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 
YandexMoney: 
41001198119846 
E-gold:
5128052

4 Управление процессами в MySQL Cluster

Имеются четыре процесса, которые важны при использовании MySQL Cluster. Мы здесь разберемся, как работать с этими процессами, какие параметры использовать при старте и т. д.

4.1 Использование процесса сервера MySQL для MySQL Cluster

Традиционным серверным процессом MySQL является mysqld. Чтобы использоваться с кластером MySQL, он должен быть собран с поддержкой для способа хранения NDB Cluster. Если mysqld был собран именно так, то поддержка NDB Cluster по умолчанию выключена.

Чтобы включить поддержку NDB Cluster имеются два способа. Или использование опции --ndbcluster при запуске mysqld, встраивание строки ndbcluster в секцию [mysqld] Вашего файла my.cnf. Простой способ проверить, что Ваш сервер выполняется с поддержкой для NDB Cluster состоит в том, чтобы выдать команду SHOW ENGINES из клиента mysql. Вы должны видеть YES для строки NDBCLUSTER. Если Вы видите NO, Вы не выполняете mysqld, который компилируется с допускаемой поддержкой NDB Cluster. Если Вы видите DISABLED, то Вы должны активизировать поддержку в файле my.cnf.

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

  • Собственный ID узла в кластере.
  • Имя хоста (или IP-адрес), где работате сервер управления.
  • Порт, на котором можно соединиться с сервером управления.

ID узла может быть пропущен в MySQL 4.1.5, потому что ID может быть динамически распределен.

В mysqld применяется параметр ndb-connectstring, чтобы определить строку подключения connectstring при старте mysqld или в файле my.cnf.

shell> mysqld --ndb-connectstring=ndb_mgmd.mysql.com:1186

ndb_mgmd.mysql.com представляет собой хост, на котором постоянно находится сервер управления, и он слушает порт 1186.

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

4.2 Процесс ndbd и работа узлов памяти

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

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

До MySQL 4.1.5 процесс ndbd должен запускаться из отдельного каталога. Причиной этого было то, что ndbd генерирует набор журналов в начальном каталоге.

В MySQL 4.1.5 это было изменено так, что файлы помещены в каталог, определенный DataDir в файле конфигурации. Таким образом, ndbd может быть запущен отовсюду.

Вот эти журналы (2 обозначает ID узла):

  • ndb_2_error.log (error.log в версии 4.1.3) файл, который содержит информацию обо всех сбоях, с которыми столкнулся процесс ndbd, строки сообщений об ошибках и ссылки на файл трассировки для них, например, так:
    Date/Time: Saturday 31 January 2004 - 00:20:01
    Type of error: error
    Message: Internal program error (failed ndbrequire)
    Fault ID: 2341
    Problem data: DbtupFixAlloc.cpp
    Object of reference: DBTUP (Line: 173)
    ProgramName: NDB Kernel
    ProcessID: 14909
    TraceFile: ndb_2_trace.log.2
    ***EOM***
    
  • ndb_2_trace.log.1 (NDB_TraceFile_1.trace в версии 4.1.3) файл трассировки, описывающий точно, что случилось прежде, чем произошла ошибка. Эта информация полезна для группы разработки MySQL Cluster при анализе любых ошибок. Информация в этом файле будет описана в разделе "Проблемы с MySQL Cluster". Может быть настраиваемое количество файлов трассировки в этом каталоге. В этом контексте 1 просто номер файла.
  • ndb_2_trace.log.next (NextTraceFileNo.log в версии 4.1.3) файл, который следит за тем, каким должен быть следующий номер файла регистрации, если их несколько.
  • ndb_2_out.log файл, который содержит любые данные, выведенные процессом ndbd. Этот файл применяется только, если ndbd запущен в режиме демона, который задан по умолчанию в версии 4.1.5 и выше. В версии 4.1.3 файл известен как node2.out.
  • ndb_2.pid (node2.pid в версии 4.1.3) файл, содержащий идентификатор процесса ndbd при работе в режиме демона. Это также функционирует как файл блокировки, чтобы избежать запуска узлов с тем же самым идентификатором.
  • ndb_2_signal.log (был Signal.log в версии 4.1.3) файл, который используется только в отладочных версиях ndbd, где возможно проследить все входящие, исходящие и внутренние сообщения с их данными в процессе ndbd.

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

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

shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"

При запуске ndbd реально запускается пара процессов. Первый присматривает за вторым и перезапускает его в случае сбоя. Так что Unix-командой kill надлежит прерывать оба процесса, а лучше всего использовать клиент управления и завершать ndbd оттуда.

Процесс выполнения использует один поток для всех действий чтения, записи, просмотра данных и всех других действий. Этот поток разработан с асинхронным программированием, так что это может легко обрабатывать тысячи параллельных задач. Кроме того, имеется поток сторожа, контролирующий поток выполнения, чтобы гарантировать, что он не останавливается в вечном цикле или другой проблеме. Имеется пул потоков для обслуживания файлового ввода-вывода. Каждый из этих потоков может обрабатывать один открытый файл. Кроме того, потоки могут использоваться для действий подключения транспортеров в процессе ndbd. Таким образом, в системе, которая выполняет большое количество действий, включая действия модификации, процесс ndbd потребит приблизительно до 2 CPU, если это позволено. Таким образом, в большом SMP-блоке со многими CPU рекомендуется использовать несколько процессов ndbd, которые сконфигурированы так, чтобы быть частью различных групп узлов.

4.3 ndb_mgmd, процесс сервера управления

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

Начиная с MySQL 4.1.5, нет надобности определять строку подключения при запуске управляющего сервера. Однако, если Вы используете несколько серверов управления, нужно обеспечить эту строку, а каждый узел в кластере должен определить свой nodeid явно.

Следующие файлы созданы или используются ndb_mgmd в начальном каталоге ndb_mgmd. Начиная с MySQL 4.1.5, файлы протоколов и PID будут помещены в DataDir, определенный в файле конфигурации:

  • config.ini представляет собой файл конфигурации кластера. Он создан пользователем и читается сервером управления. Как писать этот файл рассказано в разделе "Настройка MySQL Cluster".
  • ndb_1_cluster.log (cluster.log в версии 4.1.3) файл, где фиксируются события в кластере. Примеры событий: контрольные точки, (начатые и завершенные), сбои узлов, уровни использования памяти и т.д. События описаны в разделе "5 Управление кластером MySQL".
  • ndb_1_out.log (node1.out в версии 4.1.3) файл, используемый для stdout и stderr при выполнении сервера управления как демона. В этом контексте 1 задает ID узла.
  • ndb_1.pid (node1.pid в версии 4.1.3) PID-файл, используемый при выполнении сервера управления как демона. В этом контексте 1 задает ID узла.
  • ndb_1_cluster.log.1 (cluster.log.1 в версии 4.1.3) когда файл регистрации кластера становится большим, чем один миллион байт (именно миллион байт, а не мегабайт!), файл переименован к этому имени. Здесь 1 номер журнала кластера, такчто , если 1, 2 и 3 уже существуют следующий будет иметь номер 4.

4.4 ndb_mgm, клиентский процесс управления

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

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

При старте управляющего клиента, необходимо установить имя хоста и порт для связи с сервером управления как в примере ниже. Значение по умолчанию: localhost и порт 1186 (был 2200 до версии 4.1.8).

shell> ndb_mgm localhost 1186

4.5 Параметры команд для MySQL Cluster

Все исполняемые модули в MySQL Cluster (кроме mysqld) понимают следующие параметры, начиная с версии 4.1.8. Если вы выполняете более раннюю версию, внимательно ознакомьтесь с текстом ниже, там указаны все отличия и проблемы. Обратите внимание также, что Вы можете использовать опцию -?, чтобы увидеть, что обеспечивается в Вашей версии.

-?, --usage, --help
Печатает короткое описание доступных параметров команды.
-V, --version
Печатает номер версии процесса ndbd. Это номер версии MySQL Cluster. Важно, потому что при запуске процессы MySQL Cluster проверяют, какие версии процессов могут сосуществовать в кластере. Это также важно для интерактивного программного обновления MySQL Cluster.
-c connect_string (не ndb_mgmd), --connect-string connect_string
Установить строку подключения к серверу управления как опцию команды (по причинам обратной совместимости ndb_mgmd до версии 5.0 опцию -c не обрабатывает, поскольку она в настоящее время определяет файл конфигурации). Доступно с ndb_mgm 4.1.8 и выше.
shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"
--debug[=options]
Это может использоваться только для версий с информацией отладки. Это используется, чтобы допустить вывод из вызовов отладки тем же самым способом, что и у процесса mysqld.

4.5.1 MySQL Cluster-специфичные параметры для mysqld

--ndbcluster
Если двоичный модуль включает поддержку для способа хранения NDB Cluster, эта опция активизирует данную поддержку, а она необходима для работы MySQL Cluster.
--skip-ndbcluster
Выключает поддержку NDB Cluster. По умолчанию поддержка и так выключена, так что эта опция нужна лишь на серверах, заранее сконфигурированных для кластерной работы.
--ndb-connectstring=connect_string
При использовании NDB, возможно подчеркнуть сервер управления, который распределяет конфигурацию кластера, устанавливая опцию строки подключения.

4.5.2 Опции для ndbd

Основные параметры перечислены в разделе "4.5 Параметры команд для MySQL Cluster".

-d, --daemon
Инструктирует ndbd выполниться как процесс-демон. В MySQL 4.1.5 и выше включено по умолчанию.
--nodaemon
Инструктирует ndbd не выполняться как процесс-демон. Полезно, когда ndbd отлаживается и выводит на экран отчеты.
--initial
Инструктирует ndbd выполнить начальную инициализацию. Это сотрет любые файлы, созданные ранее ndbd для восстановления. Это также вновь создаст журналы восстановления, что на некоторых операционных системах может занимать немалое время. Инициализация применяется только при самом первом запуске процесса ndbd. Это удаляет все служебные файлы из файловой системы и создает все REDO-протоколы. При выполнении программного обновления, которое изменило содержание любых файлов, также необходимо использовать эту опцию при перезапуске узла с новой программной версией ndbd. В заключение это могло бы также использоваться как последний аргумент для узла, который невозможно перезапустить. В этом случае помните, что разрушение содержания файловой системы означает, что этот узел больше не может использоваться, чтобы восстановить данные. Эта опция не воздействует на любые созданные файлы с резервными копиями. Ранее имевшаяся возможность использовать -i для этой опции была удалена, чтобы гарантировать, что эта опция не используется по ошибке.
--nostart
Инструктирует ndbd не запускаться автоматически. Процесс ndbd соединится с сервером управления, получит конфигурацию и инициализирует объекты связи. Это не будет запускать основные процессы, пока не получит соответствующую инструкцию сервера управления в явном виде. На деле такая инструкция обычно выдается через сервер клиентом управления.

4.5.3 Опции для ndb_mgmd

Основные параметры перечислены в разделе "4.5 Параметры команд для MySQL Cluster".

-f filename (from 4.1.8), --config-file=filename, -c filename (устарело, начиная с версии 5.0)
Эта опция должна быть определена в обязательном порядке. Она определяет, какой именно файл будет рассматриваться как конфигурационный. По умолчанию это config.ini.
-d, --daemon
Инструктирует ndb_mgmd выполниться как процесс-демон. Задано по умолчанию.
-nodaemon
Инструктирует ndb_mgmd не выполняться как процесс-демон.

4.5.4 Опции для ndb_mgm

[host_name [port_num]]
Чтобы запустить клиент управления, необходимо определить, где сервер управления постоянно находится. Это означает, что надо определять имя машины и порт. Значение по умолчанию localhost и порт 1186 (был 2200 до версии 4.1.8).
--try-reconnect=number
Если подключение прервано, можно выполнить только определенное количество повторных попыток соединиться перед сообщением пользователю кода неисправности. Значение по умолчанию: повторять до успеха каждые 5 секунд.

5 Управление MySQL Cluster

Управление MySQL Cluster включает ряд действий. Первое действие должно конфигурировать и запустить MySQL Cluster.

Имеются по существу два способа активного управления выполнением MySQL Cluster. Первый: командами, введенными в клиенте управления, где состояние кластера может быть проверено. Второй метод состоит в том, чтобы исследовать вывод в файле регистрации кластера. Файл регистрации кластера направлен в ndb_2_cluster.log в каталоге DataDir сервера управления. Файл регистрации содержит отчеты о событиях, сгенерированные из процессов ndbd в кластере. Также возможно послать записи файла регистрации кластера файлу регистрации системы Unix.

5.1 Команды в клиенте управления

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

Клиент управления имеет следующие базисные команды. Ниже <id> обозначает идентификатор узла базы данных (например, 21) или ключевое слово ALL, что указывает, что команда должна применяться ко всем узлам баз данных в кластере.

HELP
Печатает информацию о всех доступных командах.
SHOW
Печатает информацию относительно состояния кластера.
<id> START
Запустит узел базы данных, идентифицированный <id>, или все узлы баз данных.
<id> STOP
Выключит узел базы данных, идентифицированный <id>, или все узлы баз данных.
<id> RESTART [-N] [-I]
Перезапустит узел базы данных, идентифицированный <id>, или все узлы баз данных.
<id> STATUS
Информация состояния для узла базы данных, идентифицированного <id>, или для всех (ALL) узлов.
ENTER SINGLE USER MODE <id>
Вводит режим отдельного пользователя, где только API с идентификатором <id> позволяют обратиться к системе базы данных.
EXIT SINGLE USER MODE
Отменяет режим отдельного пользователя, позволяя всем API обратиться к системе базы данных.
QUIT
Завершает клиент управления..
SHUTDOWN
Завершает работу всех узлов кластера (за исключением серверов mysql) и выходит из клиента управления.

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

5.2 Отчеты о событиях, сгенерированные в MySQL Cluster

MySQL Cluster имеет два файла регистрации событий: файл регистрации кластера и файл регистрации узла.

  • Файл регистрации кластера ведет протокол работы целого кластера, и этот файл регистрации может иметь многократных адресатов (файл, консоль сервера управления или syslog).
  • Файл регистрации узла является локальным для каждого узла базы данных и записан на консоль узла базы данных. Два файла регистрации могут быть установлены, чтобы регистрировать различные подмножества списка событий.

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

Каждое событие имеет следующие реквизиты:

  • Категория (STARTUP, SHUTDOWN, STATISTICS, CHECKPOINT, NODERESTART, CONNECTION, ERROR, INFO).
  • Приоритет (1-15, где 1 наиболее важный, 15 наименее важный).
  • Серьезность (ALERT, CRITICAL, ERROR, WARNING, INFO, DEBUG).

Два файла регистрации (файл регистрации кластера и файл регистрации узла) могут быть фильтрованы, основываясь на этих реквизитах.

5.2.1 Команды управления протоколированием

Следующие команды управления связаны с файлом регистрации кластера:

CLUSTERLOG ON
Включить протоколирование кластера.
CLUSTERLOG OFF
Выключить протоколирование кластера.
CLUSTERLOG INFO
Информация относительно параметров настройки протоколирования.
<id> CLUSTERLOG <category>=<threshold>
События категории category с приоритетом меньше, чем или равным threshold отмечаются в файле регистрации кластера.
CLUSTERLOG FILTER <severity>
Регистрация событий кластера определенного типа серьезности вкл\выкл.

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

Обратите внимание, что события сообщены узлом базы данных, и что пороги могут быть установлены по-разному на различных узлах.

КатегорияПорог по умолчанию (все узлы базы данных)
STARTUP7
SHUTDOWN7
STATISTICS7
CHECKPOINT7
NODERESTART7
CONNECTION7
ERROR15
INFO7

Порог используется, чтобы фильтровать события внутри каждой категории. Например: событие STARTUP с приоритетом 3 никогда не будет послано, если порог для STARTUP не установлен в 3 или ниже. Только события с приоритетом 3 или ниже будут посланы, если порог равен 3. Теперь о серьезности событий (она соответствует уровням UNIX syslog):

1ALERTСитупция, которая должна быть исправлена немедленно, типа разрушенной базы данных
2CRITICALКритическая ситуация, типа ошибок устройства или исчерпания ресурсов
3ERRORПроблема, которая должна быть исправлена, типа ошибок конфигурации
4WARNINGЭто не ошибка, но может требовать обработки
5INFOИнформационные сообщения
6DEBUGСообщения, используемые в ходе разработки и отладки NDB Cluster

Коды LOG_EMERG и LOG_NOTICE из syslog здесь не применяются и не поддерживаются.

Серьезность событий (event severity) может быть включена или выключена. От этого зависит, будут ли регистрироваться события соответствующей серьезности. Если серьезность включена, регистрируются все события с приоритетом меньше, чем или равным порогу категории. Если серьезность выключена, не будет отмечено никаких событий, принадлежащих к этой серьезности.

5.2.2 Сообщения в протоколах событий

Все регистрируемые события перечислены ниже.

Событие Категория (Category) Приоритет (Priority) Серьезность (Severity) Описание
DB nodes connectedCONNECTION8INFO Узел базы данных подключился
DB nodes disconnectedCONNECTION8INFO Узел базы данных отключился
Communication closedCONNECTION8INFO Соединение узлов API & DB закрыто
Communication openedCONNECTION8INFO Соединение узлов API & DB открыто
Global checkpoint startedCHECKPOINT9 INFOНачало GCP, то есть REDO-протокол записан на диск
Global checkpoint completedCHECKPOINT10 INFOGCP завершена
Local checkpoint startedCHECKPOINT7 INFOНачало локальной контрольной точки, то есть данные записаны на диск. LCP Id и GCI Id хранятся и восстанавливается самый старый
Local checkpoint completedCHECKPOINT8 INFOLCP завершена
LCP stopped in calc keep GCICHECKPOINT0 ALERTLCP прервана!
Local checkpoint fragment completedCHECKPOINT 11INFOLCP на фрагменте завершена
Report undo log blockedCHECKPOINT7 INFOБуфер протоколирования отмен (undo) скоро переполнится
DB node start phases initiatedSTARTUP1 INFOИнициализирован NDB Cluster
DB node all start phases completedSTARTUP1 INFOЗапущен NDB Cluster
Internal start signal received STTORRYSTARTUP 15INFOВнутренний стартовый сигнал блокам после законченного рестарта
DB node start phase X completedSTARTUP4 INFOСтартовая фаза завершена
Node has been successfully included into the cluster STARTUP3INFOУзел успешно включен в кластер
Node has been refused to be included into the cluster STARTUP8INFOУзел не удалось включить в кластер
DB node neighboursSTARTUP8INFO Показывает соседние узлы базы данных
DB node shutdown initiatedSTARTUP1 INFOИнициализировано закрытие системы узла
DB node shutdown abortedSTARTUP1 INFOПрервано закрытие системы узла
New REDO log startedSTARTUP10INFO GCI хранит X, самый новый восстанавливаемый GCI Y
New log startedSTARTUP10INFO Часть файла регистрации X, начата MB Y, завершена MB Z
Undo records executedSTARTUP15INFO Выполнение записи отмены (Undo)
Completed copying of dictionary informationNODERESTART 8INFOЗавершено копирование информации словаря
Completed copying distribution informationNODERESTART 8INFOЗавершено копирование информации распределения
Starting to copy fragmentsNODERESTART8 INFOНачало копирования фрагментов
Completed copying a fragmentNODERESTART10 INFOЗавершение копирования фрагментов
Completed copying all fragmentsNODERESTART8 INFOЗавершение копирования ВСЕХ фрагментов
Node failure phase completedNODERESTART8 ALERTЗавершена ситуация сбоя узла
Node has failed, node state was XNODERESTART8 ALERTУзел начал сбоить
Report whether an arbitrator is found or notNODERESTART 6INFO7 различных ситуаций
- Координатор перезапускает поток арбитража [состояние=X]
- Подготовка узла арбитратора X [ticket=Y]
- Принять узел арбитратора X [ticket=Y]
- Запустить узел арбитратора X [ticket=Y]
- Потерян узел арбитратора X: обрабатывает сбой [состояние=Y]
- Потерян узел арбитратора X: обрабатывает выход [состояние=Y]
- Потерян узел арбитратора X <сообщение_об_ошибке>[состояние=Y]
Report arbitrator resultsNODERESTART2 ALERT8 разных результатов
- Потерянная проверка арбитража: меньше половины узлов доступны
- Проверка арбитража: узлы сгруппированы как надо
- Потерянная проверка Арбитража: отсутствующая группа узла
- Выделение разделов сети по требованию арбитража
- Положительный ответ из узла X
- Арбитраж потерян: отрицательный ответ из узла X
- Разрыв сети: никакой арбитратор сейчас не доступен
- Разрыв сети: нет конфигурации для арбитратора
GCP take over startedNODERESTART7 INFOGCP запущен
GCP take over completedNODERESTART7 INFOGCP завершен
LCP take over startedNODERESTART7 INFOLCP запущен
LCP take completed (state = X)NODERESTART7 INFOLCP завершен с состоянием X
Report transaction statisticsSTATISTICS8 INFOКоличество транзакций, завершений транзакции, чтений, простых чтений, записей, параллельных операций, работ с информацией атрибутов, аварийных прекращений работы
Report operationsSTATISTICS8INFO Число проделанных операций
Report table createSTATISTICS7 INFOСоздана таблица отчета
Report job scheduling statisticsSTATISTICS9 INFOОзначает внутреннюю работу, планирующую статистику
Sent # of bytesSTATISTICS9INFO Среднее количество байт, посланных узлу X
Received # of bytesSTATISTICS9 INFOСреднее количество байт, полученных от узла X
Memory usageSTATISTICS5INFO Использование памяти данными и индексом (80%, 90% и 100%)
Transporter errorsERROR2ERROR Ошибки транспортера
Transporter warningsERROR8 WARNINGПредупреждения транспортера
Missed heartbeatsERROR8WARNING Узел X пропустил синхронизацию Y
Dead due to missed heartbeatERROR8 ALERTУзел X объявлен зависшим по причине пропуска синхронизации
General warning eventsERROR2WARNING Общие события предупреждений
Sent heartbeatINFO12INFO Синхронизация послана узлу X
Create log bytesINFO11INFO Часть файла регистрации, имя файла, его размер в MB
General info eventsINFO2INFO Общие события информации

Отчет события имеет следующий формат в файлах регистрации:

<Дата & время в GMT> [<строка>]
<серьезность события> -- <сообщение файла регистрации>

Пример отчета о событии:

09:19:30 2003-04-24 [NDB] INFO -- Node 4 Start phase 4 completed

5.3 Однопользовательский режим работы

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

Когда кластер вошел в режим отдельного пользователя, доступ к базе данных предоставлен только определенному узлу API. Пример:

ENTER SINGLE USER MODE 5

После выполнения этой команды, узел API с идентификатором узла 5 становится единственным пользователем кластера.

Узел, определенный в команде, выше должен быть узлом сервера MySQL. Любая попытка определять любой другой тип узла будет отклонена.

Обратите внимание: если узел с идентификатором 5 выполняется, когда выполнена команда ENTER SINGLE USER MODE 5, все транзакции, выполняющиеся на узле 5, будут прерваны, подключение закрыто, а сервер должен быть перезапущен.

Команда EXIT SINGLE USER MODE изменяет состояние кластера на многопользовательский режим работы. Серверам MySQL, ждущим подключения, теперь разрешают соединиться. Сервер MySQL, обозначенный как отдельный пользователь, продолжает выполняться, если он подключен к кластеру в течение и после изменения его состояния. Пример:

EXIT SINGLE USER MODE

Лучше всего в случае сбоев узла при выполнении в режиме отдельного пользователя:

  1. Закончить все транзакции режима отдельного пользователя.
  2. Выйти из режима отдельного пользователя.
  3. Перезапустить узлы базы данных.

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

5.4 Резервирование MySQL Cluster

Этот раздел описывает, как создать резервную копию и позже восстановить из нее базу данных.

5.4.1 Концепция резервирования кластера

Копия представляет собой снимок (образ) базы данных в данное время. Копия содержит три основных части:

  1. Метаданные (какие таблицы существуют и т. п.).
  2. Записи таблиц (данные в таблицах).
  3. Файл регистрации совершенных транзакций.

Каждая из этих частей сохранена на всех узлах, участвующих в копировании.

В течение резервирования каждый узел сохраняет эти три части на диск в три файла:

BACKUP-<BackupId>.<NodeId>.ctl
Управляющий файл, который содержат управляющую информацию и метаданные.
BACKUP-<BackupId>-0.<NodeId>.data
Файл данных, который содержат записи таблиц.
BACKUP-<BackupId>.<NodeId>.log
Журнал, которые содержат совершенные транзакции.

Выше <BackupId> задает идентификатор для копии, и <NodeId> идентификатор узла, создающего файл.

Метаданные
Метаданные состоят из определений таблицы. Все узлы имеют точно те же самые определения таблицы, сохраненные на диске.
Записи таблицы
Записи таблицы сохранены пофрагментно. Каждый фрагмент содержит заголовок, который описывает, которой таблице принадлежат записи. После списка записей имеется хвост, который содержит контрольную сумму для записей. Различные узлы сохраняют различные фрагменты в ходе изготовления копии.
Совершенные транзакции
Перечень совершенных транзакций содержит все транзакции, сделанные в ходе копирования. Только транзакции на таблицах, сохраненных в копии, будут сохранены в файле регистрации. Различные узлы в копии сохраняют различные записи файла регистрации, поскольку они ведут разные фрагменты базы данных.

5.4.2 Использование сервера управления, чтобы создать копию

Прежде чем начать, удостоверьтесь, что кластер правильно сконфигурирован для резервного копирования.

  1. Запустите уцправляющий сервер.
  2. Выполните команду START BACKUP.
  3. Сервер управления ответит ``Start of backup ordered''. Это означает, что сервер управления представил на рассмотрение запрос к кластеру, но еще не получил никакого ответа.
  4. Сервер управления ответит ``Backup <BackupId> started'', где <BackupId> задает уникальный идентификатор для этой специфической копии. Это будет также сохранено в файле регистрации кластера (если он не сконфигурирован иначе). Это означает, что кластер получил и обработал запрос. Это не означает, что копия уже завершена.
  5. Сервер управления сообщит ``Backup <BackupId> completed'', когда копия закончена.

Использование сервера управления, чтобы прервать копию:

  1. Запустите уцправляющий сервер.
  2. Выполните команду ABORT BACKUP <BACKUPID>. Здесь <BackupId> задает идентификатор копии, который был включен в ответ серверу управления, когда копия начата, то есть в сообщение ``Backup <BackupId> started''. Идентификатор также сохранен в файле регистрации кластера (cluster.log).
  3. Сервер управления ответит ``Abort of backup <BackupId> ordered''. Это означает, что он представил на рассмотрение запрос кластеру, но не получил никакого ответа.
  4. Сервер управления ответит ``Backup <BackupId> has been aborted reason XYZ''. Это означает, что кластер прервал копию и удалил все к ней относящееся, включая файлы в файловой системе.

Обратите внимание, что, если не имеется копии с идентификатором <BackupId>, выполняющейся на момент попытки прерывания, сервер управления не будет отвечать ничего.

5.4.3 Восстановление из резервной копии

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

Первый раз, когда Вы выполняете программу восстановления, Вы также должны восстановить метаданные, то есть создать таблицы. Действия программы восстановления рассматриваются как обращение API к кластеру и, следовательно, нуждаются в свободном подключении, чтобы соединиться с кластером. Это может быть проверено через ndb_mgm командой SHOW. Переключатель -c <connectstring> может использоваться, чтобы указать узел MGM. Файлы с резервной копией должны присутствовать в каталоге, заданном как параметр программы восстановления. Копия может быть восстановлена в базу данных с иной конфигурацией, чем та, из которой резервировались данные. Например, допустим, что копия (с идентификатором 12) создана на кластере с двумя узлами базы данных (с идентификаторами узлов 2 и 3), а должна быть восстановлена на кластере с четырьмя узлами. Программа восстановления должна быть выполнена два раза (по одному для каждого узла базы данных в кластере, где копия создавалась, как описано ниже.

Обратите внимание: для быстрого восстановления, данные могут быть восстановлены паралелльно (если имеется достаточно свободных подключений API). Обратите внимание, однако, что файлы данных должны всегда обрабатываться перед файлами регистрации!

Еще обратите внимание: кластер должен иметь пустую базу данных перед началом процесса восстановления.

5.4.4 Конфигурации для резервирования

Имеются четыре параметра конфигурации для резервирования:

BackupDataBufferSize
Объем памяти (из общей памяти) используемый, чтобы буферизовать данные прежде, чем они будут записаны на диск.
BackupLogBufferSize
Объем памяти (из общей памяти) используемый, чтобы буферизовать записи файла регистрации прежде, чем они будут записаны на диск.
BackupMemory
Общая память, распределенная в узле базы данных для изготовления копии. Это должно быть суммой памяти, распределенной для двух буферов.
BackupWriteSize
Размер блоков, записанных на диск. Это совместно применяется к буферам данных и файлов регистрации.

5.4.5 Проблемы резервирования

Если при выдаче запроса на резервирование возвращен код ошибки, то проверьте, что имеется достаточно памяти, распределенной для копирования (то есть, параметры конфигурации). Также проверьте, что имеется достаточно пространства в разделе жесткого диска-адресате.

6 Использование высокоскоростных межсоединений в MySQL Cluster

Уже перед разработкой NDB Cluster в 1996 было очевидно, что одной из главных проблем формирования параллельных баз данных является связь между узлами в сети. Таким образом, с самого начала NDB Cluster был разработан с концепцией транспортера, чтобы учесть различные сетевые среды.

В настоящее время основание кода включает 4 различных транспортера, где 3 из них в настоящее время работают. Большинство пользователей сегодня использует TCP/IP через Ethernet, так как это существует на всех машинах. Это также наиболее проверенный транспортер в MySQL Cluster.

Для пользователей, которые желают максимальной эффективности, возможно использовать быстрые связи в кластере. Имеются два способа достигнуть этого: может быть разработан транспортер, чтобы обработать этот случай, или можно использовать реализации сокетов, которые обходят стек TCP/IP.

Авторы пакета сделали некоторые эксперименты с обоими вариантами, использующими технологию SCI, разработанную Dolphin (www.dolphinics.no).

6.1 Настройка MySQL Cluster для использования сокетов SCI

В этом разделе мы покажем, как можно использовать кластер, сконфигурированный для нормальной связи через TCP/IP, чтобы взамен использовать сокеты SCI. Эта документация основана на сокетах SCI (они также часто упоминаются как SCI Socket) версии 2.3.0 от 1 октября 2004.

Для использования сокетов SCI можно использовать любую версию MySQL Cluster. Тесты выполнялись на версии 4.1.6. Никакой специальной версии не компилируется, так как это использует нормальные обращения сокета, что является нормальной установкой конфигураций для MySQL Cluster. SCI Sockets в настоящее время обеспечиваются только ядрами Linux 2.4 и 2.6. SCI-транспортеры работает на большем количестве OS, хотя проверена только Linux 2.4.

Имеются по существу четыре вещи, необходимые, чтобы запустить сокеты SCI. Сначала необходимо сформировать библиотеки SCI. Затем SCI-библиотеки ядра должны быть установлены. Далее один или два файла конфигурации должны быть установлены. Наконец, SCI-библиотека ядра должна быть включена для всей машины или хотя бы для оболочки, где процессы запущены процессы MySQL Cluster. Этот процесс должен быть повторен для каждой машины в кластере, который будет использовать сокеты SCI.

Два пакета должны быть установлены, чтобы получить работающие сокеты SCI. Первый пакет формирует библиотеки, которые собственно работают с сокетами, а второй интерфейс сокетов с ОС. В настоящее время они доступны только в формате исходного текста.

Последние версии этих пакетов в настоящее время могут быть найдены на http://www.dolphinics.no/support/downloads.html.

Версии, описанные здесь:

http://www.dolphinics.no/ftp/source/DIS_GPL_2_5_0_SEP_10_2004.tar.gz
http://www.dolphinics.no/ftp/source/SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz

Следующий шаг должен распаковать архивы, SCI Sockets распакован ниже уровня кода DIS. Затем основание кода компилируется. Пример ниже показывает команды, используемые в Linux/x86, чтобы выполнить это.

shell> tar xzf DIS_GPL_2_5_0_SEP_10_2004.tar.gz
shell> cd DIS_GPL_2_5_0_SEP_10_2004/src/
shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz
shell> cd ../adm/bin/Linux_pkgs
shell> ./make_PSB_66_release

Если Вы используете AMD64, чтобы использовать 64-разрядные расширения, надо использовать make_PSB_66_X86_64_release вместо make_PSB_66_release. При работе на Itanium соответственно вызовите make_PSB_66_IA64_release. Вариант X86-64 должен работать и на Intel EM64T, но никакие известные тесты этого не проводились.

После формирования основания кода, он должен быть помещен в tar-архив с именем, отражающим DIS, OS и дату. Теперь настало время, чтобы установить пакет в соответствующее место. В этом примере мы поместим установку в каталог /opt/DIS. Эти действия наиболее вероятно требуют, чтобы Вы вошли в систему как пользователь root:

shell> cp DIS_Linux_2.4.20-8_181004.tar.gz /opt/
shell> cd /opt
shell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gz
shell> mv DIS_Linux_2.4.20-8_181004 DIS

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

Имеются три типа сетевых структур. Первый простое одномерное кольцо, второй использует коммутаторы SCI с одним кольцом на порт коммутатора и в заключение имеется 2D/3D тор. Каждый вариант имеет свой стандарт обеспечения идентификаторов узла.

Простое кольцо использует идентификаторы узла через 4:

4, 8, 12, ....

Следующая возможность использует коммутатор. SCI-коммутатор имеет 8 портов, причем каждый порт может обрабатывать кольцо. Здесь необходимо гарантировать, что кольца на коммутаторе используют различные наборы идентификатора узла. Так что первый порт использует идентификаторы узла ниже 64, следующие 64 идентификатора узла распределены для второго порта и т.д.:

4,8, 12, ... , 60  Кольцо на порте 1
68, 72, .... , 124 Кольцо на порте 2
132, 136, ..., 188 Кольцо на порте 3
..
452, 456, ..., 508 Кольцо на порте 8

2D/3D тор в сетевой структуре принимает во внимание, где каждый узел находится в каждой размерности, добавляя 4 для каждого узла в первой размерности, 64 во второй и 1024 в третьей размерности.

В нашем тестировании мы использовали коммутаторы. Большинство действительно больших инсталляций кластера использует торы. Свойство дополнительного пространства, которое обеспечивают коммутаторы в том, что с двойными SCI-платами и соответственно коммутаторами можно легко сформировать избыточную сеть, где потери времени в SCI-сети составят около 100 микросекунд. Это свойство обеспечивается SCI-транспортером и в настоящее время также разработано для реализации сокетов SCI.

Потери времени для торов также возможны, поскольку эта схема сети требует отправки новых индексов маршрутизации всем узлам. Задержка составляет около 100 миллисекунд, что обычно вполне допустимо.

Помещая NDB-узлы в соответствующих местах в архитектуре, возможно использовать пару коммутаторов, чтобы формировать структуру, где 16 компьютеров могут быть взаимосвязаны, и никакой одиночный сбой не сможет препятствовать больше, чем один компьютеру. С 32 компьютерами и 2 коммутаторами можно сконфигурировать кластер таким способом, что никакой одиночный сбой не сможет препятствовать больше, чем двум узлам, и в этом случае также известно, которая пара повреждена. Таким образом, помещая узлы в отдельных группах NDB-узлов можно сформировать безопасную установку MySQL Cluster.

Чтобы установить идентификатор узла SCI-платы, используйте следующую команду, которая находится в каталоге /opt/DIS/sbin. Здесь -c 1 относится к количеству SCI-плат в машине, 1 применяется только, если 1 плата находится в машине. В этом случае всегда используйте адаптер 0 (-a 0). 68 задает идентификатор узла в этом примере:

shell> ./sciconfig -c 1 -a 0 -n 68

В случае, если Вы имеете несколько SCI-плат в вашей машине, надо понять, какая плата соответствует каждому номеру адаптера. Для этого скомвндуйте:

shell> ./sciconfig -c 1 -gsn

Это даст серийный номер, который может быть найден на задней части SCI-платы и на плате непосредственно. Повторите это затем для -c 2 и так далее для всех плат. Это идентифицирует, какая карта какому id соответствует. Затем установите идентификаторы узла для всех плат.

Теперь мы установили необходимые библиотеки и двоичные модули. Мы также установили SCI-идентификаторы узла. Следующий шаг должен установить отображение имен машин (или адресов IP) к SCI-идентификаторам узла.

Файл конфигурации для сокетов SCI должен быть помещен в /etc/sci/scisock.conf. Этот файл содержит отображение имен (или IP) на SCI-идентификаторы узлов. SCI-идентификатор узла отобразится на имя, чтобы связаться через соответствующую SCI-плату. Ниже показан очень простой такой файл конфигурации:

#host           #nodeId
alpha           8
beta            12
192.168.10.20   16

Также возможно ограничить эту конфигурацию, чтобы опрашивать только некое подмножество портов этих машин. Чтобы сделать это, используется другая конфигурация, которая помещена в /etc/sci/scisock_opt.conf:

#-key                        -type        -values
EnablePortsByDefault                      yes
EnablePort                  tcp           2200
DisablePort                 tcp           2201
EnablePortRange             tcp           2202 2219
DisablePortRange            tcp           2220 2231

Теперь мы готовы установить драйверы. Мы должны сначала установить драйверы низкого уровня, а уж затем драйвер SCI-сокетов:

shell> cd DIS/sbin/
shell> ./drv-install add PSB66
shell> ./scisocket-install add

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

shell> cd /opt/DIS/sbin/
shell> ./status.sh

Если Вы обнаруживаете ошибку и должны изменить файлы конфигурации SCI, затем необходимо использовать программу ksocketconfig, чтобы сменить конфигурацию.

shell> cd /opt/DIS/util
shell> ./ksocketconfig -f

Чтобы проверить, что сокеты SCI фактически используются, Вы можете использовать программу latency_bench, которая должна иметь клиентский и серверный компоненты, чтобы проверить время ожидания. Прежде, чем Вы используете эту программу, Вы также должны установить переменную LD_PRELOAD, как показано ниже.

Установите сервер командой:

shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -server

Теперь запустите клиент:

shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -client hostname_of_server

Теперь конфигурация SCI завершена. MySQL Cluster готов использовать совместно сокеты и транспортер SCI.

Следующий шаг к запуску MySQL Cluster. Чтобы включить использование сокетов SCI, необходимо установить системную переменную LD_PRELOAD перед стартом ndbd, mysqld и ndb_mgmd, чтобы те использовали сокеты SCI. Переменная LD_PRELOAD должна указывать на ядерную библиотеку для SCI Sockets.

Например, запустим ndbd в оболочке bash.

bash-shell> export LD_PRELOAD=/opt/DIS/lib/libkscisock.so
bash-shell> ndbd

Для tcsh команда чуть иная:

tcsh-shell> setenv LD_PRELOAD=/opt/DIS/lib/libkscisock.so
tcsh-shell> ndbd

Заметьте, что MySQL Cluster может использовать только ядерный вариант SCI Sockets.

6.2 Эталонные тесты низкого уровня, чтобы понять воздействие связей в кластере

Процесс ndbd имеет ряд простых конструкций, которые используются, чтобы обратиться к данным в MySQL Cluster. Есть очень простой эталонный тест, чтобы проверить эффективность каждой такой инструкции и эффект, который различные типы связи в кластере оказывают на их эффективность.

Имеются четыре метода доступа:

Primary key access
Это простой доступ к одной записи через первичный ключ. В самом простом случае одновременно обращаются только к одной записи. Это означает, что полная стоимость установки TCP/IP-сообщения и ряд издержек для переключения контекста принимается этим одиночным запросом. В пакетном случае, где, например, 32 доступа к первичному ключу представлены одним пакетом, эти 32 доступа совместно используют стоимость установки TCP/IP-сообщений и контекстных переключений (если TCP/IP для различных адресатов, естественно, ряд TCP/IP-сообщений должен быть установлен).
Unique key access
Доступ к уникальному ключу очень похож на доступ через первичный ключ за исключением того, что он выполнен как чтение индексной таблицы, сопровождаемым доступом через первичный ключ на таблице. Однако, только один запрос будет послан серверу MySQL, чтение индексной таблицы обработано процессом ndbd. Таким образом, эти запросы извлекают пользу из пакетной обработки.
Full table scan
Когда никакие индексы не существуют для поиска на таблице, выполняется полный просмотр таблицы. Это один запрос к процессу ndbd, который делит просмотр таблицы на набор параллельных просмотров на всех процессах ndbd в кластере. В будущих версиях MySQL сервер сможет использовать фильтры при таких просмотрах.
Range scan using ordered index
Когда используется упорядоченный индекс, это выполнит просмотр тем же самым способом, как полный просмотр таблицы за исключением того, что это просмотрит только те записи, которые находятся в диапазоне, используемом установкой запросов сервера MySQL. В будущих версиях специальная оптимизация гарантирует, что, когда все связанные индексные атрибуты включают все атрибуты в отдельный ключ, только один раздел будет просмотрен вместо всех сразу в параллельном режиме.

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

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

Мы выполнили тот основной эталонный тест, используя нормальный транспортер через сокеты TCP/IP и повторили его через сокеты SCI. Ниже приведены результаты для запроса 20 записей за доступ. Различие между последовательным и пакетным доступами понижается коэффициентом 3-4 при использовании записей 2kB. SCI-сокеты не тестировались с записями в 2 kB. Тесты выполнялись на кластере с 2 узлами с 2 CPU AMD MP1900+ на каждом.

Тип доступа:         Сокеты TCP/IP            Сокеты SCI
Serial pk access:    400 microseconds         160 microseconds
Batched pk access:    28 microseconds          22 microseconds
Serial uk access:    500 microseconds         250 microseconds
Batched uk access:    70 microseconds          36 microseconds
Indexed eq-bound:   1250 microseconds         750 microseconds
Index range:          24 microseconds          12 microseconds

Мы делали также другой набор тестов, чтобы проверить эффективность сокетов SCI, сравниваемых с использованием SCI-транспортера, и все это в сравнении с TCP/IP-транспортером. Все эти тесты использовали доступ через первичный ключ последовательно, многопоточно, а также одновременно многопоточно и пакетно.

Более или менее все эти тесты показали, что сокеты SCI были приблизительно на 100% быстрее TCP/IP. Транспортер SCI в большинстве случаев был быстрее сокетов SCI. Один известный случай с многими потоками в программе теста показал, что SCI-транспортер вел себя очень плохо, если использовался в процессе mysqld.

Таким образом, для большинства эталонных тестов сокеты SCI улучшают эффективность примерно вдвое, относительно TCP/IP за исключением редких случаев, когда эффективность связи не (проблема типа того, когда фильтры просмотра занимают большинство времени обработки, или когда нужны очень большие пакеты доступа через первичные ключи. В таком случае обработка CPU в процессах ndbd становится довольно большой частью стоимости.

Использование SCI-транспортера вместо SCI-сокетов представляет интерес только в связи между процессами ndbd. Использование SCI-транспортера также представляет интерес только, если CPU может быть выделен для процесса ndbd, поскольку SCI-транспортер гарантирует, что ndbd никогда не будет бездействовать. Также важно гарантировать, что ndbd имеет приоритет, установлен таким способом, что процесс не теряет в приоритете из-за работы длительное время (как может быть выполнено, блокируя процессы на CPU в Linux 2.6). Если это возможная конфигурация, процесс ndbd принесет пользы на 10-70% больше по сравнению с использованием сокетов SCI при выполнении модификаций и, вероятно, также на параллельных действиях просмотра.

Имеются несколько других реализаций оптимизированных вариантов сокетов для кластеров, рассмотренных в различных статьях. Они включают оптимизированные варианты для Myrinet, Gigabit Ethernet, Infiniband и VIA interface. Разработчики пока проверили MySQL Cluster только на сокетах SCI.

7 Ограничения MySQL Cluster в версии 4.1

Ниже приведен список известных ограничений версии 4.1 в сравнении со способами хранения MyISAM и InnoDB. В настоящее время не имеется никаких планов по их снятию в версиях ряда 4.1 (но в 5.0 или позднее они непременно будут устранены). На http://bugs.mysql.com , в категории cluster, находится список известных глюков, подлежащих ликвидации в версиях серии 4.1.

Расхождения в синтаксисе (приводящие к ошибкам при выполнении существующей прикладной программы).
  • Не все наборы символов поддерживаются.
  • Никакие префиксные индексы не работают (можно индексировать только полные поля).
  • Никакие текстовые индексы не поддерживаются.
Расхождения в ограничениях и поведении (могут приводить к ошибке при выполнении существующей прикладной программы)
  • Отсутствует частичная обратная перемотка транзакций при ошибке. В результате, например, ошибка дублирования ключа, приведет к обратной перемотке целой транзакции.
  • Есть несколько жестких ограничений, которые являются настраиваемыми, но сдерживаются доступной оперативной памятью кластера. Большинство параметров конфигурации могут быть расширены интерактивно.
    • Размер памяти базы данных и индексов, DataMemory и IndexMemory не резиновые.
    • Насколько большие транзакции могут выполняться, установлено параметром конфигурации MaxNoOfConcurrentOperations (загрузка данных, усечение и изменение таблицы обработаны особенно, выполняя несколько транзакций, и, таким образом, не имеет этого ограничения).
    • Различные ограничения связаны с таблицами и индексами, например, максимальное число упорядоченных индексов, MaxNoOfOrderedIndexes и так далее в этом же направлении.
  • Имена баз данных, таблиц и атрибутов не могут быть в ndb-таблицах столь длинными, как в других драйверах таблицы. Имена атрибутов будут усечены до 31 символам, и если они после этого окажутся не уникальными, Вы получите ошибку. Имя базы данных и имя таблицы суммарно могут быть максимум 122 символа.
  • Максимальное количество метаобъектов данных ограничено 1600 (это включает таблицы, системные таблицы, индексы и BLOB-объекты).
  • Максимальное число атрибутов на таблицу, ограничено 128.
  • Размер строки максимум 8k (не включая BLOB-конструкции).
  • Максимальное число атрибутов в ключе равно 32.
Не обеспечиваемые свойства (это не ошибки, но не все равно неприятно).
  • Конструкция внешнего ключа игнорируется (то же самое поведение имеется и у драйвера MyISAM).
  • Точки сохранения и обратная перемотка к точке сохранения игнорируются (то же самое поведение имеется и у драйвера MyISAM).
Эффективность и связанные ограничения
  • Заблокирован кэш запросов, так как он будет ошибочен, если модификация происходит на другом сервере MySQL.
  • Эффективность запроса падает из-за последовательного доступа к серверам, распределенно хранящим данные.
  • Записи в статистическом диапазоне не обеспечиваются, что дает не оптимальное планирование запросов в некоторых случаях. Используйте конструкцию USE INDEX или FORCE INDEX, чтобы не оптимальные планы запросов.
  • Уникальный хэш-индекс (созданный с помощью USING HASH) не может использоваться для доступа к таблице, если NULL задан как часть ключа.
Отсутствующие свойства системы.
  • Есть поддержка только для уровня изоляции READ_COMMITTED (InnoDB поддерживает READ_COMMITTED, REPEATABLE_READ и SERIALIZABLE).
  • Продолжительные транзакции на диск не сбрасываются (репликация работает, но это, увы, не гарантирует, что файлы регистрации непременно будут сброшены на диск при завершении транзакции).
Проблемы с несколькими серверами MySQL (не связаны с MyISAM или InnoDB).
  • Изменение таблицы не полностью блокирует ее при выполнении нескольких серверов MySQL (отсутствует распределенная блокировка таблицы).
  • MySQL Replication не будет работать правильно, если модификации выполнены на нескольких серверах MySQL. Если схема разделения базы данных выполнена в прикладном уровне, и никакие транзакции не происходят поверх этих разделов, это будет работать.
Проблемы кластера (не связаны с MyISAM или InnoDB).
  • Все машины в кластере должны использовать ту же самую архитектуру, то есть все машины, являющиеся узлами, должны оперировать числами в формате big-endian или little-endian, и Вы не можете использовать смесь обоих. Например, Вы не можете иметь узел управления, выполняющийся на PPC, который направляет работу сервера на x86-машине. Это ограничение не относится к машинам, просто выполняющим клиенты mysql, которые могут обращаться к кластеру.
  • Нет интерактивной схемы изменения (alter table, Ndb create index).
  • Нельзя интерактивно добавлять или удалять узлы в кластере.
  • При использовании нескольких серверов управления нужно дать узлам идентификатор явно в строках подключения, так как автоматическое распределение идентификаторов узлов не работает для нескольких серверов.
  • При использовании нескольких серверов управления нужно иметь ту же самую конфигурацию на всех серверах управления. Нет проверки этого условия.
  • Максимальное количество узлов памяти: 48.
  • Общий максимальное число узлов: 63 (серверы MySQL, узлы памяти и серверы для управления).

Поиск

 

Найди своих коллег!