21.6.7.3 Adding NDB Cluster Data Nodes Online: Detailed Example — MySQL 5.7

21.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
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (5.7.44-ndb-7.5.36, Nodegroup: 0, *)
id=2    @198.51.100.2  (5.7.44-ndb-7.5.36, Nodegroup: 0)

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

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

Наконец, мы предполагаем, что кластер содержит одну таблицу 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. 5.7.44-ndb-7.5.36
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
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (5.7.44-ndb-7.5.36, Nodegroup: 0, *)
id=2    @198.51.100.2  (5.7.44-ndb-7.5.36, 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  (5.7.44-ndb-7.5.36)

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

Шаг 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 7.5.36)
Node 1: Started (version 7.5.36)

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 7.5.36)

ndb_mgm> Node 2: Started (version 7.5.36)

Важно

После выполнения каждой команды 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
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (5.7.44-ndb-7.5.36, Nodegroup: 0, *)
id=2    @198.51.100.2  (5.7.44-ndb-7.5.36, Nodegroup: 0)
id=3    @198.51.100.3  (5.7.44-ndb-7.5.36, no nodegroup)
id=4    @198.51.100.4  (5.7.44-ndb-7.5.36, no nodegroup)

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

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

Шаг 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
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (5.7.44-ndb-7.5.36, Nodegroup: 0, *)
id=2    @198.51.100.2  (5.7.44-ndb-7.5.36, Nodegroup: 0)
id=3    @198.51.100.3  (5.7.44-ndb-7.5.36, Nodegroup: 1)
id=4    @198.51.100.4  (5.7.44-ndb-7.5.36, Nodegroup: 1)

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

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

Шаг 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

NDBT_ProgramExit: 0 - OK

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

Важно

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

Имейте в виду, что использование MAX_ROWS для установки количества разделов на таблицу устарело в NDB 7.5.4 и более поздних версиях, где вместо этого следует использовать PARTITION_BALANCE; см. Раздел 13.1.18.9, «Установка опций комментариев 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

NDBT_ProgramExit: 0 - OK

Примечание

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

Для получения дополнительной информации см. Раздел 13.1.8, «Команда 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 не могут использовать новые узлы для распределения данных до тех пор, пока это не будет сделано.)