17.5.13.3. Добавление MySQL Cluster Data Nodes Online: Подробный Пример

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

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

[ndbd default]DataMemory = 100MIndexMemory = 100MNoOfReplicas = 2DataDir = /usr/local/mysql/var/mysql-cluster[ndbd]Id = 1HostName = 192.168.0.1[ndbd]Id = 2HostName = 192.168.0.2[mgm]HostName = 192.168.0.10Id = 10[api]Id=20HostName = 192.168.0.20[api]Id=21HostName = 192.168.0.21

Отметить

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

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

-- NDB Cluster -- Management Client --ndb_mgm> SHOWConnected to Management Server at: 192.168.0.10:1186Cluster Configuration---------------------[ndbd(NDB)]     2 node(s)id=1    @192.168.0.1  (5.6.11-ndb-7.3.3, Nodegroup: 0, Master)id=2    @192.168.0.2  (5.6.11-ndb-7.3.3, Nodegroup: 0)[ndb_mgmd(MGM)] 1 node(s)id=10   @192.168.0.10  (5.6.11-ndb-7.3.3)[mysqld(API)]   2 node(s)id=20   @192.168.0.20  (5.6.11-ndb-7.3.3)id=21   @192.168.0.21  (5.6.11-ndb-7.3.3)

Наконец, мы предполагаем, что кластер содержит сингл 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, используемый для процессов узла данных. Однако — начинание с MySQL Cluster NDB 7.0.4 — можно также применить этот пример, если Вы используете многопоточный ndbmtd, заменяя ndbmtd для ndbd везде, где это появляется в шагах, которые следуют. (Ошибка #43108)

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

[ndbd default]DataMemory = 100MIndexMemory = 100MNoOfReplicas = 2DataDir = /usr/local/mysql/var/mysql-cluster[ndbd]Id = 1HostName = 192.168.0.1[ndbd]Id = 2HostName = 192.168.0.2[ndbd]Id = 3HostName = 192.168.0.3[ndbd]Id = 4HostName = 192.168.0.4[mgm]HostName = 192.168.0.10Id = 10[api]Id=20HostName = 192.168.0.20[api]Id=21HostName = 192.168.0.21

Как только Вы произвели необходимые изменения, сохраните файл.

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

Остановите сервер управления, используя клиент управления STOP команда, как показано здесь:
```
ndb_mgm> 10 STOPNode 10 has shut down.Disconnecting to allow Management Server to shutdownshell>
```
Поскольку завершение работы сервера управления заставляет клиент управления завершаться, следует запустить сервер управления с системной оболочки. Для простоты мы принимаем это config.ini находится в том же самом каталоге как двоичный файл сервера управления, но практически, следует предоставить корректный путь к конфигурационному файлу. Следует также предоставить --reload или --initial опция так, чтобы сервер управления считал новую конфигурацию из файла, а не его кэша конфигурации. Если текущий каталог Вашей оболочки является также тем же самым как каталогом, где двоичный файл сервера управления располагается, то можно вызвать сервер управления как показано здесь:
```
shell> ndb_mgmd -f config.ini
                    --reload2008-12-08 17:29:23 [MgmSrvr] INFO     -- NDB Cluster Management Server. 5.6.11-ndb-7.3.32008-12-08 17:29:23 [MgmSrvr] INFO     -- Reading cluster configuration from 'config.ini'
```

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

-- NDB Cluster -- Management Client --ndb_mgm> SHOWConnected to Management Server at: 192.168.0.10:1186Cluster Configuration---------------------[ndbd(NDB)]     2 node(s)id=1    @192.168.0.1  (5.6.11-ndb-7.3.3, Nodegroup: 0, Master)id=2    @192.168.0.2  (5.6.11-ndb-7.3.3, Nodegroup: 0)id=3 (not connected, accepting connect from 192.168.0.3)id=4 (not connected, accepting connect from 192.168.0.4)[ndb_mgmd(MGM)] 1 node(s)id=10   @192.168.0.10  (5.6.11-ndb-7.3.3)[mysqld(API)]   2 node(s)id=20   @192.168.0.20  (5.6.11-ndb-7.3.3)id=21   @192.168.0.21  (5.6.11-ndb-7.3.3)

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

ndb_mgm> 1 RESTARTNode 1: Node shutdown initiatedNode 1: Node shutdown completed, restarting, no start.Node 1 is being restartedndb_mgm> Node 1: Start initiated (version 7.3.3)Node 1: Started (version 7.1.29)ndb_mgm> 2 RESTARTNode 2: Node shutdown initiatedNode 2: Node shutdown completed, restarting, no start.Node 2 is being restartedndb_mgm> Node 2: Start initiated (version 7.3.3)ndb_mgm> Node 2: Started (version 7.3.3)

Важный

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

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

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

shell> mysqladmin -uroot -ppassword shutdown081208 20:19:56 mysqld_safe mysqld from pid file/usr/local/mysql/var/tonfisk.pid endedshell> mysqld_safe --ndbcluster --ndb-connectstring=192.168.0.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 databasesfrom /usr/local/mysql/var

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

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

shell> ndbd -c 192.168.0.10 --initial

Отметить

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

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

ndb_mgm> SHOWConnected to Management Server at: 192.168.0.10:1186Cluster Configuration---------------------[ndbd(NDB)]     2 node(s)id=1    @192.168.0.1  (5.6.11-ndb-7.3.3, Nodegroup: 0, Master)id=2    @192.168.0.2  (5.6.11-ndb-7.3.3, Nodegroup: 0)id=3    @192.168.0.3  (5.6.11-ndb-7.3.3, no nodegroup)id=4    @192.168.0.4  (5.6.11-ndb-7.3.3, no nodegroup)[ndb_mgmd(MGM)] 1 node(s)id=10   @192.168.0.10  (5.6.11-ndb-7.3.3)[mysqld(API)]   2 node(s)id=20   @192.168.0.20  (5.6.11-ndb-7.3.3)id=21   @192.168.0.21  (5.6.11-ndb-7.3.3)

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

ndb_mgm> CREATE NODEGROUP 3,4Nodegroup 1 created

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

ndb_mgm> SHOWConnected to Management Server at: 192.168.0.10:1186Cluster Configuration---------------------[ndbd(NDB)]     2 node(s)id=1    @192.168.0.1  (5.6.11-ndb-7.3.3, Nodegroup: 0, Master)id=2    @192.168.0.2  (5.6.11-ndb-7.3.3, Nodegroup: 0)id=3    @192.168.0.3  (5.6.11-ndb-7.3.3, Nodegroup: 1)id=4    @192.168.0.4  (5.6.11-ndb-7.3.3, Nodegroup: 1)[ndb_mgmd(MGM)] 1 node(s)id=10   @192.168.0.10  (5.6.11-ndb-7.3.3)[mysqld(API)]   2 node(s)id=20   @192.168.0.20  (5.6.11-ndb-7.3.3)id=21   @192.168.0.21  (5.6.11-ndb-7.3.3)

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

ndb_mgm> ALL REPORT MEMORYNode 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 раздел вывода, показанного здесь полужирным текст):

shell> ndb_desc -c 192.168.0.10 -d n ips
        -p-- ips --Version: 1Fragment type: 9K Value: 6Min load factor: 78Max load factor: 80Temporary table: noNumber of attributes: 6Number of primary keys: 1Length of frm data: 340Row Checksum: 1Row GCI: 1SingleUserMode: 0ForceVarPart: 1FragmentCount: 2TableStatus: Retrieved-- Attributes --id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCRcountry_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORYtype Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORYip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORYaddresses Bigunsigned NULL AT=FIXED ST=MEMORYdate Bigunsigned NULL AT=FIXED ST=MEMORY-- Indexes --PRIMARY KEY(id) - UniqueHashIndexPRIMARY(id) - OrderedIndex-- Per partition info --Partition Row count Commit count Frag fixed memory Frag
        varsized memory0 26086 26086 1572864 5570561 26329 26329 1605632 557056NDBT_ProgramExit: 0 - OK

Можно заставить данные быть перераспределенными среди всех узлов данных, выполняя для каждого NDBCLUSTER таблица, ALTER ONLINE TABLE ... REORGANIZE PARTITION оператор в mysql клиенте. После делания заявления ALTER ONLINE TABLE ips REORGANIZE PARTITION, можно видеть использование ndb_desc, что данные для этой таблицы теперь хранятся, используя 4 раздела, как показано здесь (с соответствующими частями вывода полужирным вводят):

shell> ndb_desc -c 192.168.0.10 -d n ips
        -p-- ips --Version: 16777217Fragment type: 9K Value: 6Min load factor: 78Max load factor: 80Temporary table: noNumber of attributes: 6Number of primary keys: 1Length of frm data: 341Row Checksum: 1Row GCI: 1SingleUserMode: 0ForceVarPart: 1FragmentCount: 4TableStatus: Retrieved-- Attributes --id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCRcountry_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORYtype Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORYip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORYaddresses Bigunsigned NULL AT=FIXED ST=MEMORYdate Bigunsigned NULL AT=FIXED ST=MEMORY-- Indexes --PRIMARY KEY(id) - UniqueHashIndexPRIMARY(id) - OrderedIndex-- Per partition info --Partition Row count Commit count Frag fixed memory Frag
        varsized memory0 12981 52296 1572864 5570561 13236 52515 1605632 5570562 13105 13105 819200 2949123 13093 13093
        819200 294912NDBT_ProgramExit: 0 - OK

Отметить

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

Для получения дополнительной информации см. Раздел 13.1.7,"ALTER TABLE Синтаксис".

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

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

Отметить

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

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

ndb_mgm> ALL REPORT MEMORYNode 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 ONLINE TABLE ... REORGANIZE PARTITION оператор, чтобы закончиться прежде, чем выпустить следующий.

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

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

[ndbd default]DataMemory = 100MIndexMemory = 100MNoOfReplicas = 2DataDir = /usr/local/mysql/var/mysql-cluster[ndbd]Id = 1HostName = 192.168.0.1[ndbd]Id = 2HostName = 192.168.0.2[ndbd]Id = 3HostName = 192.168.0.3Nodegroup = 65536   [ndbd]Id = 4HostName = 192.168.0.4Nodegroup = 65536   [mgm]HostName = 192.168.0.10Id = 10[api]Id=20HostName = 192.168.0.20[api]Id=21HostName = 192.168.0.21

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

shell> ndbd -c 192.168.0.10 --initial

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

Отметить

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

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

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