Версия для печати

Архив документации на OpenNet.ru / Раздел "Базы данных, SQL" (Многостраничная версия)

Руководство по MySQL Cluster

Автор: Алексей Паутов

Источник: RussianLDP:MySQL

Данное руководство подготовлено Алексеем Паутовым в рамках некоммерческого проекта RussianLDP:MySQL ( http://www.botik.ru/~rldp/mysql.htm). Именно по этому адресу публикуются новые версии, а также другие материалы по MySQL.

1 Обзор MySQL Cluster

MySQL Cluster использует новый способ хранения NDB Cluster, чтобы сделать возможным выполнение нескольких серверов MySQL в кластере. Способ NDB Cluster доступен в BitKeeper для MySQL 4.1.2 и в двоичных дистрибутивах MySQL-Max 4.1.3.

В настоящее время поддерживаются операционные системы Linux, Mac OS X и Solaris. Ведутся работы по поддержке NDB Cluster на всех операционных системах, поддерживаемых MySQL, включая Windows.

Вы можете подписаться на список рассылки MySQL Cluster. Подробности на http://lists.mysql.com. Вы можете также обратиться к форумам MySQL на http://forums.mysql.com.

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

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

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

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

2 Основные концепции MySQL Cluster

NDB представляет собой сочетание свойств постоянства данных и их высокой доступности.

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

Теперь опишем, как установить MySQL Cluster, состоящий из NDB и нескольких серверов MySQL.

Кластерная часть MySQL Cluster в настоящее время конфигурируется независимо от серверов MySQL. В MySQL Cluster каждая часть кластера именуется node (узел).

Обратите внимание: узел встречается во многих контекстах, но для MySQL Cluster он является процессом. Может иметься любое число узлов на одном компьютере.

Каждый узел имеет тип, и может быть несколько узлов каждого типа в MySQL Cluster. В минимальной конфигурации кластера MySQL будут по крайней мере три узла:

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

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

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

3 Настройка MySQL Cluster

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

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

Так как сервер MySQL является частью кластера, также надо знать, как обратиться к MGM-узлу, чтобы получить данные конфигурации кластера. Заданное по умолчанию поведение: искать MGM-узел на localhost. Однако, если надо определить расположение в другом месте, это может быть выполнено в my.cnf или в командной строке сервера MySQL. Прежде, чем NDB сможет использоваться, по крайней мере один MGM-узел должен быть запущен, также как любые желательные DB-узлы.

3.1 Построение из исходного текста

NDB доступен в двоичных дистрибутивах, начиная с MySQL-Max 4.1.3 для Linux, Mac OS X и Solaris. Это еще не поддерживается под Windows, но предполагается сделать это доступным для платформы win32 в ближайшем будущем.

Если Вы выбираете сборку из исходных текстов или дерева разработки MySQL 4.1 BitKeeper, убедитесь, что использовали опцию --with-ndbcluster при выполнении configure. Вы можете взамен использовать скрипт BUILD/compile-pentium-max. Обратите внимание, что этот скрипт включает OpenSSL, так что Вы должны иметь или получить OpenSSL, чтобы все прошло нормально, иначе Вы должны будете изменить compile-pentium-max, чтобы исключить это требование. Конечно, Вы можете также только следовать стандартным командам для компилирования Вашего собственного пакета, затем выполнить обычные тесты и процедуру установки.

3.2 Установка готового пакета

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

Вы найдете конфигурацию кластера самой простой, если уже имеете все узлы MGM и DB в рабочем виде изначально, полагаю, это будет самым длительным этапом настройки. Редактирование файла my.cnf довольно просто, и этот раздел рассматривает только отличия от конфигурирования MySQL без кластеризации.

3.3 Быстрая установка и тестирование MySQL 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 DB node,
# 1 management server, and 3 MySQL servers.
# The empty default sections are not required, and are shown only for
# the sake of completeness.
# Storage nodes are required to provide a hostname but MySQL Servers
# are not.
# 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.
# NDBD, MYSQLD, and NDB_MGMD are aliases for DB, API, and MGM respectively
#
[NDBD DEFAULT]
NoOfReplicas= 1

[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]

[NDB_MGMD]
HostName= myhost.example.com

[NDBD]
HostName= myhost.example.com
DataDir= /var/lib/mysql-cluster

[MYSQLD]
[MYSQLD]
[MYSQLD]

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

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

Затем запустите один DB-узел, выполняя ndbd. При старте ndbd для данного DB-узла в самый первый раз, Вы должны использовать опцию --initial:

shell> ndbd --initial

Для последующих стартов ndbd Вы уже не будете вообще использовать опцию --initial:

shell> ndbd

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

По умолчанию ndbd будет искать сервер управления в localhost на порте 1186 (до MySQL версии 4.1.8 заданный по умолчанию порт был 2200).

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

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

[mysqld]
ndbcluster

Вы можете теперь запустить сервер MySQL обычным порядком:

shell> mysqld_safe --user=mysql &

Подождите немного, чтобы удостовериться, что сервер MySQL выполняется правильно. Если Вы видите сообщение mysql ended, проверьте файл .err сервера, чтобы выяснить то, что пошло неправильно. Если все пока хорошо, Вы можете теперь запустить кластер:

shell> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.7

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> SHOW ENGINES;
+------------+---------+-----------------------------------------------+
| Engine     | Support | Comment                                       |
+------------+---------+-----------------------------------------------+
...
| NDBCLUSTER | DEFAULT | Clustered, fault-tolerant, memory-based tables|
| NDB        | YES     | Alias for NDBCLUSTER                          |
...

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> SHOW
Cluster Configuration
---------------------
[ndbd(NDB)]     1 node(s)
id=2    @127.0.0.1  (Version: 3.5.3, Nodegroup: 0, Master)

[ndb_mgmd(MGM)] 1 node(s)
id=1    @127.0.0.1  (Version: 3.5.3)

[mysqld(API)]   3 node(s)
id=3    @127.0.0.1  (Version: 3.5.3)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)

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

3.4 Файл настройки

Конфигурирование кластера MySQL требует работы с двумя файлами:

Разработчики пакета непрерывно делают усовершенствования конфигурации кластера и пытаются упрощать этот процесс. Несмотря на то, что они стараются поддерживать совместимость в обратном направлении, могут иметься моменты, когда появляется несовместимое изменение. В таких случаях пользователям предоставляется информация о проблеме, если изменение не совместимо в обратном направлении. Если Вы находите такое изменение, которое не зарегистрировано, пожалуйста, используйте базу данных ошибок (http://bugs.mysql.com), чтобы сообщить авторам об этом.

3.4.1 Пример конфигурации для кластера MySQL

Чтобы поддерживать кластер MySQL, Вы должны будете модифицировать файл my.cnf как показано в примере ниже.

Начиная с версии 4.1.8 в my.cnf были сделаны некоторые упрощения, включая новые разделы для выполнимых программ ndbcluster. Однако, они не должны быть спутаны с встречающимися в файле config.ini. Как всегда Вы можете определять эти параметры при вызове тех выполнимых программ из командной строки.

# my.cnf
# example additions to my.cnf for MySQL Cluster
# (valid from 4.1.8)

# enable ndbcluster storage engine, and provide connectstring for
# management server host (default port is 1186)
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com

# provide connectstring for management server host (default port: 1186)
[ndbd]
connect-string=ndb_mgmd.mysql.com

# provide connectstring 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

Для получения подробной информации относительно connectstrings обратитесь к разделу 3.4.2 MySQL Cluster connectstring. 

# my.cnf
# example additions to my.cnf for MySQL Cluster
# (will work on all versions)
# enable ndbcluster storage engine, and provide connectstring
# for management server host to the default port 2200

[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com:2200

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

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

В настоящее время файл конфигурации находится в формате INI и именован по умолчанию config.ini. Это читается ndb_mgmd при запуске, и это может быть помещено где угодно. Расположение и имя определено, используя опцию --config-file=[<path>]<filename> в командной строке ndb_mgmd. Если файл конфигурации не определен, ndb_mgmd по умолчанию пробует читать config.ini, размещенный в текущем рабочем каталоге.

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

Формат INI состоит из разделов, которым предшествуют заголовки раздела (окруженные квадратными скобками), сопровождаемые соответствующими именами параметров и значениями. Одно отклонение из стандартного формата в том, что имя параметра и значение может отделяться двоеточием (`:'), так же, как и знаком равенства (`='). Другое состоит в том, что разделы не идентифицированы уникальным именем. Вместо этого, уникальные записи (типа двух различных узлов того же самого типа) идентифицированы уникальным идентификатором (ID).

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

# file "config.ini" - 2 DB nodes and 2 mysqld
# This file is placed in the startup directory of ndb_mgmd,
# i.e., the management server.
# The first MySQL Server can be started from any host and the second
# can only be started at the host mysqld_5.mysql.com
# NDBD, MYSQLD, and NDB_MGMD are aliases for DB, API, and MGM respectively

[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]
HostName=mysqld_5.mysql.com

Имеется шесть различных разделов в этом файле конфигурации:

Обратите внимание, что каждый узел имеет собственный раздел в config.ini. Например, так как этот кластер имеет два узла памяти, файл конфигурации содержит два раздела, определяющие эти узлы. В примере выше эти разделы помечены [NDBD], но любой из них (или оба) могли бы быть помечены как [DB].

Можно определять значения DEFAULT для каждого раздела. Начиная с MySQL 4.1.5, все имена параметров нечувствительны к регистру.

3.4.2 MySQL Cluster connectstring

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

<connectstring> := [<nodeid-specification>,]<host-specification>[,<host-specification>]
<nodeid-specification> := nodeid=<id>
<host-specification> := <host>[:<port>]

Здесь <id> целое число больше, чем 1. Определяет узел в config.ini, <port> целое число указывает на unix-порт, а <host> является строкой, которая задает адрес хоста в любом, допустимом в Интернете формате.

Пример первый (длинный): 

"nodeid=2, myhost1:1100, myhost2:1100, 192.168.0.3:1200"

Пример второй (короткий): 

"myhost1"

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

Используя много значений <host-specification>, можно обозначить несколько избыточных серверов управления. Узел кластера будет пытаться входить в контакт с сервером управления на каждом компьютере в определенном порядке, пока успешное подключение не было установлено.

Имеется ряд различных способов определить connectstring:

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

3.4.3 Определение компьютеров, составляющих кластер MySQL

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

[COMPUTER]Id
Это внутренний идентификатор в файле конфигурации. Позже в файле всн обращается к этому компьютеру по этому ID. Это целое число.
[COMPUTER]HostName
Это имя компьютера. Также возможно использовать IP-адрес.

3.4.4 Определение сервера управления MySQL Cluster

Раздел [MGM] (или его псевдоним [NDB_MGMD]) используется, чтобы конфигурировать поведение сервера управления. Хотя бы один из параметров ExecuteOnComputer или HostName должен присутствовать. Все другие параметры могут быть опущены и, если это так, примут значения по умолчанию.

[MGM]Id
Каждый узел в кластере имеет уникальный идентификатор, представляемый целочисленным значением между 1 и 63 включая границы. Этот ID используется для адресации узла в соответствии со всеми внутренними сообщениями кластера.
[MGM]ExecuteOnComputer
Это относится к одному из компьютеров, определенных в разделе [COMPUTER].
[MGM]PortNumber
Это номер порта, на котором сервер ждет запросов конфигурации и команд управления.
[MGM]LogDestination
Этот параметр определяет, куда послать регистрирующую информацию с кластера. Имеются три параметра в этом отношении: CONSOLE, SYSLOG и FILE.
[MGM]ArbitrationRank
Этот параметр используется, чтобы определить, которые узлы могут действовать как арбитраторы. Только MGM и API-узлы могут быть арбитраторами, и параметр может принимать одно из следующих значений: Обычно сервер управления должен быть конфигурирован как арбитратор, устанавливая ArbitrationRank в 1 (значение по умолчанию) и ArbitrationRank в 0 на всех API и серверных узлах.
[MGM]ArbitrationDelay
Целочисленное значение, которое предписывает серверу управления до запросов арбитража отсрочить ответы на соответствующее число миллисекунд. По умолчанию это значение 0, это обычно не надо менять.
[MGM]DataDir
Это устанавливает каталог, где выходные файлы с сервера управления будут помещены. Эти файлы включают журналы кластера, обрабатываемые выходные файлы и pid-файл сервера (для журналов это может быть отменено, устанавливая параметр FILE для [MGM]LogDestination).

3.4.5 Определение узлов памяти MySQL Cluster

Раздел [DB] (или [NDBD], что то же самое) используется, чтобы конфигурировать поведение узлов памяти. Имеется много параметров, определяющих всякие настройки. Единственные обязательные параметры: ExecuteOnComputer или HostName и параметр NoOfReplicas, которые должны быть определены в разделе [DB DEFAULT]. Большинство параметров должно быть установлено именно в разделе [DB DEFAULT]. Параметры HostName, Id и ExecuteOnComputer должны быть определены в локальном разделе [DB].

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

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

[DB]Id
Это ID узла, используемый как адрес узла во всем кластере. Это целое число между 1 и 63. Каждый узел в кластере имеет уникальный ID.
[DB]ExecuteOnComputer
Это ссылка на один из компьютеров, определенных в разделе computer.
[DB]HostName
Этот параметр подобен определению компьютера. Это определяет имя компьютера, на котором постоянно дислоцируется узел памяти. Этот параметр или запись ExecuteOnComputer требуется в обязательном порядке.
[DB]ServerPort
Каждый узел в кластере использует один порт, чтобы подключить узлы друг к другу. Этот порт используется также для не-TCP связи в фазе установки подключения. Заданный по умолчанию порт будет вычислен, чтобы гарантировать, что никакие узлы на том же самом компьютере не получают тот же самый номер порта.
[DB]NoOfReplicas
Этот параметр может быть установлен только в разделе [DB DEFAULT], потому что это глобальный параметр. Это определяет число точных копий для каждой таблицы, сохраненной в кластере. Этот параметр также определяет размер групп узлов. Группа представляет собой набор узлов, хранящих ту же самую информацию. Группы сформированы неявно. Первая группа сформирована узлами памяти с самыми низкими идентификаторами узла. Далее берутся более высокие идентификаторы и так далее. Например, предположите, что мы имеем 4 узла памяти, и NoOfReplicas установлен в 2. Четыре узла памяти имеют ID узла 2, 3, 4 и 5. Затем первая группа будет сформирована узлами 2 и 3. Вторая группа узлов будет сформирована узлами 4 и 5. Важно конфигурировать кластер таким способом, что узлы в тех же самых группах не помещены в тот же самый компьютер. Это вызвало бы одиночный HW-сбой, который может вызвать аварийный отказ кластера. Если никакие идентификаторы узлов не обеспечиваются, порядок узлов памяти будет фактором определения группы узла. Фактическая группа узла будет напечатана командой SHOW в клиенте управления. Не имеется никакого значения по умолчанию, максимальный номер 4.
[DB]DataDir
Этот параметр определяет каталог, где помещены служебные файлы (трассировка, протоколы, журналы ошибок и pid-файл).
[DB]FileSystemPath
Этот параметр определяет каталог, где размещаются все файлы, созданные для метаданных, протоколов REDO и UNDO, а также файлы данных. Значение по умолчанию должно использовать тот же самый каталог, что и DataDir. Каталог должен быть создан перед запуском процесса ndbd. Если Вы используете рекомендуемую иерархию каталога, Вы используете каталог /var/lib/mysql-cluster. Под этим каталогом будет создан каталог ndb_3_fs (если ID узла был 3), который будет файловой системой для этого узла.
[DB]BackupDataDir
Это определяет каталог, где копии будут помещены. По умолчанию это каталог FileSystemPath/BACKUP.

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

[DB]DataMemory
Этот параметр один из наиболее важных, потому что это определяет, доступное, чтобы сохранить фактические записи в базе данных. Весь объем DataMemory будет распределен в памяти, так что важно, что машина содержит достаточно памяти, чтобы обработать DataMemory. DataMemory используется, чтобы сохранить две вещи. Это сохраняет фактические записи. Каждая запись имеет в настоящее время фиксированный размер. Столбцы типа VARCHAR сохранены как столбцы фиксированного размера. Имеются нпроизводительные затраты на каждой записи (обычно 16 байт). Дополнительно каждая запись сохранена в странице размером 32KB с непроизводительными затратами страницы в 128 байт. Максимальный размер записи для столбцов в настоящее время 8052 байт. DataMemory также используется, чтобы сохранить упорядоченные индексы. Упорядоченные индексы используют приблизительно 10 байт в соответствии с записью. Каждая запись в таблице всегда представляется в упорядоченном индексе. DataMemory состоит из страниц длиной по 32KB. Эти страницы распределены по разделам таблиц. Каждая таблица обычно разбита на разделы с тем же самым числом разделов, сколько имеется узлов памяти в кластере. Таким образом, для каждого узла имеется то же самое число разделов (= фрагменты), сколько задано в параметре NoOfReplicas. Другой важный аспект: DataMemory также хранит информацию UNDO для записей. Для каждой модификации записи, копия изначальной записи распределена в DataMemory. Также каждая копия записи будет иметь элемент в упорядоченных индексах таблицы. Уникальные индексы модифицируются только, когда модифицируются уникальные индексные столбцы, в том случае вставлен новый вход в индексной таблице, а старый вход удален. Таким образом, необходимо также распределить память, чтобы обработать самые большие транзакции, которые выполняются в кластере. Выполнение больших транзакций не имеет никакого преимущества в кластере MySQL. Это не быстрее и потребляет большие объемы памяти. Значение по умолчанию для DataMemory: 80MB. Минимум: 1MB. Не имеется никакого максимального размера, но в действительности максимальный размер должен адаптироваться так, чтобы процесс не вызывал своп при использовании максимального размера памяти.
[DB]IndexMemory
IndexMemory представляет собой параметр, который управляет количеством памяти, используемой для индексов в MySQL Cluster. Индексы всегда используются для первичных индексов ключа, уникальных индексов и уникальных ограничений. Фактически при определении первичного ключа и уникального индекса будут иметься два индекса, созданные в MySQL Cluster. Один индекс используется для всех доступов, а также для обработки блокировки. Это также используется, чтобы гарантировать уникальные ограничения. Размер индекса составляет 25 байт плюс размер первичного ключа. Для первичных ключей, больших, чем 32 байта, 8 байт добавлены для некоторых внутренних ссылок. Таким образом, для таблицы, определенной как 
CREATE TABLE example
(
  a INT NOT NULL, b INT NOT NULL, c INT NOT NULL,
  PRIMARY KEY(a), UNIQUE(b)
) ENGINE=NDBCLUSTER;
мы будем иметь 12 байт непроизводительных затрат (отсутствие столбцов со значениями null экономит 4 байта) плюс 12 байт данных в соответствии с записью. Кроме того мы будем иметь два упорядоченных индекса на a и b, потребляющих приблизительно по 10 байт каждый в соответствии с записью. Мы будем также иметь первичный индекс ключа в основной таблице грубо с 29 байтами в соответствии с записью. Уникальное ограничение выполнено отдельной таблицей с b как первичный ключ, а с a как столбец. Эта таблица потребит другие 29 байтов индексной памяти в соответствии с записью в таблице, а также 12 байт непроизводительных затрат плюс 8 байт данных в части записи. Таким образом, для одного миллиона записей мы будем нуждаться в 58MB индексной памяти, чтобы обработать индексы для первичного ключа и уникального ограничения. Для части DataMemory мы будем нуждаться в 64MB памяти, чтобы обработать записи основной таблицы и уникальной индексной таблицы плюс две упорядоченных индексных таблицы. Заключение: индексы занимают немало памяти, но они обеспечивают очень быстрый доступ к данным. Они также используются в MySQL Cluster, чтобы обработать ограничения уникальности. В настоящее время единственный алгоритм разбиения хеширование, и упорядоченные индексы локальны для каждого узла и не могут таким образом использоваться, чтобы обработать ограничения уникальности в общем случае. Важный момент для IndexMemory и DataMemory: то, что общий размер базы данных является суммой DataMemory и IndexMemory в каждой группе узлов. Каждая группа узлов используется, чтобы сохранить скопированную информацию, так, если имеются четыре узла с 2 точными копиями будут две группы узлов, и таким образом общее количество DataMemory составит 2*DataMemory в каждом из узлов. Другой важный момент относительно изменений DataMemory и IndexMemory. Прежде всего, строго рекомендуется иметь тоже самое количество DataMemory и IndexMemory во всех узлах. Так как данные распределены равномерно по всем узлам в кластере, размер лимитируется самым маленьким размером на узле в кластере. Размер DataMemory и IndexMemory может быть изменен, но опасно уменьшить их, потому что это может легко привести к узлу, который не будет способен перезапуститься, или даже к невозможности перезапуска кластера, если не имеется достаточно пространства памяти для таблиц, необходимых, чтобы работать со стартовым узлом. Увеличение их должно быть безопасно, но рекомендуется, чтобы такие обновления выполнились тем же самым способом, как программное обновление, где сначала модифицируется файл конфигурации, затем перезапускается сервер управления, а уж потом один узел памяти одновременно перезапускается. Большее количество IndexMemory не используется при модификациях, но вставки будут вставлены немедленно, а удаления не будут удалены, пока транзакция не завершена. Значение по умолчанию размера IndexMemory составляет 18MB. Минимальное равно 1MB.

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

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

[DB]MaxNoOfConcurrentTransactions
Для каждой активной транзакции в кластере должна иметься также запись транзакции в одном из узлов в кластере. Роль координации транзакции распространена среди узлов и таким образом общее число записей транзакций в кластере равно количеству узлов в кластере. Фактически записи транзакции распределены сервером MySQL, обычно имеется по крайней мере одна запись транзакции, распределенная в кластере, на подключение, которая использует или использовала таблицу в кластере. Таким образом, нужно гарантировать, что имеется большее количество записей транзакции в кластере, чем параллельных соединений с серверами в кластере. Этот параметр должен быть тем же самым на всех узлах в кластере. Изменение этого параметра никогда не безопасно и может вызывать аварийный отказ кластера. Дело в том, что в случае сбоя одного из узлов, нагрузку примут остальные, а это означает, что у них должно хватить записей транзакций, чтобы обработать транзакции с временно вышедшего из строя узла. Если не хватит, узлы начнут вылетать по одному, что выведет из строя кластер в целом. Значение по умолчанию для этого параметра: 4096.
[DB]MaxNoOfConcurrentOperations
Этот параметр, вероятно, будет изменен пользователями. Пользователи, выполняющие только короткие, маленькие транзакции, не должны устаналивать этот параметр очень высоко. Прикладные программы, желающие выполнять довольно большие транзакции, включающие много записей, должны установить этот параметр выше. Для каждой транзакции, которая модифицирует данные в кластере требуется иметь записи операции. Имеются записи операции в координаторе транзакции и в узлах, где выполняются фактические модификации. Записи операции содержат информацию о состоянии, необходимую, чтобы найти записи UNDO для обратной перемотки, очередей блокировок и много другой информации о состоянии. Для кластера, обрабатывающего транзакции, где модифицируется один миллион записей одновременно, надлежит установить этот параметр в один миллион поделенный на число узлов. Таким образом, для кластера с четырьмя узлами памяти нужно установить этот параметр в 250000. Также запросы чтения, которые устанавливают блокировки, исчерпывают записи операции. Некоторое дополнительное количество распределено в локальных узлах, чтобы обслужить случаи, в которых распределение по узлам не совершенно. Когда запросы транслируют в использование уникального индекса фактически будет две записи операции, используемые в соответствии с записью в транзакции. Первая представляет чтение индексной таблицы, а вторая обрабатывает операцию на основной таблице. Значение по умолчанию для этого параметра: 32768. Этот параметр фактически обрабатывает две части, которые могут быть сконфигурированы отдельно. Первая часть определяет, сколько записей операции должны быть помещены в часть координатора транзакции. Вторая часть определяет, сколько записей операции должны использоваться в локальной части базы данных. Если очень большая транзакция выполняется на кластере с 8 узлами, то понадобится столько записей операции в координаторе транзакции, сколько будет чтений, удалений и обновлений в транзакции. Транзакция, однако, распределит записи операции между всеми восьмью узлами. Таким образом, если необходимо конфигурировать систему для одной очень большой транзакции, хорошая идея конфигурировать их порознь. MaxNoOfConcurrentOperations будет всегда использоваться, чтобы вычислить число записей операции в части координатора транзакции узла. Также важно иметь представление относительно требований памяти для тех записей операции. В MySQL 4.1.5 записи операции потребляют около 1KB на запись. Это планируется уменьшить в версиях 5.x.
[DB]MaxNoOfLocalOperations
По умолчанию этот параметр вычислен как 1.1*MaxNoOfConcurrentOperations, который удовлетворяет системы с большим числом одновременных, не очень больших транзакций. Если конфигурация должна обработать очень большие транзакции одновременно, и имеется много узлов, стоит конфигурировать это отдельно.

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

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

[DB]MaxNoOfConcurrentIndexOperations
Для запросов, использующих уникальный индекс, другой набор записей операции временно используются в фазе выполнения запроса. Этот параметр устанавливает размер этого пула. Таким образом, эта запись распределена только при выполнении части запроса, как только эта часть была выполнена, запись освобождается немедленно. Обработка аварийных прекращений работы и тому подобное выполнена в соответствии с нормальными записями операции, где размер пула установлен параметром MaxNoOfConcurrentOperations. Значение по умолчанию для этого параметра: 8192. Только в редких случаях чрезвычайно высокого параллелизма, использующего уникальные индексы, этот параметр необходимо увеличить. Уменьшение сэкономит память, но делать это можно только, если Вы уверены, что такой высокий параллелизм не встречается в кластере.
[DB]MaxNoOfFiredTriggers
Значение по умолчанию для MaxNoOfFiredTriggers равно 4000. Обычно это значение должно быть достаточно для большинства систем. В некоторых случаях это стоит уменьшить, если Вы чувствуете, что параллелизм в кластере не так уж и высок. Эта запись используется, когда операция выполняется, что воздействует на уникальный индекс. Модифицирование столбца, который является частью уникального индекса или вставки/удаления записи в таблице с уникальными индексами будет работать со вставками и удалениями в индексной таблице. Эта запись используется, чтобы представить эту индексную операцию таблицы, в то время как идет ожидание для первоначальной операции. Таким образом, эта запись требуется ненадолго, но может занимать немало места для временных ситуаций с многими параллельными операциями записи на основной рабочей таблице, содержащей набор уникальных индексов.
[DB]TransactionBufferMemory
Этот параметр также используется для хранения операций, чтобы модифицировать индексные таблицы. Эта часть хранит ключ и информацию столбца для операций. Этот параметр меняется очень редко. Также нормальное чтение и операции записи использует подобный буфер. Этот буфер во время компиляции выставлен в 4000*128 байт (500KB), что определено через ZATTRBUF_FILESIZE в Dbtc.hpp. Существует подобный буфер для информации ключа, который содержит 4000*16 байт, 62.5KB. Параметр в этом случае: ZDATABUF_FILESIZE в Dbtc.hpp. Dbtc представляет собой модуль для обработки координации транзакций. Подобные параметры существуют в модуле Dblqh, где данные размещены. В Dblqh.hpp с ZATTRINBUF_FILESIZE, установленным в 10000*128 байт (1250KB), установите ZDATABUF_FILE_SIZE в 10000*16 байт (примерно 156KB). Заданный по умолчанию размер TransactionBufferMemory составляет 1MB.
[DB]MaxNoOfConcurrentScans
Этот параметр используется, чтобы управлять количеством параллельных просмотров, которые могут выполняться в кластере. Каждый координатор транзакции может обрабатывать количество параллельных просмотров, определенное этим параметром. Каждый запрос просмотра выполняется, просматривая все разделы параллельно. Каждый просмотр раздела использует запись просмотра в узле, где раздел размещен. Просмотр выполняется в двух случаях. Первый случай: не существует никакого упорядоченного индекса, чтобы обработать запрос. В этом случае запрос обрабатывается, выполняя полный просмотр таблицы (очень долго и неоптимально!). Второй вариант: не имеется никакого индекса, чтобы поддерживать запрос, но имеется упорядоченный индекс. Тогда происходит использование упорядоченных индексных средств, выполняющих параллельный просмотр диапазона. Так как индекс только продолжает локальные разделы, необходимо выполнить индексный просмотр на всех разделах. Значение по умолчанию для MaxNoOfConcurrentScans равно 256. Максимальное допустимое значение составляет 500. Этот параметр будет всегда определять количество возможных просмотров в координаторе транзакций. Если число локальных записей просмотров не задано явно, это вычислено как произведение MaxNoOfConcurrentScans на число узлов памяти в системе.
[DB]MaxNoOfLocalScans
Возможно определять число локальных записей просмотра, если многие просмотры не полностью параллелизируемы.
[DB]BatchSizePerLocalScan
Этот параметр используется, чтобы вычислить число записей блокировки, требуемых, чтобы обработать много параллельных операций просмотра. Значение по умолчанию составляет 64, и оно сильно связано с ScanBatchSize, определенным в узлах API.
[DB]LongMessageBuffer
Это внутренний буфер, используемый для передачи сообщений в узле и для сообщений между узлами в системе. Вряд ли его вообще понадобится менять, но на всякий случай такая возможность существует. По умолчанию это 1MB.
[DB]NoOfFragmentLogFiles
Это важный параметр, который заявляет размер REDO журналов в узле. REDO журналы организованы в кольцо, так что важно, чтобы хвост и голова списка не встречались. Если они перекроются, узел запустит прерывание всех транзакций модифицирования, потому что не имеется никакого участка памяти для записи файла регистрации. REDO записи файла регистрации не удалены, пока три локальных контрольных точки не завершатся после того, как запись файла регистрации была вставлена. Быстродействие контрольной точки управляется набором других параметров, так что эти параметры взаимосвязаны. Заданное по умолчанию значение параметра: 8, что означает 8 наборов по 4 файла в 16MB каждый. Таким образом, в общем получаем 512MB. Единицей места для файла регистрации REDO является 64MB. В случае больших количеств модификаций этот параметр должен быть установлен очень высоким. Известны случаи, где было необходимо установить его к более, чем 300. Если введение контрольных точек медленно, и имеется так много записей в базе данных, что журналы заполнились, а хвост списка файла регистрации не может быть вырезан по причинам восстановления, то все транзакции модифицирования будут прерваны с внутренним кодом ошибки 410, который будет транслироваться в Out of log file space temporarily. Это условие будет преобладать, пока контрольная точка не завершилтся, а хвост списка файла регистрации не будет продвинут вперед.
[DB]MaxNoOfSavedMessages
Этот параметр устанавливает максимальное число файлов трассировки, которые будут сохраняться перед перезаписью старых файлов трассировки. Файлы трассировки сгенерированы, когда узел терпит крах по некоторым причинам. Значение по умолчанию: 25 файлов трассировки.

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

[DB]MaxNoOfAttributes
Этот параметр определяет число атрибутов, которые могут быть определены в кластере. Значение по умолчанию для этого параметра: 1000. Минимальное значение: 32, но не имеется никакого максимума. Каждый атрибут потребляет около 200 байт памяти в каждом узле, потому что метаданные полностью скопируются на серверы.
[DB]MaxNoOfTables
Объект таблицы распределен для каждой таблицы, для каждого уникального индекса и для каждого упорядоченного индекса. Этот параметр устанавливает максимальное число объектов таблицы в кластере. Для каждого атрибута, который имеет тип BLOB, используется дополнительная таблица, чтобы сохранить большинство данных BLOB. Эти таблицы также должны быть приняты во внимание при определении числа таблиц. Значение по умолчанию для этого параметра 128. Минимум 8, а максимум 1600. Каждый объект таблицы потребляет примерно по 20KB в каждом узле.
[DB]MaxNoOfOrderedIndexes
Для каждого упорядоченного индекса в кластере, будут распределены объекты, чтобы описать то, что он индексирует и части памяти. По умолчанию каждый определенный индекс будет иметь упорядоченный индекс. Уникальные индексы и индексы первичных ключей имеют сразу упорядоченный индекс и хэш-индекс, то есть им нужно по два объекта. Значение по умолчанию этого параметра 128. Каждый объект потребляет примерно по 10KB данных на узел.
[DB]MaxNoOfUniqueHashIndexes
Для каждого уникального индекса (не для первичных ключей) распределена специальная таблица, которая отображает уникальный ключ на первичный ключ индексированной таблицы. По умолчанию будет иметься упорядоченный индекс, также определенный для каждого уникального индекса. Чтобы избежать этого, Вы должны использовать опцию USING HASH на уникальном индексном определении. Значение по умолчанию 64. Каждый индекс потребит около 15KB памяти на узел.
[DB]MaxNoOfTriggers
Для каждого уникального индекса распределяются триггеры, контролирующие внутренние вставки, обновления и удаления. Таким образом, получается по три триггера на уникальный индекс. Упорядоченные индексы используют только единственный триггерный объект на индекс. Резервирование также требует по три объекта для каждой нормальной таблицы в кластере. Когда между кластерами обеспечивается репликация, это также использует внутренние триггеры. Этот параметр устанавливает максимальное число триггерных объектов в кластере. Значение по умолчанию этого параметра 768.
[DB]MaxNoOfIndexes
Этот параметр устарел в MySQL 4.1.5. Теперь Вы должны использовать вместо этого MaxNoOfOrderedIndexes и MaxNoOfUniqueHashIndexes. Этот параметр используется только уникальными индексами. Должна иметься одна запись в этом пуле для каждого уникального индекса, определенного в кластере. Значение по умолчанию для этого параметра составляет 128.

Имеется набор булевых параметров, воздействующих на поведение узлов памяти. Булевы параметры могут быть определены как истина, устанавливая их в Y или 1, либо как ложь, устанавливая их в N или 0.

[DB]LockPagesInMainMemory
Для ряда операционных систем типа Solaris и Linux возможно блокировать процесс в памяти и избегать уймы проблем со свопом. Это важное свойство, чтобы обеспечить характеристики работы кластера в реальном масштабе времени. Значение по умолчанию: это выключено.
[DB]StopOnError
Этот параметр заявляет, должен ли процесс завершиться с сообщением об ошибке или выполнить автоматический рестарт. Значение по умолчанию: включено.
[DB]Diskless
Во внутренних интерфейсах возможно установить таблицы как таблицы без диска, означающие, что таблицы не сбрасываются на диск, и никакая регистрация не происходит. Они существуют только в оперативной памяти. Таблицы (но не записи в таблице!) будут существовать после аварийного отказа. Это свойство делает весь кластер бездисковым, в этом случае даже таблицы не существуют больше после аварийного отказа. Включение этого свойства может быть выполнено установкой его в Y или в 1. Когда это свойство активно, копии будут выполняться, но не будут сохранены, потому что формально не имеется никакого диска. В будущих выпусках это, вероятно, будет делать копию без диска отдельным параметром с перестраиваемой конфигурацией. Значение по умолчанию для этого параметра: выключено.
[DB]RestartOnErrorInsert
Это свойство доступно только при формировании отладочной версии, где возможно вставить ошибки в выполнение различных частей кода, чтобы проверить случаи сбоя. Значение по умолчанию: это свойство выключено.

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

[DB]TimeBetweenWatchDogCheck
Чтобы гарантировать, что основной поток не эастревает в вечном цикле где-нибудь, имеется сторожевой поток, который проверяет основной поток. Этот параметр заявляет число миллисекунд между проверками. После трех проверок, все еще находящийся в том же самом состоянии процесс будет остановлен процессом-сторожем. Этот параметр легко может быть изменен и отличен в узлах, хотя имеются лишь немногие причины для такого различия. Заданное по умолчанию время ожидания составляет 4000 миллисекунд (4 секунды).
[DB]StartPartialTimeout
Этот параметр определяет время, которое кластер будет ждать запуска всех узлов памяти прежде, чем запустить собственно кластерный алгоритм. Это используется, чтобы избежать запуска только частичного кластера, если возможно. Значение по умолчанию 30000 миллисекунд (30 секунд). 0 указывает вечное время. Таким образом, кластер запустится только, если все узлы доступны.
[DB]StartPartitionedTimeout
Если кластер готов к пуску после ожидания StartPartialTimeout, но все еще возможно в разбитом на разделы состоянии, он ждет, пока также и это время ожидания не выйдет. Заданное по умолчанию время ожидания 60000 миллисекунд (60 секунд).
[DB]StartFailureTimeout
Если старт не выполнен в рамках времени, определенного этим параметром, попытка пуска узла будет терпеть неудачу. При установке этого параметра в 0 никакой таймаут не применяется, чтобы запустить кластер. Значение по умолчанию: 60000 миллисекунд (60 секунд). Для узлов памяти, содержащих большие наборы данных, этот параметр должен быть увеличен, поскольку может требоваться по 10-15 минут, чтобы выполнить рестарт узла памяти с несколькими гигабайтами данных.
[DB]HeartbeatIntervalDbDb
Один из основных методов обнаружения неудачных узлов. Этот параметр заявляет, как часто сигналы проверки будут посланы, и как часто ожидать их получения. После отсутствия сигналов три интервала подряд узел будет объявлен вышедшим из строя. Таким образом максимальное время обнаружения сбоя через этот механизм составляет четыре интервала. Заданный по умолчанию интервал 1500 миллисекунд (1,5 секунды). Этот параметр почти никогда не должен быть изменен на большую величину. Если один узел использует 5000 миллисекунд, а другой узел, наблюдая это, использует 1000 миллисекунд, очевидно, что узел будет объявлен сбойным очень быстро. Так что этот параметр может быть изменен очень маленькими порциями в течение интерактивного программного обновления.
[DB]HeartbeatIntervalDbApi
Подобным способом каждый узел памяти посылает сигналы каждому из связанных серверов MySQL, чтобы гарантировать, что они ведут себя правильно. Если сервер MySQL не посылает сигналов (тот же самый алгоритм, что касается узла памяти) три интервала подряд, он считается сбойным, все продолжающиеся транзакции будут завершены, все ресурсы будут освобождены, а сервер MySQL не сможет повторно соединяться, пока завершение всех действий, начатых предыдущим экземпляром MySQL, не будет завершено. Заданный по умолчанию интервал 1500 миллисекунд. Этот интервал может быть отличен в узле памяти, потому что каждый узел памяти независимо от всех других узлов памяти наблюдает серверы MySQL, связанные с ним.
[DB]TimeBetweenLocalCheckpoints
Этот параметр исключительная ситуация, в которой не устанавливает время, чтобы ждать перед стартом новой локальной контрольной точки. Этот параметр используется, чтобы гарантировать, что не выполняются локальные контрольные точки в кластере, где происходит не так много модификаций. В большинстве кластеров с высокими периодами обновления вероятно, что новая локальная контрольная точка начата немедленно после завершения предыдущей. Размер всех операций записи, выполненных начиная с начала предыдущих локальных контрольных точек добавлен. Этот параметр определен как логарифм числа слов. Так значение по умолчанию 20 означает 4MB операций записи, 21 задает 8MB и и так далее вплоть до максимального значения, которое означает 8GB операций записи. Все операции записи в кластере добавлены вместе. Установка этого в 6 или более низкое значение означает, что локальные контрольные точки выполняются без паузы между ними, независимо от рабочей нагрузки в кластере.
[DB]TimeBetweenGlobalCheckpoints
Когда транзакция совершена, это передано в оперативной памяти во всех узлах, где существовали зеркала данных. Записи файла регистрации транзакции не переданы на диск как часть совершающегося. Рассуждение здесь состоит в том, что раз уж транзакция безопасно совершена, по крайней мере два независимых компьютера должны хранить данные о ней. В то же самое время также важно гарантировать, что даже самый плохой из случаев, когда кластер полностью терпит крах, обработан правильно. Чтобы гарантировать это, все транзакции в некотором интервале помещены в глобальную контрольную точку. Глобальная контрольная точка очень похожа на групповое завершение транзакций. Вся группа транзакций послана на диск сразу. Таким образом, как часть совершающегося транзакция была помещена в глобальную группу контрольной точки. Позже это сгруппирует записи файла регистрации для сброса на диск, а затем вся группа транзакции безопасно совершена. Этот параметр заявляет интервал между глобальными контрольными точками. Заданное по умолчанию время паузы составляет 2000 миллисекунд.
[DB]TimeBetweenInactiveTransactionAbortCheck
Обработка блокировки времени выполняется, проверяя каждый таймер на каждой транзакции каждый период времени в соответствии с этим параметром. Таким образом, если этот параметр установлен в 1000 миллисекунд, то каждая транзакция будет проверена один раз в секунду. Значение по умолчанию для этого параметра как раз и составляет 1000 миллисекунд.
[DB]TransactionInactiveTimeout
Если транзакция в настоящее время не выполняет никаких запросов, но ждет дальнейший ввод пользователя, этот параметр заявляет максимальное время, которое можно ждать перед тем, как прервать транзакцию. Значение по умолчанию для этого параметра отсутствует. Для базы данных в реальном масштабе времени, никакая транзакция не хранит блокировки в течение длительного времени, так что этот параметр должен быть установлен к намного меньшему значению.
[DB]TransactionDeadlockDetectionTimeout
Когда транзакция включается в выполнение запроса, это ждет других узлов. Если другие узлы не отвечают, это может зависеть от трех вещей. Первое (и самое очевидное): узел сдох, второе: операция может ввести очередь блокировок, а третье узел, необходимый, чтобы выполнить действие, может быть просто конкретно перегружен. Этот параметр времени ожидания заявляет, как долго координатор транзакций будет ждать, пока не прервет транзакцию при ожидании выполнения запроса другим узлом. Таким образом, этот параметр важен для обработки сбоя узла и для обнаружения тупика. Установка этого параметра слишком высоким вызвала бы нежелательное поведение при сбоях узла и тупиках. Заданное по умолчанию время составляет 1200 миллисекунд (1,2 секунды).
[DB]NoOfDiskPagesToDiskAfterRestartTUP
При выполнении локальной контрольной точки алгоритм посылает все данные страницы на диск в течение локальной контрольной точки. Увы, это частенько приводит к нежелательным перегрузкам оборудования, а, следовательно, и замедлению работы кластера в целом. Таким образом, чтобы управлять записью, этот параметр определяет, сколько страниц за 100 миллисекунд должны быть записаны. Страница здесь определена как 8KB. Единица, в которой этот параметр определен, равна 80KB в секунду. Так установка этого в 20 означает запись 1,6MB данных страницы на диск в секунду в течение локальной контрольной точки. Также сброс записей файла регистрации UNDO для данных страницы является частью этой суммы. Запись страниц индексов и их записей файла регистрации UNDO обработана параметром NoOfDiskPagesToDiskAfterRestartACC. Этот параметр обрабатывает ограничение записей из DataMemory. Этот параметр определяет, как быстро локальные контрольные точки будут выполнены. Этот параметр важен в связке с NoOfFragmentLogFiles, DataMemory и IndexMemory. Значение по умолчанию 40 (3,2MB данных страницы).
[DB]NoOfDiskPagesToDiskAfterRestartACC
Этот параметр имеет те же самые величины измерения, что и NoOfDiskPagesToDiskAfterRestartTUP, но ограничивает быстродействие записи страниц индексов из IndexMemory. Значение по умолчанию этого параметра: 20 (1,6MB в секунду).
[DB]NoOfDiskPagesToDiskDuringRestartTUP
Этот параметр определяет те же самые вещи, что и NoOfDiskPagesToDiskAfterRestartTUP (и NoOfDiskPagesToDiskAfterRestartACC), только это делается для локальных контрольных точек, выполненных в узле как часть локальной контрольной точки, когда узел перезапускается. Поскольку перезапускается часть всех узлов, локальная контрольная точка всегда выполняется. С тех пор в течение рестарта узла возможно использовать более высокое быстродействие записи на диск, потому что меньшее количество действий выполняется в узле из-за фазы рестарта. Этот параметр обрабатывает часть DataMemory. Значение по умолчанию 40 (3,2MB в секунду).
[DB]NoOfDiskPagesToDiskDuringRestartACC
В течение рестарта для части IndexMemory локальной контрольной точки задается быстродействие именно здесь. Значение по умолчанию составляет 20 (1,6 MB в секунду).
[DB]ArbitrationTimeout
Этот параметр определяет время, которое узел памяти будет ждать ответ арбитратора при посылке сообщения арбитража в случае проблем в сети. Значение по умолчанию 1000 миллисекунд.

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

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

[DB]UndoIndexBuffer
Этот буфер используется в течении обработки локальных контрольных точек. Движок NDB использует схему восстановления, основанную на непротиворечивой контрольной точке вместе с операционным протоколом REDO. Чтобы производить непротиворечивую контрольную точку без того, чтобы блокировать всю систему для записи, регистрация UNDO сделана при выполнении локальной контрольной точки. Регистрация UNDO активизирована одновременно только на одном фрагменте одной таблицы. Эта оптимизация возможна, потому что таблицы полностью сохранены в оперативной памяти. Этот буфер используется для модификаций на первичном индексе ключа. Вставки и удаления реорганизуют индекс и записи файла регистрации UNDO, которые отображают все физические изменения для страницы индексов так, что они могут быть уничтожены при рестарте системы. Это также регистрирует все активные операции вставки в начале локальной контрольной точки для фрагмента. Чтения и обновления только устанавливают бит блокировки и меняют заголовок в элементе указателя. Эти изменения обработаны алгоритмом записи страницы, чтобы гарантировать, что эти операции не нуждаются ни в какой регистрации UNDO. Этот буфер по умолчанию 2MB. Минимальное значение 1MB. Для большинства прикладных программ это достаточно хорошо. Прикладные программы, делающие чрезвычайно тяжелые вставки и удаления вместе с большими транзакциями, использующими большие первичные ключи, должны расширить этот буфер. Если этот буфер слишком маленький, движок NDB выдает внутренний код ошибки 677, который будет транслироваться в "Index UNDO buffers overloaded".
[DB]UndoDataBuffer
Этот буфер имеет точно ту же самую роль, что и UndoIndexBuffer, но используется для части данных. Этот буфер используется в течение локальной контрольной точки фрагмента, его задействуют вставки, модификации и удаления. Так как эти записи файла регистрации UNDO имеют тенденцию быть большими, и большее количество вещей регистрируется, буфер также больший по умолчанию. Это установлено в 16MB. Для некоторых прикладных программ это слишком много, и они могли бы уменьшать этот размер, минимальный размер 1MB. Редко но бывает, что прикладные программы должны увеличить этот буферный размер. Если имеется потребность в этом, стоит проверить, могут ли диски фактически обрабатывать загрузку, которую вызывает действие модификации в базе данных. Если они этого не могут, никакой размер этого буфера не будет достаточно большим. Если этот буфер слишком маленький и становится переполненным, NDB выдает внутренний код ошибки 891, который будет транслироваться в "Data UNDO buffers overloaded".
[DB]RedoBuffer
Все действия модификации также должны регистрироваться. Это допускает повтор этих модификаций при рестарте системы. Алгоритм восстановления использует непротиворечивую контрольную точку, произведенную "размытой" контрольной точкой данных вместе с UNDO-регистрацией страниц. Затем это применяет REDO-журнал, чтобы воспроизвести все изменения вплоть до времени, когда был выполнен рестарт системы. Этот буфер по умолчанию 8MB. Минимальное значение 1MB. Если этот буфер слишком маленький, NDB выдает внутренний код ошибки 1221, который будет транслироваться в "REDO log buffers overloaded".

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

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

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

[DB]LogLevelStartup
События, сгенерированные в течение процесса запуска. Заданный по умолчанию уровень 1.
[DB]LogLevelShutdown
События, сгенерированные как часть нормального завершения системы узла. Заданный по умолчанию уровень 0.
[DB]LogLevelStatistic
Статистические события типа того, сколько первичных ключей читается, модифицируется, вставляется и много другой статистической информации по применению буферов. Заданный по умолчанию уровень информативности 0.
[DB]LogLevelCheckpoint
События, сгенерированные локальными и глобальными контрольными точками. Заданный по умолчанию уровень 0.
[DB]LogLevelNodeRestart
События, сгенерированные в течение рестарта узла. Заданный по умолчанию уровень 0.
[DB]LogLevelConnection
События, сгенерированные подключениями между узлами в кластере. Заданный по умолчанию уровень 0.
[DB]LogLevelError
События, сгенерированные ошибками и предупреждениями в кластере. Это ошибки, не вызывающие сбой узла, но все еще рассматриваемые, как стоящие сообщения о них. Заданный по умолчанию уровень 0.
[DB]LogLevelInfo
События, сгенерированные для информации относительно состояния кластера и т. д. Заданный по умолчанию уровень 0.

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

[DB]BackupDataBufferSize
При выполнении копии имеются два буфера, используемые для посылки данных на диск. Этот буфер используется в записи данных, выполненном сканированием таблиц узла. При заполнении этого буфера до некоторого уровня, страницы посланы на диск. Этот уровень определен параметром BackupWriteSize. При посылке данных на диск, копия может продолжать заполнять этот буфер, пока не вылезет за его пределы. При исчерпании пространства буфера, система просто остановит просмотр и будет ждать, пока некоторые записи на диск не завершатся и таким образом не освободят буфера памяти, чтобы использовать их для дальнейшего просмотра. Значение по умолчанию 2MB.
[DB]BackupLogBufferSize
Этот параметр имеет подобную роль, но используется для записи протокола всех записей в таблицы в течение выполнения копии. Те же самые принципы применяются для записи страниц, что и в BackupDataBufferSize за исключением того, что, когда эта часть вылезет за пределы буфера, это заставляет копию прерваться из-за недостатка резервных буферов. Таким образом, размер этого буфера должен быть достаточно большим, чтобы обработать нагрузку, вызванную действиями записи в течение резервного копирования. Заданный по умолчанию размер должен быть достаточно большим. Фактически более вероятно, что сбой резервирования вызван диском, не способным записывать так быстро, как это хотелось бы. Если дисковая подсистема недостаточно быстрая для нагрузки записи, вызванной прикладными программами, это создаст кластер, который будет иметь большие трудности, чтобы выполнить желательные действия. Значение по умолчанию 2MB.
[DB]BackupMemory
Этот параметр просто сумма из двух предыдущих, BackupDataBufferSize и BackupLogBufferSize. Значение по умолчанию 4MB.
[DB]BackupWriteSize
Этот параметр определяет размер сообщений, записываемых на диск для файла регистрации, и буфера данных, используемого для копий. Значение, заданное по умолчанию, составляет 32KB.

3.4.6 Определение серверов MySQL в MySQL Cluster

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

[API]Id
Это ID узла, используемый как адрес узла во всем кластере. Это целое число между 1 и 63. Каждый узел в кластере должен иметь уникальный ID.
[API]ExecuteOnComputer
Это ссылка на один из компьютеров, определенных в разделе computer.
[API]ArbitrationRank
Этот параметр используется, чтобы определить, которые узлы могут действовать как арбитраторы. MGM-узлы и узлы API могут быть арбитраторами. 0 указывает, что этот не используется как арбитратор, 1 задает высокий приоритет, а 2 определяет низкий приоритет узла. Нормальная конфигурация использует сервер управления как арбитратор, устанавливая ArbitrationRank в 1 (значение по умолчанию) и устанавливая все API в 0.
[API]ArbitrationDelay
При установке этого к чему-нибудь, кроме 0 это означает, что сервер управления задержит ответы на запросы арбитража. Значение по умолчанию: отсутствие задержек, и нет особой надобности это менять.
[API]BatchByteSize
Для запросов, которые просматривают всю таблицу или диапазон на индексах, это важно для самой лучшей эффективности, чтобы выбрать записи в правильно установленных по размеру пакетах. Возможно установить соответствующий размер в терминах числа записей или в терминах байтов. Реальный пакетный размер будет ограничен обоими параметрами. Эффективность запросов может измениться больше, чем на 40% из-за того, как этот параметр установлен. В будущих выпусках MySQL сервер будет делать обучаемые предположения о том, как установить эти параметры, основываясь на типе запроса. Этот параметр измеряется в байтах и по умолчанию равен 32KB.
[API]BatchSize
Этот параметр измеряется в числе записей и по умолчанию установлен в Максимальный размер составляет 992.
[API]MaxScanBatchSize
Пакетный размер представляет собой размер каждого пакета, посланного из каждого узла памяти. Больше всего просмотров выполняются в параллельном режиме, по причине чего необходимо защитить сервер MySQL от получения слишком большого количества данных из многих узлов в параллельном режиме. Этот параметр устанавливает ограничение общего пакетного размера всем узлам. Значение по умолчанию этого параметра установлено в 256KB. Максимальный размер составляет 16MB.

3.4.7 TCP/IP-соединения в MySQL Cluster

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

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

Также возможно изменить значения по умолчанию, устанавливая параметры в разделе [TCP DEFAULT].

[TCP]NodeId1
[TCP]NodeId2
Чтобы идентифицировать подключение между двумя узлами, необходимо обеспечить идентификатор узла для обоих из них в NodeId1 и в NodeId2.
[TCP]SendBufferMemory
TCP-транспорт использует буферизацию всех сообщений перед выполнением посылающего обращения к операционной системе. Когда этот буфер достигает 64KB, он будет послан. Система пошлет его также, если выполняется кольцо сообщений. Чтобы обрабатывать временные ситуации перегрузки, также возможно определить больший буфер. Заданный по умолчанию размер буфера 256KB.
[TCP]SendSignalId
Чтобы отследить диаграмму распространения сообщений, надо идентифицировать каждое сообщение. Устанавливая этот параметр Y, Вы указываете, что идентификатор отправителя сообщения также транспортируется через сеть. Это свойство не допускается по умолчанию.
[TCP]Checksum
Этот параметр также Y/N, который не допускается по умолчанию. Когда он включен все сообщения проверены контрольным суммированием прежде, чем помещены в посылающий буфер. Это свойство позволяет контролировать, что сообщения не разрушены при ожидании в посылающем буфере. Это также двойная проверка того, что транспортный механизм не разрушил данные.
[TCP]PortNumber
Это номер порта, чтобы использовать для слушания подключений из других узлов. Этот номер порта обычно должен быть определен в разделе [TCP DEFAULT]. Этот параметр больше не должен использоваться. Используйте параметр на узлах памяти вместо этого.
[TCP]ReceiveBufferMemory
Этот параметр определяет размер буфера, используемого при получении данных из сокета TCP/IP. Редко возникает потребность изменить этот параметр. Значение по умолчанию 64KB.

3.4.8 Подключения с общедоступной памятью в MySQL Cluster

Общедоступные сегменты памяти в настоящее время обеспечиваются только для специальных версий MySQL Cluster, собранных с применением параметра --with-ndb-shm скрипта configure. Реализация наиболее вероятно изменится. При определении общедоступной памяти как метода подключения, необходимо определить по крайней мере NodeId1, NodeId2 и ShmKey. Все другие параметры имеют значения по умолчанию, которые будут прекрасно работать в большинстве случаев.

[SHM]NodeId1
[SHM]NodeId2
Это определяет идентификаторы узлов NodeId1 и NodeId2, между которыми создается соединение.
[SHM]ShmKey
При установке общедоступных сегментов памяти используется идентификатор, чтобы уникально идентифицировать общедоступный сегмент памяти для связи. Это целое число, которое не имеет значения по умолчанию.
[SHM]ShmSize
Каждое подключение имеет общедоступный сегмент памяти, где сообщения между узлами откладываются отправителем и читаются получателем. Сегмент имеет размер, определенный этим параметром. Значение по умолчанию 1MB.
[SHM]SendSignalId
Передавать в сообщении идентификатор отправителя. По умолчанию выключено.
[SHM]Checksum
Аналог [TCP]Checksum, но для подключений с общей памятью.

3.4.9 Транспортные подключения SCI в MySQL Cluster

SCI-транспорт между узлами в кластере MySQL поддерживается только для специальных версий, собранных с параметром --with-ndb-sci=/your/path/to/SCI скрипта configure. Путь должен указать на каталог, который содержит по крайней мере каталоги lib и include, где дислоцируются библиотека SISCI и файлы заголовков.

Настоятельно рекомендуется использовать только SCI для связи между процессами ndbd. Также использование SCI будет означать, что процесс ndbd никогда не будет бездействовать, поскольку применение SCI разумно только для машин с по крайней мере 2 CPU, которые выделены для использования процессом ndbd. Должен иметься по крайней мере 1 CPU на процесс ndbd в этом случае и по крайней мере еще один необходим, чтобы также обработать действия OS.

[SCI]NodeId1
[SCI]NodeId2
Идентификаторы узлов NodeId1 и NodeId2, между которыми устанавливается связь.
[SCI]Host1SciId0
Это определяет SCI-идентификатор узла на первом узле (NodeId1).
[SCI]Host1SciId1
Это позволяет определить SCI-транспорт между парой SCI-карт, которые затем должны использовать отдельные сети между узлами. Это определяет идентификатор узла и второй SCI-карты, которую нужно использовать на первом узле.
[SCI]Host2SciId0
Это определяет SCI-идентификатор узла на втором узле (NodeId2).
[SCI]Host2SciId1
Аналогично [SCI]Host1SciId1, но для второго узла.
[SCI]SharedBufferSize
Каждый SCI-транспорт имеет общедоступный сегмент памяти между двумя узлами. Обычно его размер составляет 1MB, что устраивает основную массу прикладных программ. Меньшие размеры (типа 256kB) имеют проблемы при выполнении многих параллельных вставок. Если буфер слишком маленький, это может вызвать сбои процесса ndbd.
[SCI]SendLimit
Маленький буфер перед SCI буферизует сообщения перед посылкой их в SCI-сеть. По умолчанию это установлено 8kB. Большинство эталонных тестов показывают, что лучше всего 64 kB, но 16kB лишь на несколько процентов хуже. Для всех эталонных тестов кластера MySQL, не было отмечено никакого измеримого различия в увеличении этого параметра выше 8kB.
[SCI]SendSignalId
Если выставлено в Y, то в передаваемые по сети данные помещается метка их отправителя. По умолчанию выключено.
[SCI]Checksum
Аналог [TCP]Checksum, но для подключений через SCI.

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 узла может быть пропущен в 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 узла):

Рекомендуется не использовать каталог, доступный через 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, определенный в файле конфигурации:

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 имеет два файла регистрации событий: файл регистрации кластера и файл регистрации узла.

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

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

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

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.

Расхождения в синтаксисе (приводящие к ошибкам при выполнении существующей прикладной программы).
Расхождения в ограничениях и поведении (могут приводить к ошибке при выполнении существующей прикладной программы)
Не обеспечиваемые свойства (это не ошибки, но не все равно неприятно).
Эффективность и связанные ограничения
Отсутствующие свойства системы.
Проблемы с несколькими серверами MySQL (не связаны с MyISAM или InnoDB).
Проблемы кластера (не связаны с MyISAM или InnoDB).

8 MySQL Cluster FAQ

Q: Что такое MySQL Cluster?

A: MySQL Cluster объединяет наиболее популярную базу данных с открытыми исходными текстами и параллельные серверы в виде кластера, со всей устойчивостью к сбоям, вообще характерной для кластерной архитектуры. Вы можете выполнять критические прикладные программы базы данных с доступностью 99.999%. MySQL Cluster максимизирует доступность Ваших прикладных программ открытым и рентабельным способом. MySQL Cluster дает возможность организациям преодолеть традиционные барьеры к принятию решений кластеризации с высокой доступностью:

Q: Что является главными особенностями и выгодами в MySQL Cluster?

Q: Что является типичной метрикой эффективности для MySQL Cluster?

Q: Для кого предназначен MySQL Cluster?

A: Любая организация, которая заинтересована универсальной надежностью на дешевых аппаратных средствах и программном обеспечении. Типичные заказчики включают телекоммуникационные и финансовые компании, которые нуждаются в значительной производительности, чтобы обработать большие объемы транзакций. Однако, MySQL Cluster представляет собой доступное решение для любой компании, требующей высокой доступности. Специфические пользователи и организации включают:

Q: Чем MySQL Cluster отличается от Oracle RAC?

A: MySQL Cluster и Oracle RAC сосредоточены на поставке решений базы данных с высокой доступностью. Однако, Oracle использует архитектуру распределенного хранения в то время, как MySQL Cluster использует архитектуру централизованной обработки.

Oracle RAC сложная программа, которая требует значительного капиталовложения в аппаратные средства, программное обеспечение и разработку. Oracle RAC полагается на архитектуру, которая требует дополнительного капиталовложения в SAN (Storage Area Network, локальная сеть памяти). Это приводит к следующим проблемам:

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

Q: MySQL Cluster поддерживает работу с MyISAM и InnoDB?

A: MySQL Cluster может включать способы хранения MyISAM и InnoDB. Но данные с высокой доступностью должны постоянно находиться именно в самом MySQL Cluster.

Узел памяти MySQL Cluster сохраняет данные MySQL Cluster, сервер MySQL анализирует SQL и посылает запросы узлу памяти. Сервер MySQL не сохраняет никакие данные, принадлежащие хранилищу MySQL Cluster.

Данные InnoDB/MyISAM все еще сохраняются на сервере MySQL и могут использоваться стандартным способом, но эти данные не скопируются, так что они невидимы с любого другого сервера MySQL в кластере.

Q: Сервер MySQL может постоянно находиться на одной машине, в то время как DB-узел на другой машине?

A: Да, сервер MySQL может быть на одном компьютере, а DB-узлы могут быть на других компьютерах.

Q: Как я могу проапгрейдить мой MySQL 3.x & 4.x до MySQL Cluster?

A: Данные, которые должны быть высокодоступными, должны постоянно находиться в хранилище MySQL Cluster. Если существующие MyISAM и/или InnoDB данные должны быть сделаны высокодоступными, они должны быть перенесены в это хранилище MySQL Cluster.

Перемещение представляет собой простое использование команды ALTER TABLE. В большинстве случаев, изменения кода прикладной программы или SQL-запроса не требуется.

Q: Какие платформы поддерживает MySQL Cluster?

A: MySQL Cluster доступен на наиболее популярных платформах, включая:

Q: Каковы минимальные системные требования для MySQL Cluster?

A: Вы можете выполнять целый кластер на одиночном компьютере:
OS:Linux (RedHat, SUSE), Solaris, AIX, HP-UX, Mac OS X
CPU:Intel/AMD x86/x86-64
Память:512 MB RAM
HDD:3 GB
Сеть:От одного узла (Ethernet TCP/IP)

Q: Какие системные требования для MySQL Cluster лучше?

A: Для каждого узла:

OS:Linux (RedHat, SUSE), Solaris, AIX, HP-UX, Mac OS X
CPU:2x Intel Xeon, Intel Itanium, AMD Opteron, Sun SPARC, IBM PowerPC
Память:16 GB RAM
HDD:4x36 GB SCSI (RAID 1)
Сеть:1-8 узлов (Gigabit Ethernet) или от 8 узлов специальной кластерной сети, например, SCI)

Q: MySQL Cluster доступен согласно двойной лицензии, обычной (коммерческой) и Open Source GPL?

A: Конечно, все разработки MySQL доступны согласно двойной лицензии. Коммерческая лицензия доступна для тех организаций, которые не хотят быть ограниченными условиями GPL. MySQL AB обеспечивает поддержку и разнообразные услуги заказчикам коммерческой лицензии.

Q: Какие инструментальные средства доступны для управления MySQL Cluster? Работает ли с ним MySQL Administrator?

Мощный набор инструментальных средств командной строки доступен, чтобы управлять MySQL Cluster. Также, MySQL Administrator уже расширен, чтобы работать с MySQL Cluster.

Q: Могу ли я резервировать таблицы кластера без их закрытия (то есть, "hot online backup")?

A: Да, MySQL Cluster поддерживает функцию Hot Backup.

Руководство по MySQL Cluster

Данное руководство подготовлено Алексеем Паутовым в рамках некоммерческого проекта RussianLDP:MySQL ( http://www.botik.ru/~rldp/mysql.htm). Именно по этому адресу публикуются новые версии, а также другие материалы по MySQL.

1 Обзор MySQL Cluster

MySQL Cluster использует новый способ хранения NDB Cluster, чтобы сделать возможным выполнение нескольких серверов MySQL в кластере. Способ NDB Cluster доступен в BitKeeper для MySQL 4.1.2 и в двоичных дистрибутивах MySQL-Max 4.1.3.

В настоящее время поддерживаются операционные системы Linux, Mac OS X и Solaris. Ведутся работы по поддержке NDB Cluster на всех операционных системах, поддерживаемых MySQL, включая Windows.

Вы можете подписаться на список рассылки MySQL Cluster. Подробности на http://lists.mysql.com. Вы можете также обратиться к форумам MySQL на http://forums.mysql.com.

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

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

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

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

2 Основные концепции MySQL Cluster

NDB представляет собой сочетание свойств постоянства данных и их высокой доступности.

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

Теперь опишем, как установить MySQL Cluster, состоящий из NDB и нескольких серверов MySQL.

Кластерная часть MySQL Cluster в настоящее время конфигурируется независимо от серверов MySQL. В MySQL Cluster каждая часть кластера именуется node (узел).

Обратите внимание: узел встречается во многих контекстах, но для MySQL Cluster он является процессом. Может иметься любое число узлов на одном компьютере.

Каждый узел имеет тип, и может быть несколько узлов каждого типа в MySQL Cluster. В минимальной конфигурации кластера MySQL будут по крайней мере три узла:

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

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

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