Глава 5. Конфигурация NDB Cluster

Сервер MySQL, который является частью NDB Cluster, отличается от нормального сервера MySQL в том, что это использует механизм NDB. Этот механизм также иногда упоминается как NDBCLUSTER, хотя NDB правильней.

Чтобы избежать ненужного распределения ресурсов, сервер формируется по умолчанию с выключенным NDB . Для включения NDB необходимо изменить серверный конфигурационный файл my.cnf или запустить сервер с опцией --ndbcluster.

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

Для получения дополнительной информации о --ndbcluster и других опциях mysqld, определенных для NDB Cluster, см. раздел 5.3.9.1.

Можно использовать также NDB Cluster Auto-Installer, чтобы настроить и развернуть NDB Cluster на одном или более хостах, используя основанный на браузере GUI. Для получения дополнительной информации посмотрите раздел 4.1.

Для получения общей информации об установке NDB Cluster см. главу 4.

5.1. Быстрая испытательная установка NDB Cluster

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

Во-первых, необходимо создать каталог конфигурации такой, как /var/lib/mysql-cluster, выполняя следующую команду как системный root:

shell> mkdir /var/lib/mysql-cluster

В этом каталоге создайте файл config.ini, который содержит следующую информацию. Замените соответствующими значениями HostName и DataDir.

# file "config.ini" - showing minimal setup consisting of 1 data node,
# 1 management server, and 3 MySQL servers.
# The empty default разделы are not required, and are shown only for
# the sake of completeness.
# Data nodes must provide a hostname but MySQL Servers are not required
# to do so.
# If you don't know the hostname for your machine, use localhost.
# The DataDir parameter also has a default value, but it is recommended to
# set it explicitly.
# Note: [db], [api], and [mgm] are aliases for [ndbd], [mysqld], and [ndb_mgmd],
# respectively. [db] is deprecated and should not be used in new installations.
[ndbd default]
NoOfReplicas= 1
[mysqlddefault]
[ndb_mgmd default]
[tcp default]
[ndb_mgmd]
HostName= myhost.example.com
[ndbd]
HostName= myhost.example.com
DataDir= /var/lib/mysql-cluster
[mysqld]
[mysqld]
[mysqld]

Можно теперь запустить сервер управления ndb_mgmd. По умолчанию это пытается читать файл config.ini в его текущем рабочем каталоге, поэтому измените местоположение в каталог, где файл расположен, затем вызовите ndb_mgmd:

shell> cd /var/lib/mysql-cluster
shell> ndb_mgmd

Запустите единственный узел данных ndbd:

shell> ndbd

Для параметров командной строки, которые могут использоваться, начиная ndbd, см. раздел 6.32.

По умолчанию ndbd ищет сервер управления в localhost на порту 1186.

Если вы установили MySQL из архива, необходимо будет определить путь ndb_mgmd и ndbd явно. Обычно они будут найдены в /usr/local/mysql/bin.

Наконец, измените местоположение к каталогу данных MySQL (обычно это /var/lib/mysql или /usr/local/mysql/data) и удостоверьтесь, что my.cnf содержит выбор, необходимый, чтобы позволить механизм хранения NDB:

[mysqld]
ndbcluster

Можно теперь начать сервер MySQL как обычно:

shell> mysqld_safe --user=mysql &

Ждите, чтобы удостовериться, что сервер MySQL работает правильно. Если вы видите уведомление mysql ended, проверьте серверный файл .err.

Если все подходило до сих пор, теперь можно начать использовать кластер. Соединитесь с сервером и проверьте, что NDBCLUSTER включен:

shell> mysql
Welcome to the MySQL monitor.Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.7.30
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> SHOW ENGINES\G
...
*************************** 12. row ***************************
Engine: NDBCLUSTER
Support: YES
Comment: Clustered, fault-tolerant, memory-based tables
*************************** 13. row ***************************
Engine: NDB
Support: YES
Comment: Alias for NDBCLUSTER
...

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

Попытайтесь создать таблицу NDBCLUSTER:

shell> mysql
mysql> USE test;
Database changed
mysql> CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.09 sec)
mysql> SHOW CREATE TABLE ctest \G
*************************** 1. row ***************************
  Table: ctest
Create Table: CREATE TABLE `ctest` (`i` int(11) default NULL)
ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

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

shell> ndb_mgm

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

ndb_mgm> SHOW
Cluster Configuration
---------------------
[ndbd(NDB)] 1 node(s)
id=2@127.0.0.1(версия 5.7.29-ndb-7.5.17, Nodegroup: 0, *)
[ndb_mgmd(MGM)] 1 node(s)
id=1@127.0.0.1(версия 5.7.29-ndb-7.5.17)
[mysqld(API)] 3 node(s)
id=3@127.0.0.1(версия 5.7.29-ndb-7.5.17)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)

В этом пункте вы успешно настроили работу NDB Cluster. Можно теперь хранить данные в нем при помощи любой таблицы, составленной с ENGINE=NDBCLUSTER или ENGINE=NDB.

5.2. Обзор параметров кластерной конфигурации NDB, вариантов и переменных

Следующие несколько секций предоставляют сводные таблицы параметров конфигурации узла NDB Cluster, используемых в файле config.ini, чтобы управлять различными аспектами поведения узла, а также вариантов и переменных, прочитанных mysqld из файла my.cnf или из командной строки, когда управляется как процесс NDB Cluster. Каждая из таблиц параметров узла перечисляет параметры для данного типа (ndbd, ndb_mgmd, mysqld, computer, tcp или shm). Все таблицы включают тип данных для параметра, выбора или переменной, а также ее умолчание, минимальное и максимальное значения.

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

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

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

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

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

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

4294967039 часто появляется как максимальное значение в этих таблицах. Это значение определяется в NDBCLUSTER как MAX_INT_RNIL оно равно 0xFFFFFEFF или 232-28-1.

5.2.1. Параметры конфигурации узла данных NDB Cluster

Списки в этой секции предоставляют информацию о параметрах, используемых в разделах [ndbd] или [ndbd default] файла config.ini для формирования узлов данных NDB Cluster. Для подробных описаний и другой дополнительной информации о каждом из этих параметров, посмотрите раздел 5.3.6.

Эти параметры также относятся к ndbmtd, многопоточной версии ndbd. Для получения дополнительной информации посмотрите раздел 6.3.

Следующие параметры определены для ndbmtd:

5.2.2. Параметры конфигурации узла управления NDB Cluster

Листинг в этой секции предоставляет информацию о параметрах, используемых в секциях [ndb_mgmd] или [mgm] файла config.ini для формирования узлов управления NDB Cluster. Для подробных описаний и другой дополнительной информации о каждом из этих параметров посмотрите раздел 5.3.5.

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

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

5.2.3. Параметры конфигурации NDB Cluster для узлов SQL и API

Листинг в этой секции предоставляет информацию о параметрах, используемых в разделах [mysqld] и [api] файла config.ini для формирования узлов SQL и API. Для подробных описаний и другой дополнительной информации о каждом из этих параметров посмотрите раздел 5.3.7.

Для обсуждения возможностей сервера MySQL для NDB Cluster см. раздел 5.3.9.1 . Для получения информации о системных переменных сервера MySQL, касающихся NDB Cluster, см. раздел 5.3.9.2.

Чтобы добавить новый узел SQL или API к конфигурации управления NDB Cluster, необходимо выполнить катящийся перезапуск всех узлов после добавления нового раздела [mysqld] или [api] в файл config.ini (или файлы, если вы используете больше, чем один сервер управления). Это должно быть сделано прежде, чем новый узел сможет соединиться с кластером.

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

5.2.4. Другие параметры конфигурации NDB Cluster

Списки в этой секции предоставляют информацию о параметрах, используемых в разделах [computer], [tcp] и [shm] файла config.ini для формирования NDB Cluster. Для подробных описаний и дополнительной информации об отдельных параметрах посмотрите разделы 5.3.10 и 5.3.12.

Следующие параметры относятся к разделу [computer] файла config.ini:

Следующие параметры относятся к разделу [tcp] файла config.ini:

Следующие параметры относятся к разделу [shm] файла config.ini:

5.2.5. Опции и переменные NDB Cluster mysqld

Следующая таблица предоставляет список параметров командной строки, сервера и переменных статуса, применимых в mysqld, когда это работает как узел SQL в NDB Cluster. Для таблицы, показывающей ВСЕ параметры командной строки, сервера и переменные статуса, доступные для использования с mysqld, см. Server Option, System Variable, and Status Variable Reference.

5.3. Файлы кластерной конфигурации NDB

Формирование NDB Cluster требует работы с двумя файлами:

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

Файлы кэша конфигурации. Сервер управления по умолчанию создает файлы кэша конфигурации в каталоге mysql-cluster в инсталляционном каталоге MySQL. Если вы собираете NDB Cluster в Unix из исходных текстов, местоположение по умолчанию /usr/local/mysql-cluster. Это может быть отвергнуто во времени выполнения, начав сервер управления с опцией --configdir. Файлы кэша конфигурации это двоичные файлы, названные согласно образцу ndb_ node_id_config.bin.seq_id , где node_id это ID узла сервера управления в кластере, а seq_id это идентиификатор кэша. Файлы кэша пронумерованы, последовательно используя seq_id, в порядке, в котором они создаются. Сервер управления использует последний файл кэша, как определено seq_id .

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

Для получения дополнительной информации об опциях --configdir, --config-cache, --initial и --reload для сервера управления NDB Cluster см. раздел 6.4.

Мы непрерывно делаем улучшения кластерной конфигурации и пытаемся упростить этот процесс. Хотя мы стремимся поддержать обратную совместимость, могут быть времена, когда вводят несовместимое изменение. В таких случаях мы попытаемся сообщить пользователям заранее, если изменение не будет обратно совместимо. Если вы находите такое изменение, и мы не зарегистрировали его, пожалуйста, сообщите о нем в базе данных ошибок MySQL, используя инструкции в How to Report Bugs or Problems.

5.3.1. Кластерная конфигурация NDB: основной пример

Чтобы поддержать NDB Cluster, необходимо будет обновить my.cnf как показано в следующем примере. Можно также определить эти параметры в командной строке.

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

# my.cnf
# example additions to my.cnf for NDB Cluster
# (valid in MySQL 5.7)
# enable ndbcluster storage engine, and provide connection string for
# management server host (default port is 1186)
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com
# provide connection string for management server host (default port: 1186)
[ndbd]
connect-string=ndb_mgmd.mysql.com
# provide connection string for management server host (default port: 1186)
[ndb_mgm]
connect-string=ndb_mgmd.mysql.com
# provide location of cluster configuration file
[ndb_mgmd]
config-file=/etc/config.ini

Для получения дополнительной информации о строках подключения посмотрите раздел 5.3.3.

# my.cnf
# example additions to my.cnf for NDB Cluster
# (will work on all versions)
# enable ndbcluster storage engine, and provide connection string for management
# server host to the default port 1186
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com:1186

Как только вы начали процесс mysqld с параметрами NDBCLUSTER и ndb-connectstring в секции [mysqld] файла my.cnf как показано ранее, вы не можете выполнить CREATE TABLE или ALTER TABLE не запустив кластер на самом деле. Иначе эти запросы потерпят неудачу с ошибкой.

Можно также использовать отдельный раздел [mysql_cluster] в файле my.cnf для параметров настройки, которые будут читаться и использоваться всеми исполняемыми файлами:

# cluster-specific settings
[mysql_cluster]
ndb-connectstring=ndb_mgmd.mysql.com:1186

Для поучения списка дополнительных переменных NDB, которые могут быть установлены в файле my.cnf, см. раздел 5.3.9.2.

Глобальный конфигурационный файл NDB Cluster в соответствии с соглашением называется config.ini (но это не обязательно). В случае необходимости это прочитано ndb_mgmd при запуске и может быть помещено в любое место, которое может быть прочитано им. Место и название конфигурации определяются, используя опцию --config-file= path_name с ndb_mgmd в командной строке. Этот выбор не имеет никакого значения по умолчанию и проигнорирован, если ndb_mgmd использует кэш конфигурации.

Глобальный конфигурационный файл для NDB Cluster использует INI-формат, который состоит из секций, которым предшествуют заголовки раздела (окруженные квадратными скобками), сопровождаемые соответствующими названиями параметра и значениями. Одно отклонение от стандартного формата INI: название параметра и значение могут быть отделены двоеточием a colon (:), а также знак "равно" (=), однако, знак "равно" предпочтен. Другое отклонение: секции не однозначно определяются именем секции. Вместо этого уникальные секции (такие как два различных узла того же самого типа) определяются уникальным идентификатором, определенным в качестве параметра в разделе.

Значения по умолчанию определяются для большинства параметров и могут быть также определены в config.ini. Чтобы создать секцию значения по умолчанию, просто добавьте слово default к имени секции. Например, раздел [ndbd] содержит параметры, которые относятся к конкретному узлу данных, тогда как раздел [ndbd default] содержит параметры, которые относятся ко всем узлам данных. Предположим, что все узлы данных должны использовать тот же самый размер памяти данных. Чтобы формировать их все, создайте раздел [ndbd default], который содержит строку DataMemory, чтобы определить размер памяти данных.

Если используется раздел [ndbd default], должен предшествовать любому разделу [ndbd] в конфигурационном файле. Это также верно для разделов default любого другого типа.

В некоторых более старых выпусках NDB Cluster не было никакого значения по умолчанию для NoOfReplicas, который всегда должен был определяться явно в [ndbd default]. Хотя у этого параметра теперь есть значение по умолчанию 2, которое является рекомендуемым в наиболее распространенных сценариях использования, все еще рекомендуют практику, чтобы установить этот параметр явно.

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

# file "config.ini" - 2 data nodes and 2 SQL nodes
# This file is placed in the startup directory of ndb_mgmd (the
# management server)
# The first MySQL Server can be started from any host. The second
# can be started only on the host mysqld_5.mysql.com
[ndbd default]
NoOfReplicas= 2
DataDir= /var/lib/mysql-cluster
[ndb_mgmd]
Hostname= ndb_mgmd.mysql.com
DataDir= /var/lib/mysql-cluster
[ndbd]
HostName= ndbd_2.mysql.com
[ndbd]
HostName= ndbd_3.mysql.com
[mysqld]
[mysqld]
HostName= mysqld_5.mysql.com

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

У каждого узла есть своя собственная секция в файле config.ini. Например, у этого кластера есть два узла данных, таким образом, предыдущий конфигурационный файл содержит два раздела [ndbd], определяющих эти узлы.

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

Разделы файла config.ini

Есть шесть различных секций, которые можно использовать в конфигурационном файле config.ini, как описано в следующем списке:

Можно определить значения default для каждой секции. Если используется, раздел default должен быть перед любыми другими разделами того типа. Например, [ndbd default] должен появиться в конфигурационном файле перед любым разделом [ndbd].

Названия параметров NDB Cluster нечувствительны к регистру, если не определено в файлах MySQL Server my.cnf или my.ini.

5.3.2. Рекомендуемая стартовая конфигурация для NDB Cluster

Достижение лучшей работы NDB Cluster зависит от ряда факторов, включая следующие:

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

Стартовый файл config.ini. Следующий файл config.ini это рекомендуемая отправная точка для формирования NDB Cluster 7.5:

# TCP PARAMETERS
[tcp default]
SendBufferMemory=2M
ReceiveBufferMemory=2M
# Increasing the sizes of these 2 buffers beyond the default values
# helps prevent bottlenecks due to slow disk I/O.
# MANAGEMENT NODE PARAMETERS

[ndb_mgmd default]
DataDir=path/to/management/server/data/directory
# It is possible to use a different data directory for each management
# server, but for ease of administration it is preferable to be consistent.

[ndb_mgmd]
HostName=management-server-A-hostname
# NodeId=management-server-A-nodeid

[ndb_mgmd]
HostName=management-server-B-hostname
# NodeId=management-server-B-nodeid
# Using 2 management servers helps guarantee that there is always an
# arbitrator in the event of network partitioning, and so is
# recommended for high availability. Each management server must be
# identified by a HostName. You may for the sake of convenience specify
# a NodeId for any management server, although one will be allocated
# for it automatically; if you do so, it must be in the range 1-255
# inclusive and must be unique among all IDs specified for cluster nodes.

# DATA NODE PARAMETERS
[ndbd default]
NoOfReplicas=2
# Using 2 replicas is recommended to guarantee availability of data;
# using only 1 replica does not provide any redundancy, which means
# that the failure of a single data node causes the entire cluster to
# shut down. We do not recommend using more than 2 replicas, since 2 is
# sufficient to provide high availability, and we do not currently test
# with greater values for this parameter.
LockPagesInMainMemory=1
# On Linux and Solaris systems, setting this parameter locks data node
# processes into memory. Doing so prevents them from swapping to disk,
# which can severely degrade cluster performance.
DataMemory=3072M
IndexMemory=384M
# The values provided for DataMemory and IndexMemory assume 4 GB RAM
# per data node. However, for best results, you should first calculate
# the memory that would be used based on the data you actually plan to
# store (you may find the ndb_size.pl utility helpful in estimating
# this), then allow an extra 20% over the calculated values. Naturally,
# you should ensure that each data node host has at least as much
# physical memory as the sum of these two values.
# NOTE: IndexMemory is deprecated in NDB 7.6 and later.
# ODirect=1
# Enabling this parameter causes NDBCLUSTER to try using O_DIRECT
# writes for local checkpoints and redo logs; this can reduce load on
# CPUs. We recommend doing so when using NDB Cluster on systems running
# Linux kernel 2.6 or later.
NoOfFragmentLogFiles=300
DataDir=path/to/data/node/data/directory
MaxNoOfConcurrentOperations=100000
SchedulerSpinTimer=400
SchedulerExecutionTimer=100
RealTimeScheduler=1
# Setting these parameters allows you to take advantage of real-time scheduling
# of NDB threads to achieve increased throughput when using ndbd. They
# are not needed when using ndbmtd; in particular, you should not set
# RealTimeScheduler for ndbmtd data nodes.
TimeBetweenGlobalCheckpoints=1000
TimeBetweenEpochs=200
RedoBuffer=32M
# CompressedLCP=1
# CompressedBackup=1
# Enabling CompressedLCP and CompressedBackup causes, respectively, local
checkpoint files and backup files to be compressed, which can result in a space
savings of up to 50% over noncompressed LCPs and backups.
# MaxNoOfLocalScans=64
MaxNoOfTables=1024
MaxNoOfOrderedIndexes=256
[ndbd]
HostName=data-node-A-hostname
# NodeId=data-node-A-nodeid
LockExecuteThreadToCPU=1
LockMaintThreadsToCPU=0
# On systems with multiple CPUs, these parameters can be used to lock NDBCLUSTER
# threads to specific CPUs
[ndbd]
HostName=data-node-B-hostname
# NodeId=data-node-B-nodeid
LockExecuteThreadToCPU=1
LockMaintThreadsToCPU=0
# You must have an [ndbd] раздел for every data node in the cluster;
# each of these разделы must include a HostName. Each раздел may
# optionally include a NodeId for convenience, but in most cases, it is
# sufficient to allow the cluster to allocate node IDs dynamically. If
# you do specify the node ID for a data node, it must be in the range 1
# to 48 inclusive and must be unique among all IDs specified for
# cluster nodes.
# SQL NODE / API NODE PARAMETERS
[mysqld]
# HostName=sql-node-A-hostname
# NodeId=sql-node-A-nodeid
[mysqld]
[mysqld]
# Each API or SQL node that connects to the cluster requires a [mysqld]
# or [api] раздел of its own. Each such раздел defines a connection
# slot; you should have at least as many of these разделы in the
# config.ini file as the total number of API nodes and SQL nodes that
# you wish to have connected to the cluster at any given time. There is
# no performance or other penalty for having extra slots available in
# case you find later that you want or need more API or SQL nodes to
# connect to the cluster at the same time.
# If no HostName is specified for a given [mysqld] or [api] раздел,
# then any API or SQL node may use that slot to connect to the
# cluster. You may wish to use an explicit HostName for one connection slot
# to guarantee that an API or SQL node from that host can always
# connect to the cluster. If you wish to prevent API or SQL nodes from
# connecting from other than a desired host or hosts, then use a
# HostName for every [mysqld] or [api] раздел in the config.ini file.
# You can if you wish define a node ID (NodeId parameter) for any API or
# SQL node, but this is not necessary; if you do so, it must be in the
# range 1 to 255 inclusive and must be unique among all IDs specified
# for cluster nodes.

Рекомендуемые опции my.cnf для узлов SQL. MySQL Server, действующие как узлы SQL в NDB Cluster, должны всегда запускаться с опцией --ndbcluster и --ndb-connectstring в командной строке или в my.cnf. Кроме того, установите следующие возможности для всех процессов mysqld в кластере, если ваша установка не требует иного:

5.3.3. Строки подключения NDB Cluster

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

[nodeid=node_id, ] host-definition[, host-definition[, ...]]
host-definition:
host_name[:port_number]

node_id это целое число больше или равное 1, которое определяет узел в config.ini. host_name это последовательность, представляющая действительное интернет-имя хоста или IP-адрес. port_number целое число, относящееся к номеру порта TCP/IP.

Пример 1 (полный):  "nodeid=2, myhost1:1100, myhost2:1100,198.51.100.3:1200"
Пример 2 (краткий): "myhost1"

localhost:1186 используется в качестве значения строки подключения по умолчанию, если ничего не задано. Если port_num опущен, порт по умолчанию 1186. Этот порт должен всегда быть доступным в сети, потому что это было назначено IANA с этой целью (см. http://www.iana.org/assignments/port-numbers).

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

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

[nodeid=node_id, ]
[bind-address=host-definition, ]
host-definition[; bind-address=host-definition]
host-definition[; bind-address=host-definition]
[, ...]]
host-definition:
host_name[:port_number]

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

bind-address=198.51.100.242, poseidon:1186, perch:1186

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

poseidon:1186;bind-address=localhost, perch:1186;bind-address=198.51.100.242

В этом случае узел использует localhost, чтобы соединиться с сервером управления, работающим на хосте, poseidon, и 198.51.100.242, чтобы соединиться с сервером управления, работающим на хосте perch.

Можно определить, что умолчание связывает адрес и затем отвергает это умолчание для одного или более определенных хостов управления. В следующем примере localhost используется для соединения с сервером управления, работающим на хосте poseidon, после того, как 198.51.100.242 определяется сначала (перед любыми определениями сервера управления), это умолчание и используется для соединения с серверами управления на хостах perch и orca:

bind-address=198.51.100.242,poseidon:1186;bind-address=localhost,perch:1186,orca:2200

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

Рекомендуемый метод для определения строки подключения должен установить ее в командной строке или в файле my.cnf для каждого исполняемого файла.

5.3.4. Определение компьютеров в NDB Cluster

Раздел [computer] не имеет реального значения кроме служения в качестве способа избежать потребности определения имен хоста для каждого узла в системе. Все параметры, упомянутые здесь, требуются.

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

Таблица 5.1. Типы перезапуска NDB Cluster

Символ Тип перезапуска Описание
N Node Параметр может быть обновлен, используя катящийся перезапуск (см. раздел 7.5).
S System Все узлы должны быть закрыты полностью, затем перезапущены, чтобы вызвать изменение в этом параметре.
I Initial Узлы данных должны быть перезапущены, используя опцию --initial.

5.3.5. Определение сервера управления NDB Cluster

Раздел [ndb_mgmd] используется, чтобы формировать поведение сервера управления. Если многократные серверы управления используются, можно определить параметры, характерные для всех, в разделе [ndb_mgmd default]. [mgm] и [mgm default] это более старые псевдонимы для них, поддержанные для обратной совместимости.

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

Если ни один из параметров ExecuteOnComputer или HostName не присутствует, значение по умолчанию localhost будет принято для обоих.

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

Таблица 5.4. Типы перезапуска NDB Cluster

Символ Тип перезапуска Описание
N Node Параметр может быть обновлен, используя катящийся перезапуск (см. раздел 7.5 ).
S System Все узлы должны быть закрыты полностью, затем перезапущены, чтобы вызвать изменение в этом параметре.
I Initial Узлы данных должны быть перезапущены, используя опцию --initial.

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

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

5.3.6. Определение узлов данных NDB Cluster

Разделы [ndbd] и [ndbd default] используются, чтобы формировать поведение узлов данных.

[ndbd] и [ndbd default] всегда используются в качестве имен секции, используете ли вы ndbd или ndbmtd для процессов узла данных.

Есть много параметров, которые управляют буферными размерами, тайм-аутами, размерами пулов и т.д. Единственный обязательный параметр любой из ExecuteOnComputer или HostName, это должно быть определено в локальном разделе [ndbd].

Параметр NoOfReplicas должен быть определен в разделе [ndbd default], поскольку это характерно для всех узлов данных. Не строго необходимо установить NoOfReplicas, но это хорошая практика.

Большинство параметров узла данных устанавливаются в разделе [ndbd default]. Только тпараметрам, явно указанным как способные установить локальные значения, разрешают быть измененными в разделе [ndbd]. HostName, NodeId и ExecuteOnComputer должны быть определен локально в разделе [ndbd], а не в любом другом разделе config.ini. Другими словами, параметры настройки для этих параметров определены для одного узла данных.

Для параметров, затрагивающих использование памяти или буферные размеры, возможно использовать K, M или G как суффикс, чтобы указать на единицы 1024, 1024*1024 или 1024*1024*1024. Например, 100K это 100*1024 = 102400.

Названия параметра и значения нечувствительны к регистру, если не используются в файле my.cnf или my.ini, в этом случае они чувствительны к регистру.

Информация о параметрах конфигурации, определенных для таблиц NDB Cluster Disk Data, может быть найдена позже в этой секции (см. здесь).

Все эти параметры также относятся к ndbmtd (мультипоточной версии ndbd). Три дополнительных параметра конфигурации узла данных MaxNoOfExecutionThreads, ThreadConfig и NoOfFragmentLogParts применяются только к ndbmtd, они не имеют никакого эффекта, когда используются с ndbd. См. также раздел 6.3.

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

Таблица 5.20. Типы перезапуска NDB Cluster

Символ Тип перезапуска Описание
N Node Параметр может быть обновлен, используя катящийся перезапуск (см. раздел 7.5 ).
S System Все узлы должны быть закрыты полностью, затем перезапущены, чтобы вызвать изменение в этом параметре.
I Initial Узлы данных должны быть перезапущены, используя опцию --initial .

Идентификация узлов данных. NodeId или Id (то есть, идентификатор узла данных) может быть ассигнован в командной строке, когда узел запускается, или в конфигурационном файле.

Память данных, индекса и строк

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

IndexMemory устарело в NDB 7.6.

Следующий пример иллюстрирует, как память используется для таблицы. Рассмотрите это определение таблицы:

CREATE TABLE example (a INT NOT NULL, b INT NOT NULL, c INT NOT NULL,
                      PRIMARY KEY(a), UNIQUE(b)) ENGINE=NDBCLUSTER;

Для каждого отчета есть 12 байтов данных плюс 12 байтов заголовок. Отсутствие nullable-столбцов экономит 4 байта заголовка. Кроме того, у нас есть два упорядоченных индекса на колонках a и b с потреблением примерно 10 байтов каждый на отчет. Есть хэш-индекс первичного ключа на базовой таблице, использущий примерно 29 байтов на отчет. Ограничение на уникальность данных осуществляется отдельной таблицей b как первичный ключ и a как колонка. Эта другая таблица потребляет дополнительные 29 байтов памяти индекса на отчет в таблице example, а также 8 байтов для данных плюс 12 байтов заголовка.

Таким образом, для одного миллиона отчетов, нам нужны 58 МБ для памяти индекса, чтобы обращаться с хэш-индексами для первичного ключа и ограничения на уникальность данных. Нам также нужны 64 МБ для отчетов базовой таблицы и таблицы уникального индекса плюс два упорядоченных индекса таблицы.

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

В настоящее время единственный алгоритм разделения это хэширование, а отсортированные индексы локальны для каждого узла. Таким образом отсортированные индексы не могут использоваться, чтобы обращаться с ограничениями уникальности в общем случае.

Важный момент для обоих IndexMemory и DataMemory в том, что полный размер базы данных это сумма всей памяти данных и всей памяти индекса для каждой группы узлов. Каждая группа узлов используется, чтобы хранить копируемую информацию, поэтому если будет четыре узла с двумя точными копиями, будет две группы узлов. Таким образом полная доступная память данных является 2* DataMemory для каждого узла данных.

Настоятельно рекомендовано установить DataMemory и IndexMemory в те же самые значения для всех узлов. Распределение данных даже по всем узлам в группе, таким образом, будет максимальной суммой пространства, доступного для любого узла, значит может быть не больше, чем место из самого маленького узла в группе.

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

MinFreePct. Пропорция (5% по умолчанию) ресурсов узла данных, включая DataMemory (и в NDB 7.5 и ранее IndexMemory), сохраненная в резерве, чтобы гарантировать, что узел данных не исчерпывает свою память, выполняя перезапуск. Это может быть скорректировано, используя параметр конфигурации узла данных MinFreePct (умолчание 5).

Таблица 5.34. Эта таблица обеспечивает тип и информацию о значении для параметра конфигурации узла данных MinFreePct

Свойство Значение
Версия (или позже) NDB 7.5.0
Тип или единица измерения unsigned
Умолчание 5
Диапазон 0 - 100
Тип перезапуска N

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

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

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

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

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

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

Просмотры и буферизование. Дополнительные параметры [ndbd] в модуле Dblqh (в ndb/src/kernel/blocks/Dblqh/Dblqh.hpp) влияют чтение и обновление. Они включают ZATTRINBUF_FILESIZE, установленный по умолчанию в 10000 * 128 байт (1250KB), и ZDATABUF_FILE_SIZE, установленный по умолчанию в 10000*16 байт (примерно 156KB). До настоящего времени нет ни отчетов от пользователей, ни любых следствий наших собственных обширных тестов, предполагающих, что любой из этих пределов времени компиляции должен быть увеличен.

Выделение памяти

MaxAllocate

Таблица 5.51. Эта таблица обеспечивает тип и информацию о значении для параметра конфигурации узла данных MaxAllocate

Свойство Значение
Версия (или позже) NDB 7.5.0
Тип или единица измерения unsigned
Умолчание 32M
Диапазон 1M - 1G
Тип перезапуска N

Это максимальный размер блока памяти, чтобы использовать, ассигнуя память для таблиц. В случаях, когда NDB дает ошибку Out of memory, но очевидно, исследуя журнал или вывод DUMP 1000, что вся доступная память еще не использовалась, можно увеличить значение этого параметра (или MaxNoOfTables или вместе), чтобы предписать NDB сделать достаточную память доступной.

Размер хэш-карты

DefaultHashMapSize

Таблица 5.52. Эта таблица обеспечивает тип и информацию о значении для параметра конфигурации узла данных DefaultHashMapSize

Свойство Значение
Версия (или позже) NDB 7.5.0
Тип или единица измерения LDM threads
Умолчание 3840
Диапазон 0 - 3840
Тип перезапуска N

Размер таблицы хэш-карт, используемый NDB, настраивается этим параметром. DefaultHashMapSize может принять любое из трех возможных значений (0, 240, 3840). Эти значения и их эффекты описаны в следующей таблице:

Таблица 5.53. Параметры DefaultHashMapSize

Значение Эффект
0 Используйте самое низкое значение, если таковое имеется, для этого параметра среди всех узлов данных и узлов API, если это не установлено ни на каких узлах данных или API, используйте значение по умолчанию.
240 Оригинальный размер хэш-карты (используемый по умолчанию во всем NDB Cluster до NDB 7.2.7).
3840 Больший размер хэш-карты (используемый по умолчанию начиная с NDB 7.2.7).

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

Регистрация и контрольные точки. Следующие параметры [ndbd] управляют поведением контрольной точки и регистрации.

Объекты метаданных. Следующий набор параметров [ndbd] определяет размеры пула для объектов метаданных, используемых, чтобы определить максимальное количество признаков, таблиц, индексов и объектов, используемых индексами, событиями и репликацией.

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

Boolean-параметры. Поведение узлов данных также затронуто рядом параметров [ndbd], берущих булевы значения. Эти параметры могут быть определены как TRUE, устанавливая их равными 1 или Y, или FALSE, устанавливая их равными 0 или N.

Управляя перерывами, интервалами и дисковым оповещением

Есть много параметров [ndbd], определяющих перерывы и интервалы между различными действиями в узлах данных. Большинство значений перерыва определяется в миллисекундах. Любые исключения упоминаются, когда это применимо.

Буферизование и регистрация. Несколько параметров конфигурации [ndbd] позволяют опытному пользователю иметь больше контроля над ресурсами, используемыми процессами узла и приспособить различные буферные размеры.

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

Управление сообщениями регистрации. В управлении кластером очень важно быть в состоянии управлять количеством сообщений регистрации и следить за различными типами событий, пишущих сообщения в stdout. Для каждой категории событий есть 16 возможных уровней события (от 0 до 15). Установка для данной категории событий уровня 15 означает, что все отчеты о событиях в этой категории посылают на stdout, установка в 0 значит, что не будет никаких отчетов событий, сделанных в той категории.

По умолчанию только сообщение запуска посылают в stdout, с остающимися событиями по умолчанию с уровнями, устанавливаемыми в 0. Причина этого состоит в том, что эти сообщения также посылают в регистрацию сервера управления кластером.

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

Параметры отладки узла данных

Следующие параметры предназначаются для использования во время тестирования или отладки узлов данных, а не для использования в производстве.

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

Местоположение резервных файлов определяется параметром конфигурации узла данных BackupDataDir.

Дополнительные требования. Определяя эти параметры, следующие отношения должны сохраняться. Иначе узел данных будет неспособен стартовать.

Эксплуатационные параметры в реальном времени NDB Cluster

Параметры [ndbd] в этой секции, используются в планировании и блокировке потоков к определенным CPU на хостах узла данных.

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

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

До NDB 7.6 изменение ThreadCOnfig требует системного начального перезапуска. В NDB 7.6 и позже это требование может быть смягчено при определенных обстоятельствах:

В любом другом случае системный начальный перезапуск необходим, чтобы изменить этот параметр.

NDB 7.6.4 и позже может различать типы потоков по обоим из следующих критериев:

Простые примеры:

# Example 1.
ThreadConfig=ldm={count=2,cpubind=1,2},main={cpubind=12},rep={cpubind=11}
# Example 2.
Threadconfig=main={cpubind=0},ldm={count=4,cpubind=1,2,5,6},io={cpubind=3}

Это обычно желательно, формируя использование потока для хоста узла данных, чтобы зарезервировать один или более CPU для операционной системы и других задач. Таким образом, для хост-машины с 24 CPU вы могли бы хотеть использовать 20 потоков ЦП (оставляя 4 для другого использования) с 8 потоками LDM, 4 потоками TC (половина от количества потоков LDM), 3 потоками передачи, 3 потоками получения и по 1 потоку для управления схемами, асинхронной репликацией и операциями I/O. Это почти то же самое распределение потоков используемое, когда MaxNoOfExecutionThreads = 20. Следующая настройка ThreadConfig выполняет эти назначения, дополнительно привязывая все эти потоки к определенным CPU

ThreadConfig=ldm{count=8,cpubind=1,2,3,4,5,6,7,8},main={cpubind=9}, \
             io={cpubind=9}, rep={cpubind=10},tc{count=4, \
             cpubind=11,12,13,14},recv={count=3,cpubind=15,16,17}, \
             send{count=3,cpubind=18,19,20}

Должно быть возможно в большинстве случаев привязать основной (управление схемами) поток и поток I/O к тому же самому CPU, как мы сделали в этом примере.

Следующий пример включает группы CPU, определенные, используя cpuset и cpubind, а также использование установления приоритетов потока.

ThreadConfig=ldm={count=4,cpuset=0-3,thread_prio=8,spintime=200}, \
             ldm={count=4,cpubind=4-7,thread_prio=8,spintime=200}, \
             tc={count=4,cpuset=8-9,thread_prio=6},send={count=2, \
             thread_prio=10,cpubind=10-11}, \
             main={count=1,cpubind=10},rep={count=1,cpubind=11}

В этом случае мы создаем две группы LDM, первая использует cpubind, вторая cpuset. thread_prio и spintime установлены в те же самые значения для каждой группы. Это означает, что всего есть восемь потоков LDM. Необходимо гарантировать, что NoOfFragmentLogParts тоже 8. Четыре потока TC используют только два CPU, это возможно, используя cpuset, чтобы определить меньше CPU, чем потоков в группе. Это неверно для cpubind. Потоки передачи используют два потока через cpubind , чтобы связывать эти потоки с CPU 10 и 11. Главные потоки и потоки репликации тоже могут использовать эти CPU.

Этот пример показывает, как ThreadConfig и NoOfFragmentLogParts могли бы быть настроены для хоста с 24 CPU с гипертрейдингом, оставив CPU 10, 11, 22 и 23 доступными для функций операционной системы и прерываний:

NoOfFragmentLogParts=10
ThreadConfig=ldm={count=10,cpubind=0-4,12-16,thread_prio=9,spintime=200}, \
             tc={count=4,cpuset=6-7,18-19,thread_prio=8},send={count=1, \
             cpuset=8}, recv={count=1,cpuset=20},main={count=1, \
             cpuset=9,21}, rep={count=1,cpuset=9,21}, \
             io={count=1,cpuset=9,21,thread_prio=8},watchdog={count=1, \
             cpuset=9,21,thread_prio=9}

Следующие несколько примеров включают параметры настройки для idxbld. Первые два демонстрируют, как CPU, установленный для idxbld, может наложиться на определенные для других (постоянных) типов потоков, первый применяет cpuset, второй использует cpubind:

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
             io={cpubind=8},idxbld={cpuset=1-8}
ThreadConfig=main,ldm={count=1,cpubind=1},idxbld={count=1,cpubind=1}

Следующий пример определяет CPU для потока I/O, но не для построения индекса:

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
             io={cpubind=8}

Начиная с ThreadConfig, пример показывает привязку потоков к восьми ядрам с 1 по 8, это эквивалентно урегулированию, показанному здесь:

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
             io={cpubind=8},idxbld={cpuset=1,2,3,4,5,6,7,8}

Чтобы использовать в своих интересах расширенную стабильность, что делает ThreadConfig, необходимо гарантировать, что CPU изолированы, и что они не подвергаются прерываниям или не намечены для других задач операционной системой. На многих системах Linux можно сделать это, установив IRQBALANCE_BANNED_CPUS в /etc/sysconfig/irqbalance = 0xFFFFF0 и применив опцию загрузки isolcpus в grub.conf. Для определенной информации см. свою документацию по операционной системе.

Параметры конфигурации Disk Data. Параметры конфигурации, затрагивающие Disk Data, включают следующее:

Дисковые данные и ошибки остановки GCP. Ошибки, с которыми сталкиваются, используя дисковые таблицы данных, такие как Node nodeid killed this node because GCP stop was detected (error 2303), часто упоминаются как GCP stop errors. Такие ошибки происходят, когда журнал отката не сбрасывается на диск достаточно быстро, это обычно связано с медленным диском и недостаточной дисковой пропускной способностью.

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

В дополнение к вниманию, уделенному DiskPageBufferMemory как объяснено ранее, также очень важно установить корректно параметр DiskIOThreadPool, наличие слишком большого DiskIOThreadPool очень вероятно вызовет ошибки остановки GCP (Bug #37227).

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

Параметры для формирования распределения буферной памяти. Буферная память ассигнуется динамично из пула памяти, разделенного между всеми транспортерами, это означает, что размер буфера передачи может быть приспособлен по мере необходимости. Ранее ядро NDB использовало фиксированный размер буфера для каждого узла, который был ассигнован при старте узла и не мог быть изменен в то время, когда узел работал. Параметры конфигурации узла данных TotalSendBufferMemory и OverLoadLimit позволяют урегулирование ограничений на это выделение памяти. Для получения дополнительной информации об использовании этих параметров (а также SendBufferMemory) см. раздел 5.3.13.

См. также раздел 7.15.

Журнал отката превышает возможности обработки. Возможно управлять обработкой операций узла данных, когда слишком много времени потрачено, сбрасывая журналы отката на диск. Это происходит, когда данный поток журнала отката занимает больше времени, чем RedoOverCommitLimit секунд, больше чем RedoOverCommitCounter раз подряд, заставляя любые отложенные транзакции быть прерванными. Когда это происходит, узел API, который послал транзакцию, может обращаться с операциями, которые должны были быть переданы: либо стоять в очереди операций и повторять их, либо прервать их, как определено DefaultOperationRedoProblemAction. Параметры конфигурации узла данных для урегулирования тайм-аута и числа раз, которое это может быть превышено узлом API, описаны в следующем списке:

Управление попытками перезапуска. Возможно осуществить точный контроль над попытками перезапуска узлов данных, когда они падают, с использованием параметров It is possible to exercise finely-grained control over restart attempts by data nodes when they fail to start using the MaxStartFailRetries и StartFailRetryDelay.

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

Параметры статистики индекса NDB. Параметры в следующем списке касаются создания статистики индекса NDB.

5.3.7. Определение SQL и других узлов API в NDB Cluster

Разделы [mysqld] и [api] в файле config.ini определяет поведение серверов MySQL (узлов SQL) и других приложений (узлов API) для доступа к данным. Ни один из показанных параметров не требуется обязательно. Если никакой компьютер или имя хоста не обеспечиваются, любой хост может использовать этот узел SQL или API.

Вообще говоря, секция [mysqld] используется, чтобы указать на сервер MySQL, предоставляющий интерфейс SQL, а раздел [api] используется для приложений кроме mysqld для доступа к данным, но эти два обозначения на самом деле синонимичны: можно, например, перечислить параметры для сервера MySQL, действующего как узел SQL, в разделе [api].

Для обсуждения возможностей сервера MySQL для NDB Cluster см. раздел 5.3.9.1. Для получения информации о системных переменных сервера MySQL, касающихся NDB Cluster, см. раздел 5.3.9.2.

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

Таблица 5.175. Типы перезапуска NDB Cluster

Символ Тип перезапуска Описание
N Node Параметр может быть обновлен, используя катящийся перезапуск (см. раздел 7.5 ).
S System Все узлы должны быть закрыты полностью, затем перезапущены, чтобы вызвать изменение в этом параметре.
I Initial Узлы данных должны быть перезапущены, используя опцию --initial .

Параметры отладки узла API. Начиная с NDB 7.5.2, можно использовать ApiVerbose, чтобы позволить отладочную информацию от данного узла API. Этот параметр берет целочисленное значение. 0 умолчание, отключает такую отладку, 1 позволяет отладочную информацию в журнале кластера, 2 добавляет отладочную информацию DBDICT (Bug #20638450). См. также DUMP 1229.

Можно также получить информацию из сервера MySQL, работающего как узел SQL в NDB Cluster, применив SHOW STATUS в клиенте mysql:

mysql> SHOW STATUS LIKE 'ndb%';
+-----------------------------+----------------+
| Variable_name               | Value          |
+-----------------------------+----------------+
| Ndb_cluster_node_id         | 5              |
| Ndb_config_from_host        | 198.51.100.112 |
| Ndb_config_from_port        | 1186           |
| Ndb_number_of_storage_nodes | 4              |
+-----------------------------+----------------+
4 rows in set (0.02 sec)

Для получения информации о переменных статуса, появляющихся в выводе этого запроса, посмотрите раздел 5.3.9.3.

Чтобы добавить новык узлы SQL или API к конфигурации управления NDB Cluster, необходимо выполнить катящийся перезапуск всех узлов после добавления новых разделов [mysqld] или [api] в файл config.ini (или файлы, если вы используете больше одного сервера управления). Это должно быть сделано прежде, чем новые узлы SQL или API смогут соединиться с кластером.

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

5.3.8. Определение системы

Раздел [system] используется для параметров, относящихся к кластеру в целом. Параметр Name используется с MySQL Enterprise Monitor, ConfigGenerationNumber и PrimaryMGMNode не используются в производственных средах. Кроме тех случаев, когда NDB Cluster используется с MySQL Enterprise Monitor, не надо иметь раздел [system] в файле config.ini.

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

Таблица 5.197. Типы перезапуска NDB Cluster

Символ Тип перезапуска Описание
N Node Параметр может быть обновлен, используя катящийся перезапуск (см. раздел 7.5 )
S System Все узлы должны быть закрыты полностью, затем перезапущены, чтобы вызвать изменение в этом параметре
I Initial Узлы данных должны быть перезапущены, используя опцию --initial

Больше информации об этих параметрах может быть найдено в следующем списке:

5.3.9. Опции и переменные MySQL Server для NDB Cluster

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

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

5.3.9.1. Опции MySQL Server для NDB Cluster

Эта секция предоставляет описания вариантов сервера mysqld, касающихся NDB Cluster. Для получения информации об опциях mysqld, не определенных для NDB Cluster, и для получения общей информации об использовании mysqld, см. Server Command Options.

Для получения информации о параметрах командной строки, используемых с другими процессами NDB Cluster ( ndbd, ndb_mgmd и ndb_mgm) см. раздел 6.32. Для получения информации о параметрах командной строки, используемых с утилитами NDB (такими, как ndb_desc, ndb_size.pl и ndb_show_tables) см. главу 6.

5.3.9.2. Переменные NDB Cluster

Эта секция предоставляет подробную информацию о системных переменных сервера MySQL, которые являются определенными для NDB Cluster и NDB. Для системных переменных, не определенных для NDB Cluster, см. Server System Variables. Для получения общей информации об использовании системных переменных посмотрите Using System Variables.

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

5.3.9.3. Переменные статуса NDB Cluster

Эта секция предоставляет подробную информацию о переменных статуса сервера MySQL, которые касаются NDB Cluster и механизма хранения NDB. Для переменных статуса, не определенных для NDB Cluster, и для получения общей информации об использовании переменных статуса посмотрите Server Status Variables.

5.3.10. Соединения TCP/IP в NDB Cluster

TCP/IP это транспортный механизм по умолчанию для всех связей между узлами в NDB Cluster. Обычно не надо определять связи TCP/IP, кластер автоматически настраивает такие связи для всех узлов данных, узлов управления и узлов API или SQL.

Для исключения к этому правилу посмотрите раздел 5.3.11.

Чтобы отвергнуть параметры связи по умолчанию, необходимо определить связь, используя один или больше разделов [tcp] в файле config.ini. Каждый раздел [tcp] явно определяет связь TCP/IP между двумя узлами NDB Cluster и должен содержать как минимум параметры NodeId1 и NodeId2, а также любые перекрываемые параметры связи.

Также возможно изменить значения по умолчанию для этих параметров, устанавливая их в разделе [tcp default].

Любые Any разделы [tcp] в файле config.ini должны быть после после всех других секций в файле. Однако, это не требуется для раздела [tcp default]. Это требование известная проблема с путем, которым NDB Cluster читает файл config.ini.

Параметры связи, которые могут быть установлены в [tcp] и [tcp default]:

Типы перезапуска. Информацию о типах перезапуска, используемых описаниями параметров в этой секции:

Таблица 5.237. Типы перезапуска NDB Cluster

Символ Тип перезапуска Описание
N Node Параметр может быть обновлен, используя катящийся перезапуск (см. раздел 7.5 )
S System Все узлы кластера должны быть закрыты полностью, затем перезапущены, чтобы вызвать изменение в этом параметре
I Initial Узлы данных должны быть перезапущены, используя опцию --initial

5.3.11. Соединения TCP/IP в NDB Cluster, используя прямые связи

Подготовка кластера, используя прямые связи между узлами данных требует определения явно пересекающихся IP-адресов узлов данных, связанных в разделе [tcp] файла config.ini.

В следующем примере мы предполагаем кластер по крайней мере с четырьмя хостами, один для сервера управления, узла SQL и двух узлов данных. Кластер в целом находится в подсети 172.23.72.* LAN. В дополнение к обычным сетевым соединениям два узла данных связаны непосредственно, используя стандартный пересекающийся кабель и сообщаются друг с другом непосредственно с использованим IP-адресов в диапазоне 1.1.0.*:

# Management Server
[ndb_mgmd]
Id=1
HostName=172.23.72.20
# SQL Node
[mysqld]
Id=2
HostName=172.23.72.21
# Data Nodes
[ndbd]
Id=3
HostName=172.23.72.22
[ndbd]
Id=4
HostName=172.23.72.23
# TCP/IP Connections
[tcp]
NodeId1=3
NodeId2=4
HostName1=1.1.0.1
HostName2=1.1.0.2

HostName1 и HostName2 используются только определяя прямые связи.

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

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

5.3.12. Сопряжения с общей памятью NDB Cluster

Связи между узлами NDB cluster обычно обрабатываются, используя TCP/IP. Общая память (SHM) отличается тем, что сигналы переданы с помощью записи в память, а не в сокет. Транспортер общей памяти (SHM) может улучшить работу, уменьшая до 20% издержек, требуемых соединением по протоколу TCP, управляя узлом API (обычно узел SQL) и узлом данных вместе на том же самом хосте. Можно позволить сопряжение с общей памятью любым из этих двух способов:

Предположим, что кластер управляет узлом данных, у которого есть ID 1 и узлом SQL, имеющим ID 51 на том же самом компьютере в 10.0.0.1. Чтобы позволить связь SHM между этими двумя узлами, необходимо гарантировать, что следующие записи включены в файл кластерной конфигурации:

[ndbd]
NodeId=1
HostName=10.0.0.1
UseShm=1
[mysqld]
NodeId=51
HostName=10.0.0.1

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

Перед стартом узлов данных, которые используют связи SHM, также необходимо удостовериться, что в операционной системе на каждом компьютере, где есть такой узел данных, ассигновали достаточную память сегментам общей памяти. См. документацию для своей операционной платформы для получения информации относительно этого. В установках, где многократные хосты управляют узлом данных и узлом API, возможно позволить общую память на всех таких хостах, устанавливая UseShm в разделе [ndbd default] конфигурационного файла. Это показывают в примере позже в этой секции.

Хотя это не строго требуется, настраивая для всех связей SHM, может быть установлен один или больше следующих параметров в разделе [shm default] файла (config.ini):

Этот пример показывает простую установку со связями SHM на многих хостах в NDB Cluster, используя 3 компьютера, перечисленные здесь именем хоста, принимая показанные типы узлов:

  1. 10.0.0.0: Сервер управления

  2. 10.0.0.1: Узел данных и узел SQL

  3. 10.0.0.2: Узел данных и узел SQL

В этом сценарии каждый узел данных общается с сервером управления и с другим узлом данных, используя транспортеры TCP, каждый узел SQL использует транспортер общей памяти, чтобы общаться с узлом данных, который является местным к нему, и транспортер TCP, чтобы общаться с узлом удаленных данных. Базовая конфигурация, отражающая эту установку, представлена файлом config.ini, содержание которого показывают здесь:

[ndbd default]
DataDir=/path/to/datadir
UseShm=1
[shm default]
ShmSize=8M
ShmSpintime=200
SendBufferMemory=4M
[tcp default]
SendBufferMemory=8M
[ndb_mgmd]
NodeId=49
Hostname=10.0.0.0
DataDir=/path/to/datadir
[ndbd]
NodeId=1
Hostname=10.0.0.1
DataDir=/path/to/datadir
[ndbd]
NodeId=2
Hostname=10.0.0.2
DataDir=/path/to/datadir
[mysqld]
NodeId=51
Hostname=10.0.0.1
[mysqld]
NodeId=52
Hostname=10.0.0.2
[api]
[api]

Параметры, затрагивающие все транспортеры общей памяти, устанавливаются в разделе [shm default], они могут быть отвергнуты для каждого подключения в одном или больше разделах [shm]. Каждая такая секция должна быть связана с данной связью SHM использованием NodeId1 и NodeId2, значения, требуемые для этих параметров, являются ID узла этих двух узлов, связанных транспортером. Можно также определить узлы с использованием имени хоста HostName1 и HostName2, но эти параметры не требуются.

Узлы API, для которых не установлены никакие имена хоста, используют транспортер TCP, чтобы общаться с узлами данных, независимыми от хостов, на которых они запущены, набор параметров и значений в разделе [tcp default] конфигурационного файла относится ко всем транспортерам TCP кластера.

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

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

Таблица 5.251. Типы перезапуска NDB Cluster

Символ Тип перезапуска Описание
N Node Параметр может быть обновлен, используя катящийся перезапуск (см. раздел 7.5 )
S System Все узлы должны быть закрыты полностью, затем перезапущены, чтобы вызвать изменение в этом параметре
I Initial Узлы данных должны быть перезапущены, используя опцию --initial

5.3.13. Формирование буфера передачи NDB Cluster

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

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

5.4. Применение High-Speed Interconnects в NDB Cluster

Даже перед дизайном NDBCLUSTER в 1996 было очевидно, что одной из основных проблем, с которыми столкнутся в строительстве параллельных баз данных, будет связь между узлами в сети. Поэтому NDBCLUSTER был разработан с самого начала, чтобы разрешить использование многих различных транспортных механизмов данных. В этом руководстве мы используем термин транспортер для них.

Кодовая база NDB Cluster предусматривает четыре различных транспортера:

Большинство пользователей сегодня использует TCP/IP по Ethernet, потому что это повсеместно распространено. TCP/IP также безусловно лучше всего проверенный транспортер для использования в NDB Cluster.

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