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 (8.4.5-ndb-8.4.5, Nodegroup: 0, *)
id=2 @198.51.100.2 (8.4.5-ndb-8.4.5, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=10 @198.51.100.10 (8.4.5-ndb-8.4.5)
[mysqld(API)] 2 node(s)
id=20 @198.51.100.20 (8.4.5-ndb-8.4.5)
id=21 @198.51.100.21 (8.4.5-ndb-8.4.5)
Наконец, мы предполагаем, что кластер содержит единственную таблицу 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 STOPNode 10 has shut down. Disconnecting to allow Management Server to shutdown $> -
Поскольку остановка сервера управления приводит к завершению работы клиента управления, вам необходимо запустить сервер управления из системной оболочки. Для простоты мы предполагаем, что
config.iniнаходится в той же директории, что и двоичный файл сервера управления, но на практике вы должны указать правильный путь к файлу конфигурации. Вы также должны указать опцию--reloadили--initial, чтобы сервер управления считывал новую конфигурацию из файла, а не из кэша конфигурации. Если текущая директория вашей оболочки совпадает с директорией, где расположен двоичный файл сервера управления, то вы можете запустить сервер управления, как показано здесь:$>
ndb_mgmd -f config.ini --reload2008-12-08 17:29:23 [MgmSrvr] INFO -- NDB Cluster Management Server. 8.4.5-ndb-8.4.5 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 (8.4.5-ndb-8.4.5, Nodegroup: 0, *)
id=2 @198.51.100.2 (8.4.5-ndb-8.4.5, 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 (8.4.5-ndb-8.4.5)
[mysqld(API)] 2 node(s)
id=20 @198.51.100.20 (8.4.5-ndb-8.4.5)
id=21 @198.51.100.21 (8.4.5-ndb-8.4.5)
Шаг 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 8.4.5)
Node 1: Started (version 8.4.5)
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 8.4.5)
ndb_mgm> Node 2: Started (version 8.4.5)
После выполнения каждой команды X
RESTARTNode перед продолжением.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 (8.4.5-ndb-8.4.5, Nodegroup: 0, *)
id=2 @198.51.100.2 (8.4.5-ndb-8.4.5, Nodegroup: 0)
id=3 @198.51.100.3 (8.4.5-ndb-8.4.5, no nodegroup)
id=4 @198.51.100.4 (8.4.5-ndb-8.4.5, no nodegroup)
[ndb_mgmd(MGM)] 1 node(s)
id=10 @198.51.100.10 (8.4.5-ndb-8.4.5)
[mysqld(API)] 2 node(s)
id=20 @198.51.100.20 (8.4.5-ndb-8.4.5)
id=21 @198.51.100.21 (8.4.5-ndb-8.4.5)
Шаг 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 (8.4.5-ndb-8.4.5, Nodegroup: 0, *)
id=2 @198.51.100.2 (8.4.5-ndb-8.4.5, Nodegroup: 0)
id=3 @198.51.100.3 (8.4.5-ndb-8.4.5, Nodegroup: 1)
id=4 @198.51.100.4 (8.4.5-ndb-8.4.5, Nodegroup: 1)
[ndb_mgmd(MGM)] 1 node(s)
id=10 @198.51.100.10 (8.4.5-ndb-8.4.5)
[mysqld(API)] 2 node(s)
id=20 @198.51.100.20 (8.4.5-ndb-8.4.5)
id=21 @198.51.100.21 (8.4.5-ndb-8.4.5)
Шаг 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.20.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 используется со списком идентификаторов разделов и набором определений разделов для создания новой схемы разбиения для таблицы, которая уже была явно разбита. Его использование здесь для перераспределения данных на новый узел группы NDB Cluster является исключением; когда используется таким образом, за ним не следуют другие ключевые слова или идентификаторы table_name
[ALGORITHM=INPLACE,] REORGANIZE PARTITIONREORGANIZE
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, прежде чем выполнять следующий.
Не нужно издавать операторы ALTER TABLE ...
REORGANIZE PARTITION для таблиц NDBCLUSTER, созданных после добавления новых узлов данных; данные, добавленные в такие таблицы, автоматически распределяются между всеми узлами данных. Однако в таблицах 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 не могут использовать новые узлы для распределения данных до тех пор, пока это не будет выполнено.)
© 2025 Oracle
Licensed under the GPLv2 License.
