25.6.7.3 Adding NDB Cluster Data Nodes Online: Detailed Example — MySQL 9.2

25.6.7.3 Добавление узлов данных NDB Cluster онлайн: подробный пример

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

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

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21

Примечание

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

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

-- NDB Cluster -- Management Client --
ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186 (using cleartext)
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (9.2.0-ndb-9.2.0, Nodegroup: 0, *)
id=2    @198.51.100.2  (9.2.0-ndb-9.2.0, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (9.2.0-ndb-9.2.0)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (9.2.0-ndb-9.2.0)
id=21   @198.51.100.21  (9.2.0-ndb-9.2.0)

Наконец, мы предполагаем, что кластер содержит единственную таблицу NDBCLUSTER, созданную, как показано здесь:

USE n;

CREATE TABLE ips (
    id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    country_code CHAR(2) NOT NULL,
    type CHAR(4) NOT NULL,
    ip_address VARCHAR(15) NOT NULL,
    addresses BIGINT UNSIGNED DEFAULT NULL,
    date BIGINT UNSIGNED DEFAULT NULL
)   ENGINE NDBCLUSTER;

Использование памяти и связанная информация, показанные позже в этом разделе, были получены после вставки примерно 50000 строк в эту таблицу.

Примечание

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

Шаг 1: Обновление конфигурационного файла. Откройте глобальный конфигурационный файл кластера в текстовом редакторе и добавьте секции [ndbd], соответствующие 2 новым узлам данных. (Мы присваиваем этим узлам данных идентификаторы 3 и 4 и предполагаем, что они будут работать на машинах-хостах по адресам 198.51.100.3 и 198.51.100.4 соответственно.) После добавления новых секций содержимое файла config.ini должно выглядеть так, где добавления к файлу показаны жирным шрифтом:

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[ndbd]
Id = 3
HostName = 198.51.100.3

[ndbd]
Id = 4
HostName = 198.51.100.4

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21

После внесения необходимых изменений сохраните файл.

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

Остановите сервер управления, используя команду клиента управления STOP, как показано здесь:
```
ndb_mgm> 10 STOP
Node 10 has shut down.
Disconnecting to allow Management Server to shutdown

$>
```
Поскольку остановка сервера управления приводит к завершению клиента управления, вы должны запустить сервер управления из командной оболочки системы. Для простоты мы предполагаем, что config.ini находится в той же директории, что и двоичный файл сервера управления, но на практике вы должны указать правильный путь к конфигурационному файлу. Вы также должны указать параметр --reload или --initial, чтобы сервер управления читал новую конфигурацию из файла, а не из кэша конфигурации. Если текущий каталог вашей оболочки также совпадает с каталогом, в котором расположен двоичный файл сервера управления, то вы можете запустить сервер управления, как показано здесь:
```
$> ndb_mgmd -f config.ini --reload
2008-12-08 17:29:23 [MgmSrvr] INFO     -- NDB Cluster Management Server. 9.2.0-ndb-9.2.0
2008-12-08 17:29:23 [MgmSrvr] INFO     -- Reading cluster configuration from 'config.ini'
```

Если вы проверите вывод SHOW в клиенте управления после перезапуска процесса ndb_mgm, вы теперь должны увидеть что-то вроде этого:

-- NDB Cluster -- Management Client --
ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186 (using cleartext)
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (9.2.0-ndb-9.2.0, Nodegroup: 0, *)
id=2    @198.51.100.2  (9.2.0-ndb-9.2.0, Nodegroup: 0)
id=3 (not connected, accepting connect from 198.51.100.3)
id=4 (not connected, accepting connect from 198.51.100.4)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (9.2.0-ndb-9.2.0)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (9.2.0-ndb-9.2.0)
id=21   @198.51.100.21  (9.2.0-ndb-9.2.0)

Шаг 3: Выполните поэтапный перезапуск существующих узлов данных. Этот шаг можно выполнить полностью в клиенте управления кластером, используя команду RESTART, как показано здесь:

ndb_mgm> 1 RESTART
Node 1: Node shutdown initiated
Node 1: Node shutdown completed, restarting, no start.
Node 1 is being restarted

ndb_mgm> Node 1: Start initiated (version 9.2.0)
Node 1: Started (version 9.2.0)

ndb_mgm> 2 RESTART
Node 2: Node shutdown initiated
Node 2: Node shutdown completed, restarting, no start.
Node 2 is being restarted

ndb_mgm> Node 2: Start initiated (version 9.2.0)

ndb_mgm> Node 2: Started (version 9.2.0)

Важно

После выполнения каждой команды X RESTART дождитесь, пока клиент управления не сообщит Node X: Started (version ...) перед продолжением дальнейших действий.

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

Шаг 4: Выполните поэтапный перезапуск всех узлов API кластера. Остановите и перезапустите каждый сервер MySQL, действующий в качестве узла SQL в кластере, используя mysqladmin shutdown за которым следует mysqld_safe (или другой скрипт запуска). Это должно быть похоже на то, что показано здесь, где password — это пароль MySQL root для данного экземпляра сервера MySQL:

$> mysqladmin -uroot -ppassword shutdown
081208 20:19:56 mysqld_safe mysqld from pid file
/usr/local/mysql/var/tonfisk.pid ended
$> mysqld_safe --ndbcluster --ndb-connectstring=198.51.100.10 &
081208 20:20:06 mysqld_safe Logging to '/usr/local/mysql/var/tonfisk.err'.
081208 20:20:06 mysqld_safe Starting mysqld daemon with databases
from /usr/local/mysql/var

Конечно, точный ввод и вывод зависят от того, как и где MySQL установлен в системе, а также от выбранных вами параметров запуска (и от того, указаны ли некоторые или все эти параметры в файле my.cnf).

Шаг 5: Выполните начальный запуск новых узлов данных. Из командной оболочки системы на каждом из хостов для новых узлов данных запустите узлы данных, как показано здесь, используя опцию --initial:

$> ndbd -c 198.51.100.10 --initial

Примечание

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

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

ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186 (using cleartext)
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (9.2.0-ndb-9.2.0, Nodegroup: 0, *)
id=2    @198.51.100.2  (9.2.0-ndb-9.2.0, Nodegroup: 0)
id=3    @198.51.100.3  (9.2.0-ndb-9.2.0, no nodegroup)
id=4    @198.51.100.4  (9.2.0-ndb-9.2.0, no nodegroup)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (9.2.0-ndb-9.2.0)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (9.2.0-ndb-9.2.0)
id=21   @198.51.100.21  (9.2.0-ndb-9.2.0)

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

ndb_mgm> CREATE NODEGROUP 3,4
Nodegroup 1 created

Выполнив SHOW снова, вы можете проверить, что узлы данных 3 и 4 присоединились к новой группе узлов (снова показано жирным шрифтом):

ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186 (using cleartext)
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (9.2.0-ndb-9.2.0, Nodegroup: 0, *)
id=2    @198.51.100.2  (9.2.0-ndb-9.2.0, Nodegroup: 0)
id=3    @198.51.100.3  (9.2.0-ndb-9.2.0, Nodegroup: 1)
id=4    @198.51.100.4  (9.2.0-ndb-9.2.0, Nodegroup: 1)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (9.2.0-ndb-9.2.0)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (9.2.0-ndb-9.2.0)
id=21   @198.51.100.21  (9.2.0-ndb-9.2.0)

Шаг 7: Перераспределение данных кластера. При создании группы узлов существующие данные и индексы не автоматически распределяются по узлам данных новой группы узлов, как вы можете видеть, выдав соответствующую команду REPORT в клиенте управления:

ndb_mgm> ALL REPORT MEMORY

Node 1: Data usage is 5%(177 32K pages of total 3200)
Node 1: Index usage is 0%(108 8K pages of total 12832)
Node 2: Data usage is 5%(177 32K pages of total 3200)
Node 2: Index usage is 0%(108 8K pages of total 12832)
Node 3: Data usage is 0%(0 32K pages of total 3200)
Node 3: Index usage is 0%(0 8K pages of total 12832)
Node 4: Data usage is 0%(0 32K pages of total 3200)
Node 4: Index usage is 0%(0 8K pages of total 12832)

Используя ndb_desc с опцией -p, которая заставляет вывод включать информацию о разбиении, вы можете увидеть, что таблица по-прежнему использует только 2 разбиения (в разделе Per partition info вывода, показанном здесь жирным шрифтом):

$> ndb_desc -c 198.51.100.10 -d n ips -p
-- ips --
Version: 1
Fragment type: 9
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 6
Number of primary keys: 1
Length of frm data: 340
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
FragmentCount: 2
TableStatus: Retrieved
-- Attributes --
id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR
country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY
addresses Bigunsigned NULL AT=FIXED ST=MEMORY
date Bigunsigned NULL AT=FIXED ST=MEMORY

-- Indexes --
PRIMARY KEY(id) - UniqueHashIndex
PRIMARY(id) - OrderedIndex

-- Per partition info --
Partition   Row count   Commit count  Frag fixed memory   Frag varsized memory
0           26086       26086         1572864             557056
1           26329       26329         1605632             557056

Вы можете заставить данные перераспределиться по всем узлам данных, выполнив для каждой таблицы NDB оператор ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION в клиенте mysql.

Важно

ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION не работает с таблицами, которые были созданы с опцией MAX_ROWS. Вместо этого используйте ALTER TABLE ... ALGORITHM=INPLACE, MAX_ROWS=... для реорганизации таких таблиц.

Имейте в виду, что использование MAX_ROWS для установки количества разбиений на таблицу устарело, и вы должны использовать PARTITION_BALANCE вместо этого; см. Раздел 15.1.21.12, «Настройка параметров комментариев NDB» для получения дополнительной информации.

После выполнения оператора ALTER TABLE ips ALGORITHM=INPLACE, REORGANIZE PARTITION, вы можете увидеть с помощью ndb_desc, что данные для этой таблицы теперь хранятся с использованием 4 разбиений, как показано здесь (с соответствующими частями вывода жирным шрифтом):

$> ndb_desc -c 198.51.100.10 -d n ips -p
-- ips --
Version: 16777217
Fragment type: 9
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 6
Number of primary keys: 1
Length of frm data: 341
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
FragmentCount: 4
TableStatus: Retrieved
-- Attributes --
id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR
country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY
addresses Bigunsigned NULL AT=FIXED ST=MEMORY
date Bigunsigned NULL AT=FIXED ST=MEMORY

-- Indexes --
PRIMARY KEY(id) - UniqueHashIndex
PRIMARY(id) - OrderedIndex

-- Per partition info --
Partition   Row count   Commit count  Frag fixed memory   Frag varsized memory
0           12981       52296         1572864             557056
1           13236       52515         1605632             557056
2           13105       13105         819200              294912
3           13093       13093         819200              294912

Примечание

Обычно, оператор ALTER TABLE table_name [ALGORITHM=INPLACE,] REORGANIZE PARTITION используется со списком идентификаторов разделов и набором определений разделов для создания новой схемы разбиения для таблицы, которая уже явно разделена. Его использование здесь для перераспределения данных на новый узел группы узлов NDB Cluster является исключением из этого правила; при использовании таким образом, за ним не следуют никакие другие ключевые слова или идентификаторы REORGANIZE PARTITION.

Для получения дополнительной информации см. Раздел 15.1.9, «Оператор ALTER TABLE».

Кроме того, для каждой таблицы оператор ALTER TABLE должен быть последовать оператор OPTIMIZE TABLE для освобождения неиспользуемого пространства. Список всех таблиц NDBCLUSTER можно получить, выполнив следующий запрос к таблице Информационной схемы TABLES:

SELECT TABLE_SCHEMA, TABLE_NAME
    FROM INFORMATION_SCHEMA.TABLES
    WHERE ENGINE = 'NDBCLUSTER';

Примечание

Значение INFORMATION_SCHEMA.TABLES.ENGINE для таблицы NDB Cluster всегда равно NDBCLUSTER, независимо от того, использовал ли оператор CREATE TABLE для создания таблицы (или оператор ALTER TABLE для преобразования существующей таблицы из другого движка хранилища) NDB или NDBCLUSTER в опции ENGINE.

После выполнения этих операторов в выводе ALL REPORT MEMORY можно увидеть, что данные и индексы теперь перераспределены между всеми узлами данных кластера, как показано здесь:

ndb_mgm> ALL REPORT MEMORY

Node 1: Data usage is 5%(176 32K pages of total 3200)
Node 1: Index usage is 0%(76 8K pages of total 12832)
Node 2: Data usage is 5%(176 32K pages of total 3200)
Node 2: Index usage is 0%(76 8K pages of total 12832)
Node 3: Data usage is 2%(80 32K pages of total 3200)
Node 3: Index usage is 0%(51 8K pages of total 12832)
Node 4: Data usage is 2%(80 32K pages of total 3200)
Node 4: Index usage is 0%(50 8K pages of total 12832)

Примечание

Поскольку одновременно можно выполнить только одну операцию DDL над таблицами NDBCLUSTER, необходимо дождаться завершения каждого оператора ALTER TABLE ... REORGANIZE PARTITION перед выполнением следующего.

Для таблиц NDBCLUSTER, созданных после добавления новых узлов данных, не требуется выполнять операторы ALTER TABLE ... REORGANIZE PARTITION; данные, добавляемые в такие таблицы, автоматически распределяются между всеми узлами данных. Однако в таблицах NDBCLUSTER, существовавших до добавления новых узлов, ни существующие, ни новые данные не распределяются с использованием новых узлов до тех пор, пока эти таблицы не будут перестроены с помощью оператора ALTER TABLE ... REORGANIZE PARTITION.

Альтернативный метод без перестройки кластера. Можно избежать необходимости перестройки кластера, настроив дополнительные узлы данных, но не запустив их при первом запуске кластера. Как и прежде, предположим, что вы хотите начать с двух узлов данных — узлов 1 и 2 — в одной группе узлов и позже расширить кластер до четырёх узлов, добавив вторую группу узлов, состоящую из узлов 3 и 4:

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[ndbd]
Id = 3
HostName = 198.51.100.3
Nodegroup = 65536

[ndbd]
Id = 4
HostName = 198.51.100.4
Nodegroup = 65536

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21

Узлы данных, которые будут запущены позже (узлы 3 и 4), можно настроить с помощью NodeGroup = 65536, в этом случае узлы 1 и 2 можно запустить, как показано здесь:

$> ndbd -c 198.51.100.10 --initial

Узлы данных, настроенные с помощью NodeGroup = 65536, обрабатываются сервером управления так, как будто вы запустили узлы 1 и 2 с помощью --nowait-nodes=3,4 после ожидания периода времени, определяемого параметром конфигурации узла данных StartNoNodeGroupTimeout. По умолчанию это 15 секунд (15000 миллисекунд).

Примечание

StartNoNodegroupTimeout должен быть одинаковым для всех узлов данных в кластере; по этой причине его всегда следует устанавливать в разделе [ndbd default] файла config.ini, а не для отдельных узлов данных.

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

Запустите узлы данных 3 и 4, вызвав процесс узла данных один раз для каждого нового узла:
```
$> ndbd -c 198.51.100.10 --initial
```
Выполните соответствующую команду CREATE NODEGROUP в клиенте управления:
```
ndb_mgm> CREATE NODEGROUP 3,4
```
В клиенте mysql выполните операторы ALTER TABLE ... REORGANIZE PARTITION и OPTIMIZE TABLE для каждой существующей таблицы NDBCLUSTER. (Как отмечалось в другом месте данного раздела, существующие таблицы NDB Cluster не могут использовать новые узлы для распределения данных до тех пор, пока это не будет сделано.)