Глава 4. Команды клиента MySQL Cluster Manager

Секции в этой главе описывают команды, используемые в MySQL Cluster Manager 1.4.8 для таких задач, как определение мест, пакетов и экземпляров ySQL NDB Cluster, настройки MySQL NDB Cluster и получения статуса MySQL NDB Cluster. Эти команды даются агенту управления, используя клиент mysql, включенную в MySQL NDB Cluster. Каждая команда клиента MySQL Cluster Manager принимает форму, показанную здесь:

instruction [options] [arguments]
options:
option [option] [...]

option:
--option-long-name[=value-list]
| -option-short-name [value-list]

value-list:
value[,value[,...]]
arguments:
argument[argument] [...]

Эта команда MySQL Cluster Manager запускает MySQL NDB Cluster mycluster и отправляет процесс в фон, чтобы клиент мог использоваться, чтобы выполнить другие команды, не имея необходимости ждать завершения start cluster:

start cluster --background mycluster;

В этом примере команда содержит инструкцию start cluster. Инструкция состоит из одного или двух ключевых слов, например, set или show status. Эта инструкция изменяется опцией --background, однако, это не назначает значений.

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

start cluster -B mycluster;

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

Не путайте варианты, данные командам MySQL Cluster Manager, с опциями mysql. Опции команд MySQL Cluster Manager всегда передаются как часть команды MySQL Cluster Manager, они не передаются клиенту mysql.

Кроме того, вы не можете выпустить запросы или другие SQL-операторы в MySQL Cluster Manager. Они не признаны клиентом и отклонены с ошибкой. Обратное из этого также верно: команды клиента MySQL Cluster Manager не распознаются клиентом mysql.

Инструкция просто берет аргумент. Аргумент обычно идентификатор, который называет объект, который будет обработан, в этом случае команда удаляет место, имя которого соответствует аргументу.

Дополнительная опция --verbose может использоваться для create cluster, add process и list hosts . В обоих случаях использование выбора заставляет команду возвращать список из процессов группы MySQL NDB, затронутых командой: это включает ID их узлов, типы процесса и хосты, где они расположены.

Идентификаторы в командах клиента. Идентификатор MySQL Cluster Manager состоит из любой последовательности знаков из числа следующего:

Идентификатор MySQL Cluster Manager должен начинаться с буквы или цифры.

Чувствительность к регистру для команд клиента. Правила для чувствительности к регистру идентификаторов MySQL Cluster Manager, команд, вариантов команд, имен процессов и признаков конфигурации следующие:

Значения, которые содержат пробелы, должны быть указаны, используя одинарную кавычку ('). Например, если вы хотите определить пакет, названный mypackage для места mysite, использование /usr/local/mysql cluster/7.3 (с пробелом между mysql и cluster) как пути к основному каталогу на всех хостах, правильная команда была бы add package --basedir='/usr/local/mysql cluster/7.3' mypackage.

Чтобы уменьшить возможность ошибок в чтении и вводе в MySQL Cluster Manager, мы рекомендуем избежать использования пробелов, когда это возможно.

Каждая команда должна закончиться символом терминатора. По умолчанию это точка с запятой (;). Однако, последовательности \g и \G также поддерживаются как терминаторы команды. \G заставляет вывод быть вертикально отформатированной (то же самое, как в стандартном mysql):

mcm> get DataMemory mycluster\G
*************************** 1. row ***************************
Name: DataMemory
 Value: 500M
Process1: ndbd
 Id1: 2
Process2:
 Id2:
 Level: Process
 Comment:
*************************** 2. row ***************************
Name: DataMemory
 Value: 500M
Process1: ndbd
 Id1: 3
Process2:
 Id2:
 Level: Process
 Comment:
2 rows in set (0.22 sec)

В соответствии с соглашением (по причинам удобочитаемости), обычно не используется терминатор команды, показывая синтаксис для команды в формате Backus-Naur или когда команды MySQL Cluster Manager включаются в текст. Однако, если вы не используете терминатор запроса при вводе в клиенте MySQL Cluster Manager, он отобразит запрос -> пока вы не введете терминатор, как показано здесь:

mcm> list sites
  ->
  ->
  ->
  -> ;
Empty set (1.50 sec)

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

mcm> create site --hosts=tonfisk,flundra mysite;
+---------------------------+
| Command result            |
+---------------------------+
| Site created successfully |
+---------------------------+
1 row in set (7.41 sec)

Команда создает место, названное mysite, состоящее из двух хостов tonfisk и flundra. См. раздел 4.2.6. Так как мы использовали длинную форму --hosts, мы были обязаны использовать знак равенства (=), чтобы отметить конец имени опции и начало списка значений. Вы не должны вставлять пробелы прежде или после знака равенства, это вызывает ошибку, как показано здесь:

mcm> create site --hosts =grindval,haj yoursite;
ERROR 7 (00MGR): Option --hosts requires a value
mcm> create site --hosts= grindval,haj yoursite;
ERROR 7 (00MGR): Option --hosts requires a value

Краткая форма выбора не использует знак "равно". Вместо этого список значений отделен от опции пространством. Используя опцию -h, предыдущая команда create site выглядела бы так:

mcm> create site -h tonfisk,flundra mysite;
+---------------------------+
| Command result            |
+---------------------------+
| Site created successfully |
+---------------------------+
1 row in set (7.41 sec)

Краткие формы вариантов на самом деле принимают многократные пробелы между именем выбора и списком значений, однако, одиночный пробел достаточен. Если вы опускаете пробел или пытаетесь использовать знак "равно", команда терпит неудачу с ошибкой, как показано здесь:

mcm> create site -htonfisk,flundra mysite;
ERROR 6 (00MGR): Illegal number of operands
mcm> create site -h=tonfisk,flundra mysite;
ERROR 3 (00MGR): Illegal syntax

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

mcm> create site --hosts=tonfisk, flundra mysite;
ERROR 6 (00MGR): Illegal number of operands

Как вы видите, клиент MySQL Cluster Manager возвращает набор результатов так же, как SQL-оператор в стандартном клиенте mysql. Набор результатов, возвращенный MySQL Cluster Manager, состоит из одного из следующего:

Каждая команда должна быть введена отдельно, невозможно объединить многократные команды на одной строке.

Варианты, характерные для команд клиента. Следующие три варианта характерны для большей части команд клиента MySQL Cluster Manager:

  1. --help (краткая форма: -?): Характерна для всех команд клиента. Обеспечивает помощь для данной команды. Посмотрите раздел 4.1.

  2. --force (краткая форма -f): Отключает любые проверки безопасности, которые будут обойдены, выполняя команду. Например, delete cluster mycluster терпит неудачу, если какой-либо процесс MySQL NDB Cluster в кластере MySQL NDB mycluster работает, однако, delete cluster --force mycluster вызывает закрытие mycluster, сопровождаемое удалением mycluster из инвентаря MySQL Cluster Manager.

    --force поддерживается для следующих команд MySQL Cluster Manager:

  3. --background (краткая форма -B ): Вместо того, чтобы ждать окончания исполнения команды, MySQL Cluster Manager немедленно возвращает командную строку, позволяя вам выполнить дополнительные задачи в клиенте в то время, как та команда продолжает выполняться в фоновом режиме. Это может быть полезно, выполняя команды, которые могли бы потребовать некоторое время (такие, как старт кластера с очень многими узлами).

    Этот выбор поддерживается всеми командами клиента за исключением create site, delete site, add hosts, add package и delete package.

4.1. Помощь онлайн и информационные команды

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

Листинг команд клиента MySQL Cluster Manager. Для получения списка всех команд с краткими описаниями используйте list commands:

mcm> list commands;
+---------------------------------------------------------------------------+
| Help                                                                      |
+---------------------------------------------------------------------------+
| COMMANDS                                                                  |
|                                                                           |
| abort backup     Abort an ongoing cluster backup.                         |
| add hosts        Add hosts to site.                                       |
| add package      Add a package alias.                                     |
| add process      Add cluster process.                                     |
| autotune         Autotune a cluster to given use-case template.           |
| backup agents    Backup the agents repository and metadata.               |
| backup cluster   Backup a cluster.                                        |
| change log-level Change the log-level.                                    |
| change process   Change process type.                                     |
| collect logs     Collect log files.                                       |
| create cluster   Create a cluster.                                        |
| create site      Create a site.                                           |
| delete cluster   Delete a cluster.                                        |
| delete package   Delete a package.                                        |
| delete site      Delete a site.                                           |
| get              Get configuration variables.                             |
| import cluster   Import a running cluster.                                |
| import config    Import the configuration of a running cluster.           |
| list backups     List backup images.                                      |
| list clusters    List all clusters.                                       |
| list commands    List the help text.                                      |
| list hosts       List hosts in site.                                      |
| list nextnodeids List next nodeids to be allocated.                       |
| list packages    List all packages.                                       |
| list processes   List processes.                                          |
| list sites       List all sites.                                          |
| remove hosts     Remove hosts from site.                                  |
| remove process   Remove a cluster process.                                |
| reset            Reset configuration variables.                           |
| restart cluster  Restart a cluster.                                       |
| restore cluster  Restore a cluster.                                       |
| rotate log       Rotate the mcmd log.                                     |
| set              Set configuration variables.                             |
| show settings    Show agent settings.                                     |
| show status      Show cluster, process, operation or backup status.       |
| start cluster    Start a cluster.                                         |
| start process    Start a cluster process.                                 |
| stop agents      Stop agents in site.                                     |
| stop cluster     Stop a cluster.                                          |
| stop process     Stop a cluster process.                                  |
| upgrade cluster  Upgrade a cluster.                                       |
| version          Print version information.                               |
|                                                                           |
| GLOBAL OPTIONS                                                            |
| Options that can be used with all commands                                |
|                                                                           |
| --help | -?      Print detailed help.                                     |
|                                                                           |
| Use '<COMMAND> --help' to see verbose help for individual commands. |
+---------------------------------------------------------------------------+
50 rows in set (0.03 sec)

Получение информации об определенной команде MySQL Cluster Manager. Чтобы получить более подробную помощь, определенную для данной команды, вызовите команду, используя опцию --help :

mcm> create site --help;
+----------------------------------------------------------------+
| Help                                                           |
+----------------------------------------------------------------+
|                                                                |
| create site [options] <sitename>                         |
|                                                                |
| Creates a site from the hosts listed in --hosts.               |
|                                                                |
| Required options:                                              |
| --hosts | -h   Comma separated list of hostnames.              |
|   Format: --hosts = <host>[,<host>]*.              |
|                                                                |
+----------------------------------------------------------------+
9 rows in set (0.00 sec)

Для любой команды MySQL Cluster Manager опция --help может быть сокращена до -? :

mcm> list processes -?;
+-------------------------------------------------------------+
| Help                                                        |
+-------------------------------------------------------------+
|                                                             |
| list processes <sitename>                             |
|                                                             |
| Lists all processes defined in the specified cluster.       |
+-------------------------------------------------------------+
4 rows in set (0.00 sec)

Как упомянуто в другом месте в этом руководстве (см. главу 4), у многих вариантов команды есть краткие формы также. Они включены в документацию для каждой команды. Можно также узнать о них для данной команды, вызывая команду с опцией --help или -? .

Можно получить версию выпуска программного обеспечения MySQL Cluster Manager командой version.

Команды клиента mysql в MySQL Cluster Manager. Можно также использовать стандартные команды mysql в MySQL Cluster Manager (но не запросы SQL, которые зависят от того, чтобы быть связанным с сервером MySQL), например, prompt, quit и status. Например, вывод команды статуса, когда связано с агентом MySQL Cluster Manager выглядит примерно так (в зависимости от точной версии клиента и агента, которую вы используете и возможно других факторов):

mcm> status
--------------
/home/jon/bin/mcm/libexec/../cluster/bin/mysql
Ver 14.14 Distrib 5.7.29-ndb-7.6.13, for linux2.6 (x86_64)
          using EditLine wrapper
Connection id:1
Current database: <n/a>
Current user: admin
SSL:Not in use
Current pager:less
Using outfile:''
Using delimiter:;
Server version: 1.4.8 MySQL Cluster Manager
Protocol version: 10
Connection: 127.0.0.1 via TCP/IP
Server characterset:<n/a>
Db characterset:<n/a>
Client characterset:<n/a>
Conn.characterset:<n/a>
TCP port: 1862
--------------

Можно использовать разделитель команды с командами mysql, но вы не обязаны делать так. Например, предполагая, что разделитель был точкой с запятой по умолчанию (;), мы, возможно, выполнили команду status:

mcm> status;
--------------
/home/jon/bin/mcm/cluster/bin/mysqlVer 14.14 Distrib 5.7.29-ndb-7.6.13,...

Особенно полезна команда mysql, чтобы можно было также использовать в mcm с командой source (краткая форма: \.), которую можно использовать для выполнения скриптов, содержащих команды MySQL Cluster Manager. В Linux у вас мог бы быть текстовый файл get-attributes.mcm в вашем домашнем каталоге:

get :ndb_mgmd mycluster\G
get :ndbd mycluster\G
get :mysqld mycluster\G

Предположение, что вы создали кластер mycluster, можно управлять этим скриптом в клиенте, результаты варьируются согласно тому, как этот кластер на самом деле формируется, но должны быть подобны этому:

mcm> \. ~/get-attributes.mcm
mcm> get :ndb_mgmd mycluster\G
*************************** 1. row ***************************
Name: DataDir
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/49/data
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 2. row ***************************
Name: HostName
 Value: flundra
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 3. row ***************************
Name: NodeId
 Value: 49
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 4. row ***************************
Name: PortNumber
 Value: 1186
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
 Level: Process
 Comment:
4 rows in set (0.09 sec)

mcm> get :ndbd mycluster\G
*************************** 1. row ***************************
Name: DataDir
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/1/data
Process1: ndbd
 NodeId1: 1
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 2. row ***************************
Name: HostName
 Value: tonfisk
Process1: ndbd
 NodeId1: 1
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 3. row ***************************
Name: NodeId
 Value: 1
Process1: ndbd
 NodeId1: 1
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 4. row ***************************
Name: DataDir
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/2/data
Process1: ndbd
 NodeId1: 2
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 5. row ***************************
Name: HostName
 Value: grindval
Process1: ndbd
 NodeId1: 2
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 6. row ***************************
Name: NodeId
 Value: 2
Process1: ndbd
 NodeId1: 2
Process2:
 NodeId2:
 Level:
 Comment: Read only
6 rows in set (0.10 sec)

mcm> get :mysqld mycluster\G
*************************** 1. row ***************************
Name: datadir
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/50/data
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 2. row ***************************
Name: HostName
 Value: haj
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 3. row ***************************
Name: log_error
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/50/data/mysqld_50_out.err
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 4. row ***************************
Name: ndb_nodeid
 Value: 50
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 5. row ***************************
Name: ndbcluster
 Value:
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 6. row ***************************
Name: NodeId
 Value: 50
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 7. row ***************************
Name: port
 Value: 3306
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 8. row ***************************
Name: socket
 Value: /tmp/mysql.mycluster.50.sock
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 9. row ***************************
Name: tmpdir
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/50/data/tmp
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 10. row ***************************
Name: datadir
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/51/data
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 11. row ***************************
Name: HostName
 Value: torsk
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 12. row ***************************
Name: log_error
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/51/data/mysqld_51_out.err
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 13. row ***************************
Name: ndb_nodeid
 Value: 51
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 14. row ***************************
Name: ndbcluster
 Value:
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 15. row ***************************
Name: NodeId
 Value: 51
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 16. row ***************************
Name: port
 Value: 3307
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 17. row ***************************
Name: socket
 Value: /tmp/mysql.mycluster.51.sock
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 18. row ***************************
Name: tmpdir
 Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/51/data/tmp
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
18 rows in set (0.05 sec)

mcm>

Вы не получите приглашение клиента до окончания работы скрипта.

Точно так же в Windows можно создать пакетный файл, используя Notepad или другой текстовый редактор, скопировать те же самые команды get и сохранить файл как get-attributes.bat в удобном местоположении, таком как рабочий стол Windows.

Можно смотреть список доступных команд mysql, используя команду help.

4.2. Команды агента MySQL Cluster Manager

В этой секции мы обсуждаем команды, используемые, чтобы работать с MySQL Cluster Manager. Кроме того, есть команды stop agents, show settings, version и show warnings, которые касаются агентов управления.

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

MySQL NDB Cluster делает чрезвычайно интенсивное использование сетевых соединений, и поиски DNS могут конфликтовать с MySQL NDB Cluster и MySQL Cluster Manager по пропускной способности, приводя к негативному воздействию на производительность MySQL NDB Cluster. Поэтому мы рекомендуем, чтобы вы использовали числовые IP-адреса, а не имена хоста для хостов MySQL NDB Cluster и MySQL Cluster Manager.

4.2.1. Команда add hosts

add hosts {--hosts=|-h }host_list
          site_name
          host_list:
          host[,
          host[, ...]]

Эта команда добавляет один или более хостов существующего места управления. Агенты, использующие тот же самый порт в качестве места управления, должны работать на любых хостах, добавленных с использованием этой команды. Эта команда берет два обязательных аргумента: список хостов (использующий опцию --hosts или ее краткую форму -h ) и название места, к которому должны быть добавлены хосты.

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

Например, следующая команда добавляет два хоста torsk и kolja к месту управления mysite:

mcm> add hosts --hosts=torsk,kolja mysite;
+--------------------------+
| Command result           |
+--------------------------+
| Hosts added successfully |
+--------------------------+
1 row in set (0.48 sec)

Ни один из хостов, добавленных этой командой, не может быть членом места управления site_name. Не пытайтесь добавить снова хост, который уже является членом места управления, используя его вторичный IP-адрес, процесс mcmd на хосте уже связан с IP-адресом, который поставлялся, когда хост был добавлен, это не может быть связано снова с другим IP-адресом.

4.2.2. Команда remove hosts

remove hosts {--hosts=|-h }host_list
             site_name
             host_list:
             host[,
             host[, ...]]

Эта команда удаляет один или более хостов из существующего места управления. Это принимает как аргумент необходимую опцию --hosts (краткая форма -h ), чье значение это список разделенных запятой значений одного или более хостов, которые будут удалены, и название места, из которого должны быть удалены хосты. Много ограничений применяются:

Следующая команда удаляет два хоста tonfisk и flundra с места управления mysite:

mcm> remove hosts --hosts=tonfisk,flundra mysite;
+----------------------------+
| Command result             |
+----------------------------+
| Hosts removed successfully |
+----------------------------+
1 row in set (0.48 sec)

4.2.3. Команда change log-level

change log-level [{--hosts=|-h }host_list]
       log_level
       site_name
       host_list:
       host[,
       host[,...]]

Установите уровень регистрации группы агента управления. Это имеет тот же самый эффект, как использование опции --log-level, однако, в отличие от опции, эта команда может использоваться во время выполнения и не требует перезапуска mcmd. Выполнение этой команды отвергает любое значение для --log-level в командной строке или в конфигурационном файле агента.

Когда log_level используется без host_list и site_name, эта команда применяется только к агенту, с которым связан mcm. В следующем примере уровень регистрации установлен в warning только на хосте, управляемом непосредственно агентом, с которым связан mcm:

mcm> change log-level warning;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Log-level changed successfully |
+--------------------------------+
1 row in set (0.00 sec)

Можно определить название места, которое будет затронуто командой. Например, следующая команда относится к месту, названному mysite:

mcm> change log-level debug mysite;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Log-level changed successfully |
+--------------------------------+
1 row in set (0.05 sec)

Можно также ограничить изменение одного или более хостов в данном месте, используя опцию --hosts option (краткая форма -h) с именами хостов, отделенными запятыми. Следующая команда изменяет уровень регистрации на debug на хостах tonfisk и haj, но не на любых других хостах в mysite:

mcm> change log-level --hosts=tonfisk,haj debug mysite;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Log-level changed successfully |
+--------------------------------+
1 row in set (0.09 sec)

Необходимо определить место, используя опцию --hosts, попытка использовать только --hosts приведет к ошибке.

Принятые значения для log_level совпадают со значениями для --log-level : debug, critical, error, info, message или warning. См. подробности здесь.

4.2.4. Команда rotate log

rotate log [{--hosts=|-h }host_list]
           [site_name]
           host_list:
           host[,
           host[,...]]

Ротирует журналы mcmd для связанного агента MySQL Cluster Manager для агентов на определенных хостах или для агентов на всех хостах в месте управления.

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

mcm> rotate log;
+--------------------------+
| Command result           |
+--------------------------+
| Log rotated successfully |
+--------------------------+
1 row in set (0.03 sec)

Новый файл журнала с подчеркиванием и меткой времени, вставленной в имя файла перед расширением, создается в результате:

-rw-r----- 1 mcmd cluster    74265 Jul 15 22:45 mcmd.log
-rw-r----- 1 mcmd cluster  1197573 Jul 15 22:45 mcmd_2017-07-15-22-45-28.log

MySQL Cluster Manager 1.4.4 и ранее: новое имя файла находится в формате old_filename .timestamp, это mcmd.log.2017-07-15T22-45-28 для примера выше.

Чтобы ротировать журналы для агентов на определенных хостах nanna12 и nanna13, используйте --hosts (краткая форма -h ):

mcm> rotate log --hosts=nanna12,nanna13 mysite;

Чтобы ротировать журналы всех агентов в месте управления mysite:

mcm> rotate log mysite;

4.2.5. Команда collect logs

collect logs [cluster_name]

Эта команда собирает файлы журнала и другие связанные файлы от всех хостов. Когда название (cluster_name ) поставляется командой, она собирает все файлы журнала (.log), а также конфигурационные файлы (.ini, .cnf), файлы ошибок (.err) и трассировки, используемые всеми процессами, принадлежащими кластеру, а также все файлы журнала агента.

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

MySQL Cluster Manager 1.4.2 и позже: Чтобы назначить определенный порт вручную для копирования файла, используйте опцию --copy-port, запуская mcmd. По умолчанию 0. Команда collect logs имеет тайм-аут: если через 30 секунд никакие связи не могут быть установлены ни одним из клиентов, или никакие поступающие связи не обнаружены сервером TCP.

Если брандмауэр или другие сетевые проблемы запрещают клиентам TCP соединяться с сокетом сервера TCP, collect logs никогда не будет заканчиваться.

Собранные файлы складируются в репозиторий данных MySQL Cluster Manager (../mcm_data (относительно инсталляционного каталога MySQL Cluster Manager) по умолчанию или определенный опцией --manager-directory) в подкаталог collected_files, где файлы организованы под иерархией меток времени [для коллекций файлов], а затем по именам хостов. Например, журнал агента для хоста tonfisk, собранный 2014-07-31 в 07:44:05, лежит в:

/opt/mcm_data/collected-files/2014-07-31T07:44:05Z/tonfisk/opt/mysql/logs/mcmd-tonfisk-19001.log

Если не задано cluster_name, только файлы журнала агента собраны.

4.2.6. Команда create site

create site {--hosts=|-h }host_list
            site_name
            host_list:
            host[,
            host[,...]]

Команда create site используется, чтобы создать место управления MySQL Cluster Manager, то есть, агентов управления MySQL Cluster Manager, работающих на одном или более компьютерах. Команда требует список из одного или более хостов, где работают агенты управления, и название места. Список хоста передается как значение опции --hosts (краткая форма: -h ).

Это пример команды create site, которая создает место mysite, состоящее из хостов tonfisk и flundra:

mcm> create site --hosts=tonfisk,flundra mysite;
+---------------------------+
| Command result            |
+---------------------------+
| Site created successfully |
+---------------------------+
1 row in set (0.31 sec)

Можно проверить, что место было создано, как предназначено, используя list sites :

mcm> list sites;
+--------+------+-------+-----------------+
| Site   | Port | Local | Hosts           |
+--------+------+-------+-----------------+
| mysite | 1862 | Local | tonfisk,flundra |
+--------+------+-------+-----------------+
1 row in set (0.06 sec)

См. раздел 4.2.8.

Агенты должны работать на всех хостах, определенных в --hosts при выполнении create site, иначе команда терпит неудачу с ошибкой Agent on host host: port is unavailable. Хост, где агент используется, чтобы дать команду, должен быть одним из перечисленных хостов. Иначе команда терпит неудачу с ошибкой Host host_name is not a member of site site_name .

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

Данный агент может быть членом одного места только, если один из агентов управления, определенных в host_list уже принадлежит месту, команда терпит неудачу с ошибкой Host host is already a member of site site .

4.2.7. Команда delete site

delete site site_name

Удаляет существующее место управления. Команда не останавливает или удаляет любых агентов, составляющих удаляемое место, вместо этого агенты продолжают работать и оставаться доступными для использования в других местах.

Команда берет отдельный аргумент, название места, которое будет удалено. Этот пример показывает удаление места управления named mysite:

mcm> delete site mysite;
+---------------------------+
| Command result            |
+---------------------------+
| Site deleted successfully |
+---------------------------+
1 row in set (0.38 sec)

Если место, которое будет удалено, не существует, команда терпит неудачу с ошибкой Command requires a site to be defined. Если есть какие-либо пакеты, ссылающиеся на хосты, принадлежащие месту, delete site терпит неудачу с ошибкой Packages exist in site site_name. Команда также терпит неудачу, если определяются какие-либо кластеры, которые включают хосты, принадлежащие месту.

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

Кроме того, если вы выполняете delete site с опцией --force, используя один агент управления в то время, как иной агент управления не работает, необходимо удалить файлы места недостающего агента управления вручную. Для получения дополнительной информации о файлах места посмотрите раздел 2.4.

4.2.8. Команда list sites

list sites

Эта команда возвращает список мест, известных агенту управления. Это не требует никаких аргументов. Пример:

mcm> list sites;
+--------+------+-------+-----------------+
| Site   | Port | Local | Hosts           |
+--------+------+-------+-----------------+
| mysite | 1862 | Local | tonfisk,flundra |
+--------+------+-------+-----------------+
1 row in set (0.06 sec)

Вывод list sites содержит следующие колонки:

4.2.9. Команда list hosts

list hosts [--verbose|-v]site_name

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

mcm> list hosts mysite;
+---------+-----------+---------+
| Host    | Status    | Version |
+---------+-----------+---------+
| tonfisk | Available | 1.4.8   |
+---------+-----------+---------+
| flundra | Available | 1.4.8   |
+---------+-----------+---------+
2 rows in set (0.16 sec)

Status может быть:

Если об агенте постоянно сообщают как Unresponsive или Unavailable, вам, вероятно, придется перезапустить его.

Если вы опускаете site_name, команда терпит неудачу с ошибкой:

mcm> list hosts;
ERROR 6 (00MGR): Illegal number of operands

Использование опции --verbose (краткая форма: -v) заставляет команду печатать дополнительную информацию о хостах:

mcm> list hosts --verbose mysite;
+---------+-----------+---------+-------+---------+-------------------------------+
| Host    | Status    | Version | Cores | Memory  | OS                            |
+---------+-----------+---------+-------+---------+-------------------------------+
| tonfisk | Available | 1.4.8   | 1     | 1819 Mb | Linux 3.13.11-100.fc19.x86_64 |
| flundra | Available | 1.4.8   | 1     | 1819 Mb | Linux 3.13.11-100.fc19.x86_64 |
+---------+-----------+---------+-------+---------+-------------------------------+
2 rows in set (0.07 sec)

4.2.10. Команда show settings

show settings [--hostinfo]

Эта команда перечисляет текущие значения многих опций mcmd :

mcm> show settings;
+-------------------+------------------------+
| Setting           | Value                  |
+-------------------+------------------------+
| log-file          | /opt/mcm_data/mcmd.log |
| log-level         | message                |
| log-use-syslog    | FALSE                  |
| manager-directory | /opt/mcm_data          |
| manager-username  | mcmd                   |
| manager-password  | ********               |
| manager-port      | 1862                   |
| xcom-port         | 18620                  |
+-------------------+------------------------+
8 rows in set (0.00 sec)

Применение опции --hostinfo заставляет команду распечатать информацию о хосте, с которым связан клиент mcm:

mcm> show settings --hostinfo;
+-----------------+-------------------------------+
| Property        | Value                         |
+-----------------+-------------------------------+
| Hostname        | localhost.localdomain         |
| Platform        | Linux 3.13.11-100.fc19.x86_64 |
| Processor cores | 1                             |
| Total memory    | 1819 Mb                       |
+-----------------+-------------------------------+
4 rows in set (0.00 sec)

4.2.11. Команда stop agents

stop agents[[--hosts=host_list]
           site_name]

Эта команда останавливает одного или больше агентов MySQL Cluster Manager на одном или более хостах.

Когда используется без любых аргументов, stop agents останавливает агента, с которым в настоящее время связывается клиент.

Когда используется с названием места управления, команда останавливает всех агентов, работающих на хостах, составляющих место. Эта команда остановит все агенты MySQL Cluster Manager на хостах в mysite:

mcm> stop agents mysite;

Можно также остановить подмножество агентов в данном месте управления, перечислив хосты, где они работают с помощью опции --hosts (краткая форма: -h ), наряду с названием места, которому они принадлежат. Результат следующей команды состоит в том, чтобы остановить агентов MySQL Cluster Manager на хостах kolja и torsk, оба из которых являются членами места управления mysite:

mcm> stop agents --hosts=kolja,torsk mysite;

Многократные имена хостов после опции --hosts должны быть отделены запятыми без пробелов. Вызов stop agents с этой опцией, не поставляя site_name вызывает синтаксическую ошибку. Использование неопределенного site_name или имен хостов, не принадлежащих месту, с этой командой также приводит к ошибке.

Когда IPv6-системы Windows используются в качестве хостов MySQL NDB Cluster под MySQL Cluster Manager, необходимо сослаться на эти хосты, используя адреса IPv4. Иначе MySQL Cluster Manager не будет способен соединиться с процессами агента на тех хостах. Посмотрите раздел 5.1.

4.2.12. Команда version

version

Эта команда показывает версию программного обеспечения MySQL Cluster Manager, используемого агентом MySQL Cluster Manager, с которым этот клиент связан, как показано здесь:

mcm> version;
+-------------------------------------+
| Version                             |
+-------------------------------------+
| MySQL Cluster Manager 1.4.8 (64bit) |
+-------------------------------------+
1 row in set (0.00 sec)

Команда version не берет аргументов.

4.2.13. Команда show warnings

Используя команду show warnings, можно проверить предупреждения (максимум последние пять), записанные в журнал агента (mcmd.log):

mcm> set delayed_insert_timeout:mysqld=400 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+

mcm> show warnings;
+---------+------+-----------------------------------------------------------------------+
| Level   | Code | Message                                                               |
+---------+------+-----------------------------------------------------------------------+
| Warning | -1   | Config variable delayed_insert_timeout was deprecated in mysqld 5.6.7 |
+---------+------+-----------------------------------------------------------------------+

4.3. Команды пакетов MySQL Cluster Manager

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

4.3.1. Команда add package

add package {--basedir=|-b }path
            [{--hosts=|-h }host_list]
            package_name
            host_list:
            host[,
            host[,...]]

Эта команда создает новый пакет или, если пакет package_name уже есть, эта команда расширяет определение пакета.

Опция --basedir (краткая форма: -b) указывает на местоположение инсталляционного каталога MySQL NDB Cluster на перечисленных хостах. Это должно быть путем к каталогу верхнего уровня, где расположено программное обеспечение MySQL NDB Cluster (например, /usr/local/mysql), и не должно включать каталоги MySQL NDB Cluster bin, libexec или другой подкаталог в рамках инсталляционного каталога.

Хосты могут быть определены как список разделенных запятой значений, используя опцию --hosts (краткая форма: -h ), однако, эта опция не требуется. Если --hosts пропущена, path как предполагается, действителен для всех хостов в кластере, который создается, используя этот пакет (см. раздел 4.4.1).

Предположим, что у нас есть два хоста Linux tonfisk и flundra и MySQL NDB Cluster в /usr/local/mysql на обеих машинах. В этом случае можно создать пакет mypackage как показано здесь:

mcm> add package --basedir=/usr/local/mysql mypackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.7 sec)

Когда этот пакет используется, чтобы создать кластер, MySQL Cluster Manager знает, что он должен найти программное обеспечение MySQL NDB Cluster в /usr/local/mysql на каждом из хостов.

Для опций MySQL Cluster Manager команды клиента, имеющие пути Windows как значение, необходимо использовать наклонные черты вправо (/) вместо наклонных черт влево (\), так если tonfisk и flundra хосты Windows, где MySQL NDB Cluster установлен в каталоге C:\mysql, команда была бы похожа на это:

mcm> add package --basedir=c:/mysql mypackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.71 sec)

В примере мы, возможно, также дали команду как add package --basedir=/usr/local/mysql --hosts=tonfisk,flundra mypackage (или add package --basedir=c:/mysql --hosts=tonfisk,flundra mypackage в Windows) с тем же самым результатом, но опция --hosts не требовалась, так как местоположение программного обеспечения MySQL NDB Cluster то же самое на каждом хосте. Давайте предположим, однако, что программное обеспечение устанавливается в /usr/local/ndb-host-10 на tonfisk и в /usr/local/ndb-host-20 на flundra. В этом случае мы должны дать 2 отдельных команды, определив хост, а также основной каталог в каждом случае, как показано здесь:

mcm> add package --basedir=/usr/local/ndb-host-10
   > --hosts=tonfisk yourpackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.68 sec)

mcm> add package --basedir=/usr/local/ndb-host-20
   > --hosts=flundra yourpackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.8 sec)

Предположив, что оба хоста принадлежат месту mysite, можно проверить, что эти пакеты были созданы, как надо, с использованием list packages:

mcm> list packages mysite;
+-------------+---------------------------------------+-----------------+
| Package     | Path                                  | Hosts           |
+-------------+---------------------------------------+-----------------+
| yourpackage | /usr/local/ndb-host-10                | tonfisk         |
|             | /usr/local/ndb-host-20                | flundra         |
| mypackage   | /usr/local/mysql                      | tonfisk,flundra |
+-------------+---------------------------------------+-----------------+
3 rows in set (1.07 sec)

См. раздел 4.3.3.

Возможно назначить тот же самый основной каталог (или каталоги) на том же самом хосте (или хостах) многим пакетам, как показано в этом примере, в котором мы предполагаем, что хосты tonfisk и flundra были ранее назначены на место mysite:

mcm> add package -b /usr/local/mysql-cluster mypackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (1.41 sec)

mcm> add package -b /usr/local/mysql-cluster yourpackage;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (1.58 sec)

mcm> list packages mysite;
+-------------+--------------------------+-----------------+
| Package     | Path                     | Hosts           |
+-------------+--------------------------+-----------------+
| mypackage   | /usr/local/mysql-cluster | tonfisk,flundra |
| yourpackage | /usr/local/mysql-cluster | tonfisk,flundra |
+-------------+--------------------------+-----------------+
2 rows in set (0.50 sec)

4.3.2. Команда delete package

delete package [{--hosts=|-h }host_list]
               package_name
               host_list:
               host[,
               host[,...]]

Эта команда используется, чтобы снять регистрацию пакета. Более определенно это удаляет любые ссылки на установки программного обеспечения MySQL NDB Cluster, добавленные к хранилищу агента, когда пакет был создан. delete package не удаляет установок MySQL NDB Cluster, команда удаляет только ссылки на установки. Как только пакет был разрегистрирован, он больше не может использоваться для create cluster. Двоичные модули MySQL NDB Cluster остаются, но могут использоваться в кластере MySQL NDB Cluster, которым управляют, используя MySQL Cluster Manager, только после того как основной каталог, содержащий их, был зарегистрирован в другом пакете. Возможно зарегистрировать основной каталог в многих пакетах, посмотрите раздел 4.3.1.

Если опция --hosts (краткая форма: -h ) используется, основные директивные параметры настройки для хоста или хостов заданные названной опцией, также удалены. Все хосты, данные в host_list, должны быть частью места, в котором зарегистрирован пакет. Иначе команда терпит неудачу.

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

Вот пример, который демонстрирует, как разрегистрировать пакет mypackage:

mcm> delete package mypackage;
+------------------------------+
| Command result               |
+------------------------------+
| Package deleted successfully |
+------------------------------+
1 row in set (1.23 sec)

Можно также проверить, что пакет был разрегистрирован, с помощью list packages , имя пакета больше не должно появляться в выводе этой команды. При попытке использовать незарегистрированный пакет в create cluster команда терпит неудачу, как показано здесь:

mcm> create cluster --package=mypackage
   > --processhosts=ndb_mgmd@tonfisk,ndbd@grindval,ndbd@flundra,mysqld@tonfisk mycluster;
ERROR 4001 (00MGR): Package mypackage not defined

upgrade cluster со ссылкой на незарегистрированный пакет также потерпит неудачу.

4.3.3. Команда list packages

list packages [package_name]
               site_name

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

mcm> list packages mysite;
+-------------+---------------------------------------+-----------------+
| Package     | Path                                  | Hosts           |
+-------------+---------------------------------------+-----------------+
| yourpackage | /usr/local/ndb-host-10                | tonfisk         |
|             | /usr/local/ndb-host-20                | flundra         |
| mypackage   | /usr/local/mysql                      | tonfisk,flundra |
+-------------+---------------------------------------+-----------------+
3 rows in set (1.07 sec)

Если tonfisk и flundra хосты Windows, список пакетов мог бы выглядеть примерно так:

mcm> list packages mysite;
+-------------+---------------------------------------+-----------------+
| Package     | Path                                  | Hosts           |
+-------------+---------------------------------------+-----------------+
| yourpackage | c:/cluster/ndb-host-10                | tonfisk         |
|             | c:/cluster/ndb-host-20                | flundra         |
| mypackage   | c:/mysql                              | tonfisk,flundra |
+-------------+---------------------------------------+-----------------+
3 rows in set (1.07 sec)

В примере yourpackage использует MySQL NDB Cluster в C:\cluster\ndb-host-10 на хосте tonfisk и C:\cluster\ndb-host-20 на flundra, mypackage использует MySQL NDB Cluster в C:\mysql на обеих машинах.

Вывод содержит три колонки, они описаны в следующем списке:

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

mcm> list packages yourpackage mysite;
+-------------+---------------------------------------+---------+
| Package     | Path                                  | Hosts   |
+-------------+---------------------------------------+---------+
| yourpackage | /usr/local/ndb-host-10                | tonfisk |
|             | /usr/local/ndb-host-20                | flundra |
+-------------+---------------------------------------+---------+
2 rows in set (0.55 sec)

Когда пакет содержит установки MySQL NDB Cluster, используя различные основные каталоги на различных хостах, каждую уникальную комбинацию пути и хоста показывают в собственной строке. Однако, название пакета показано только в первой строке, все строки, которые немедленно следуют за этой строкой и не содержат имя пакета, касаются того же самого пакета, имя которого показывают в первой предыдущей строке с именем пакета. Например, рассмотрите вывод list packages:

mcm> list packages mysite;
+-------------+------------------------+---------+
| Package     | Path                   | Hosts   |
+-------------+------------------------+---------+
| yourpackage | /usr/local/ndb-host-10 | tonfisk |
|             | /usr/local/ndb-host-20 | flundra |
| mypackage   | /usr/local/mysql       | tonfisk |
|             | /usr/local/bin/mysql   | flundra |
+-------------+------------------------+---------+
3 rows in set (1.07 sec)

Этот вывод показывает, что есть два пакета, определенные для места mysite: yourpackage и mypackage. Пакет yourpackage состоит из MySQL NDB Cluster в каталоге /usr/local/ndb-host-10 на хосте tonfisk и в каталоге /usr/local/ndb-host-20 на хосте flundra. Пакет mypackage состоит из MySQL NDB Cluster в каталоге /usr/local/mysql на хосте tonfisk и в каталоге /usr/local/bin/mysql на хосте flundra.

Если вы опускаете site_name, команда терпит неудачу с ошибкой, как показано здесь:

mcm> list packages;
ERROR 6 (00MGR): Illegal number of operands

4.4. Команды MySQL Cluster Manager Cluster

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

4.4.1. Команда create cluster

create cluster {--package=|-P}package_name
       {--processhosts=|-R }process_host_list
       cluster_name
       [(--import|-m) cluster_name]
       [--verbose | -v] process_host_list:
       process_name[:
       node_id]@host[,
       process_name@host[,...]]
       process_name:
       {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

Эта команда создает кластер, который будет управляться MySQL Cluster Manager. Однако, это не запускает кластер (см. раздел 4.4.7).

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

create cluster требует следующих аргументов:

Дополнительная опция --verbose для этой команды предписывает create cluster производить дополнительную информацию, когда это выполняется, как показано позже в этой секции.

Опция --import обозначает кластер, как создаваемый как цель для импортирования кластера, созданного вне MySQL Cluster Manager. Эта опция заставляет статус появляться как import в выводе show status:

mcm> show status --process newcluster;
+--------+----------+-------+--------+-----------+------------+
| NodeId | Process  | Host  | Status | Nodegroup | Package    |
+--------+----------+-------+--------+-----------+------------+
| 1      | ndb_mgmd | alpha | import |           | newpackage |
| 5      | ndbd     | beta  | import | n/a       | newpackage |
| 6      | ndbd     | gamma | import | n/a       | newpackage |
| 10     | mysqld   | delta | import |           | newpackage |
| 11     | ndbapi   | *     | import |           |            |
+--------+----------+-------+--------+-----------+------------+
6 rows in set (0.04 sec)

Наличие статуса import указывает, что любая из команд start cluster, restart cluster, start process и stop process потерпит неудачу, если они выполняются перед import cluster для этой группы. Также невозможно выполнить upgrade cluster на кластере, имеющем процессы со статусом import. Другие операции на этом кластере продолжают выполняться как обычно.

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

См. раздел 3.5.

Пример

Считайте следующую команду выполненной в клиенте MySQL Cluster Manager, который создает кластер mycluster:

mcm> create cluster --package=mypackage
  -> --processhosts=ndb_mgmd@flundra,ndbd@tonfisk,ndbd@grindval,mysqld@flundra
  -> mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster created successfully |
+------------------------------+
1 row in set (7.71 sec)

Как определено командой, mycluster состоит из четырех узлов: узел управления на хосте flundra, два узла данных, по одному на каждом из хостов tonfisk и grindval, и один узел SQL, также на хосте flundra.

Использование опции --verbose заставляет команду печатать вывод, подобный произведенному list processes:

mcm> create cluster --verbose --package=mypackage
  -> --processhosts=ndb_mgmd@flundra,ndbd@tonfisk,ndbd@grindval,mysqld@flundra
  -> mycluster;
+--------+----------+----------+
| NodeId | Name     | Host     |
+--------+----------+----------+
| 49     | ndb_mgmd | flundra  |
| 1      | ndbd     | tonfisk  |
| 2      | ndbd     | grindval |
| 50     | mysqld   | flundra  |
+--------+----------+----------+
4 rows in set (0.32 sec)

Можно также создать этот кластер таким способом, которым процессу mysqld разрешают соединиться с кластером от любого хоста, который в состоянии достигнуть других хостов кластера по сети как показано здесь:

mcm> create cluster --package=mypackage
  -> --processhosts=ndb_mgmd@flundra,ndbd@tonfisk,ndbd@grindval,mysqld@*
  -> mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster created successfully |
+------------------------------+
1 row in set (7.71 sec)

В случае свободного процесса ndbapi необязательно установить программное обеспечение MySQL Cluster Manager на хосте, где работает процесс ndbapi.

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

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

4.4.2. Команда delete cluster

delete cluster [--removedirs] cluster_name

Эта команда удаляет кластер cluster_name, удаляя его из списка кластеров, управляемых MySQL Cluster Manager.

delete cluster не удаляет модули MySQL NDB Cluster. Однако, это удаляет кластерную конфигурацию, данные и файлы журнала, которые хранятся в репозитории данных MySQL Cluster Manager.

Этот пример демонстрирует, как удалить кластер mycluster:

mcm> delete cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster deleted successfully |
+------------------------------+
1 row in set (1.22 sec)

Взгляд на репозиторий данных MySQL Cluster Manager (в данном случае /opt/mcm_data/) показывает, что каталог, который раньше хранил конфигурацию, данные и файлы журнала для for mycluster (/opt/mcm_data/clusters/mycluster), удален:

shell> ls -l /opt/mcm_data/clusters
total 0

Чтобы удалить конфигурационные файлы и файлы данных за пределами репозитория данных MySQL Cluster Manager, delete cluster должна быть вызвана с опцией --removedirs:

mcm> delete cluster --removedirs mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster deleted successfully |
+------------------------------+
1 row in set (1.22 sec)

Например, если один из узлов данных в mycluster имеет каталог данных за пределами репозитория данных MySQL Cluster Manager:

mcm> get Datadir mycluster;
+---------+---------------------------+----------+---------+----------+---------+---------+---------+
| Name    | Value                     | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment |
+---------+---------------------------+----------+---------+----------+---------+---------+---------+
| DataDir | /home/dso/mycluster/cdata | ndbd     | 1       |          |         | Process |         |
...

Удаление mycluster без использования --removedirs не удалит каталог данных для узла 1:

shell> ls -l /home/dso/mycluster
total 4
drwxr-xr-x . 3 dso dso 4096 Sep 10 18:00 cdata

Однако, если использована опция --removedirs, каталог данных для узла 1 также удален:

shell> ls -l /home/dso/mycluster
total 0

delete cluster терпит неудачу, если кластер, который будет удален, работает:

mcm> delete cluster mycluster;
ERROR 5010 (00MGR): All processes must be stopped to delete cluster mycluster

Необходимо сначала закрыть кластер, используя stop cluster.

4.4.3. Команда list clusters

list clusters site_name

Это перечисляет все кластеры, определенные для данного места управления site_name, вместе с пакетом, используемым каждым кластером. Например, команда, показанная здесь, показывает список всех кластеров, определенных для места mysite:

mcm> list clusters mysite;
+------------------+----------+
| Cluster          | Package  |
+------------------+----------+
| mycluster        | m-7.1.26 |
| yourcluster      | y-7.1.26 |
| someothercluster | s-7.2.9  |
+------------------+----------+
3 rows in set (2.07 sec)

Если site_name опущен, команда терпит неудачу с ошибкой, как показано здесь:

mcm> list clusters;
ERROR 6 (00MGR): Illegal number of operands

4.4.4. Команда list nextnodeids

list nextnodeids cluster_name

MySQL Cluster Manager обычно назначает ID на новые процессы узла автоматически (хотя это может быть отвергнуто командами create cluster или add process ). Команда list nextnodeids может использоваться, чтобы видеть следующий ID узла, который MySQL Cluster Manager зарезервировал для следующего нового процесса (каждого возможного типа процесса), чтобы добавить к кластеру cluster_name.

mcm> list nextnodeids mycluster;
+-----------+--------------+-------------+--------------------------+
| Category  | NodeId Range | Next NodeId | Processes                |
+-----------+--------------+-------------+--------------------------+
| Datanodes | 1- 48        | 5           | ndbd, ndbmtd             |
| Others    | 49 - 255     | 52          | ndb_mgmd, mysqld, ndbapi |
+-----------+--------------+-------------+--------------------------+
2 rows in set (0.07 sec)

4.4.5. Команда restart cluster

restart cluster [--sequential-restart]cluster_name

Эта команда выполняет перезапуск (см. Performing a Rolling Restart of an NDB Cluster) кластера cluster_name. Кластер должен уже работать Для получения информации о том, как определить операционное состояние кластера, посмотрите раздел 4.4.6.

Например, команда, показанная здесь, выполняет перезапуск кластера mycluster:

mcm> restart cluster mycluster;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Cluster restarted successfully |
+--------------------------------+
1 row in set (1 min 22.53 sec)

Если кластер уже не работает, restart cluster терпит неудачу с ошибкой, как показано здесь:

mcm> show status --cluster mycluster;
+-----------+---------+---------+
| Cluster   | Status  | Comment |
+-----------+---------+---------+
| mycluster | stopped |         |
+-----------+---------+---------+
1 row in set (1.49 sec)

mcm> restart cluster mycluster;
ERROR 5009 (00MGR): Restart can not be performed as processes are
stopped in cluster mycluster

MySQL Cluster Manager 1.4.8 и позже: По умолчанию перезапуск выполняется на узлах параллельным способом (то есть, половина узлов останавливается и перезапускается вместе, затем то же самое делается со второй половиной узлов). В некоторых ситуациях вы могли бы хотеть выполнить перезапуск последовательным способом, добавляя опцию --sequential-restart, в этом случае узлы будут остановлены и перезапущены один за другим.

MySQL Cluster Manager 1.4.7 и ранее: перезапуск выполняется на узлах параллельным способом (то есть, половина узлов останавливается и перезапускается вместе, затем то же самое делается со второй половиной).

В зависимости от количества узлов и объема данных, сохраненного в кластере, перезапуск может занять значительное количество времени до нескольких часов для кластера с очень многими узлами данных и большим объемом данных. Поэтому можно хотеть выполнить эту команду с опцией --background (краткая форма -B ), чтобы позволить ей работать в фоновом режиме, освобождая клиент MySQL Cluster Manager для других задач.

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

4.4.6. Команда show status

show status --cluster|-c cluster_name
show status --operation|-o cluster_name
show status --backup|-b cluster_name
show status --process|-r cluster_name
show status --progress cluster_name
show status --progressbar cluster_name

Эта команда используется, чтобы проверить статус процессов кластера, резервных копий и команд в клиенте MySQL Cluster Manager. Тип возвращенного статуса зависит от четырех опций --cluster (краткая форма: -c), --operation (краткая форма: -o), --backup (краткая форма: -b), or --process (краткая форма -r) команды. Если ни одна из них не используется, предполагается --cluster. Эти варианты описаны более подробно в следующих нескольких параграфах.

Опция --cluster

При использовании этой опции show status сообщает о статусе кластера cluster_name :

mcm> show status --cluster mycluster;
+-----------+-------------------+---------+
| Cluster   | Status            | Comment |
+-----------+-------------------+---------+
| mycluster | fully operational |         |
+-----------+-------------------+---------+
1 row in set (0.01 sec)

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

Таблица 4.1. Значения статуса из show status --cluster

Значение Status Смысл
fully operational Все процессы кластера работают.
operational Все узлы кластера в порядке, но по крайней мере один процесс узла данных (ndbd или ndbmtd) не работает. Кластер онлайн, но необходимо определить, почему любые недостающие узлы данных не работают и исправить проблему как можно скорее.
non-operational Кластер не готов к эксплуатации, потому что по крайней мере один узел кластера офлайн. Необходимо исследовать и решить проблему или проблемы, затем перезапустить кластер, прежде чем он сможет использоваться для поисковых операций и хранения данных.
stopped Кластер не работает, потому что он был остановлен пользователем. Это обычно не указывает ни на какую проблему как таковую, но необходимо перезапустить кластер, прежде чем это сможет использоваться любыми запросами.
created Кластер был создан успешно, используя create cluster, но никогда не был использован. Необходимо запустить кластер, используя start cluster прежде, чем можно будет использовать его.
unknown MySQL Cluster Manager не способен определить статус кластера. Это может и не указать на проблему с кластером, возможно, что проблема связана с одним или более агентами клиента MySQL Cluster Manager. Необходимо попытаться определить статус кластера другими средствами, такими как использование show status --process в клиенте MySQL Cluster Manager или использованием одной из команд, доступных в клиенте ndb_mgm (см. здесь), например, SHOW или ALL STATUS.

Опция --operation

Когда применена опция --operation (краткая форма: -o ), SHOW STATUS показывает статус последней команды, которая будет выполнена. Это включает команды, которые были даны, используя опцию --background (краткая форма -B ):

mcm> show status --operation mycluster;
+-----------------+-----------+--------------+
| Command         | Status    | Description  |
+-----------------+-----------+--------------+
| restart cluster | executing | <no message> |
+-----------------+-----------+--------------+
1 row in set (1.60 sec)

Вывод содержит 3 колонки:

Возможные значения столбца Status вместе с описаниями этих значений, показывают в следующей таблице:

Таблица 4.2. Значения статуса для show status --operation

Значение Status Описание
executing MySQL Cluster Manager выполняет команду, но еще не закончил выполнение.
finished Команда выполнилась успешно.
failed Команда не выполнилась. Столбец Description может содержать информацию о причине неудачи.
unknown MySQL Cluster Manager не способен определить статус этой команды.

Опция --backup

Когда эта опция используется, show status докладывает о статусе процесса резервного копирования для кластера cluster_name:

mcm> show status --backup mycluster;
+-----------------------------------------+
| Command result                          |
+-----------------------------------------+
| No backup currently active in mycluster |
+-----------------------------------------+
1 row in set (0.05 sec)
mcm> show status --backup mycluster;
+-----------------------------------------+
| Command result                          |
+-----------------------------------------+
| BackupId 5 currently active in mycluster|
+-----------------------------------------+
1 row in set (0.09 sec)

Опция --process

Когда выполняется с этой опцией, show status вернет информацию о каждом процессе в кластере cluster_name:

mcm> show status --process mycluster;
+----+----------+----------+---------+-----------+
| Id | Process  | Host     | Status  | Nodegroup |
+----+----------+----------+---------+-----------+
| 1  | ndb_mgmd | tonfisk  | running |           |
| 2  | ndbd     | flundra  | running | 0         |
| 3  | ndbd     | grindval | running | 0         |
| 4  | mysqld   | lax      | running |           |
+----+----------+----------+---------+-----------+
4 rows in set (1.67 sec)

При использовании опции --process (краткая форма: -r ) вывод show status содержит 5 колонок, описанных в следующем списке:

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

Таблица 4.3. Значения Status для show status --process

Значение Status Смысл
running Процесс работает нормально.
stopped Процесс был остановлен пользователем.
added Процесс был добавлен к кластеру, но еще не начат.
connected Процесс ndbapi или mysqld связан с кластером.
starting Процесс был начат, но еще не полностью работает. Для узлов данных можно определить, в которой фазе запуска узел в настоящее время находится при помощи команды status в клиенте ndb_mgm .
stopping Процесс получил команду, чтобы остановиться и теперь закрывается.
failed Процесс неожиданно закрылся (вероятно, сбой). Необходимо определить причину этого незапланированного закрытия, решить проблему и перезапустить процесс как можно скорее.
import Процесс это часть кластера, который был создан для импорта, но фактическая миграция процессов и данных из оригинального кластера еще не произошла. start process и stop process терпят неудачу для этого процесса, пока эта миграция не произошла.
unknown MySQL Cluster Manager не способен установить текущий статус этого процесса. Необходимо попытаться определить его статус, используя другие средства.

Опция --progress

MySQL Cluster Manager 1.4.2 и позже : При запуске с этой опцией show status вернет, когда доступно, прогресс текущего действия mcmd в кластере cluster_name, с точки зрения процента общего количества законченных шагов:

mcm> show status --progress mycluster;
+-----------------+-----------+----------+
| Command         | Status    | Progress |
+-----------------+-----------+----------+
| restore cluster | executing | 47%      |
+-----------------+-----------+----------+
1 row in set (0.02 sec)

Опция --progressbar

MySQL Cluster Manager 1.4.2 и позже : опция обеспечивает ту же самую функцию, как --progress, но также добавляет индикатор выполнения ASCII:

mcm> show status --progressbar mycluster;
+-----------------+-----------+-----------------------------+
| Command         | Status    | Progress                    |
+-----------------+-----------+-----------------------------+
| restore cluster | executing | 47% [#########]             |
+-----------------+-----------+-----------------------------+
1 row in set (0.02 sec)

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

mcm> show status;
ERROR 6 (00MGR): Illegal number of operands

mcm> show status -c nosuchcluster;
ERROR 5001 (00MGR): Cluster nosuchcluster not defined

Не путайте эту команду с командой MySQL SHOW STATUS, у которой иной синтаксис, и она может использоваться только в стандартном клиенте mysql. Команда клиента MySQL Cluster Manager принимает только опции, показавшие в начале этой секции, и не принимает выражения LIKE или WHERE.

4.4.7. Команда start cluster

start cluster [--initial|-i] [--skip-init=process_id_list]
      cluster_name
      process_id_list:
      process_id[,
      process_id[, ...]]

Эта команда запускает кластер cluster_name:

mcm> start cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster started successfully |
+------------------------------+
1 row in set (45.37 sec)

Чтобы команда сработала, должен уже существовать кластер, названный в команде, иначе команда терпит неудачу с ошибкой Cluster cluster_name not defined:

mcm> list sites;
+--------+------+-------+------------------------------+
| Site   | Port | Local | Hosts                        |
+--------+------+-------+------------------------------+
| mysite | 1862 | Local | tonfisk,flundra,grindval,haj |
+--------+------+-------+------------------------------+
1 row in set (1.72 sec)

mcm> list clusters mysite;
+-----------+-----------+
| Cluster   | Package   |
+-----------+-----------+
| mycluster | mypackage |
+-----------+-----------+
1 row in set (1.70 sec)

mcm> start cluster yourcluster;
ERROR 5001 (00MGR): Cluster yourcluster not defined

Кроме того, кластер еще не должен работать:

mcm> show status --cluster mycluster;
+-----------+-------------------+---------+
| Cluster   | Status            | Comment |
+-----------+-------------------+---------+
| mycluster | fully operational |         |
+-----------+-------------------+---------+
1 row in set (0.01 sec)

mcm> start cluster mycluster;
ERROR 5005 (00MGR): Cluster mycluster is running

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

Опция --initial

Опция --initial (краткая форма: -i ) вызывает следующее:

При нормальных обстоятельствах необходимо использовать эту опцию, чтобы запустить кластер только, когда вы не хотите сохранять любые данные (и хотеть сделать чистый запуск) или вы намереваетесь восстановить кластер из резервной копии до известного хорошего состояния (см. раздел 4.7.4). Необходимо также знать, что никакие специальные предупреждения не печатаются клиентом mcm, когда используется --initial с start cluster, команда немедленно выполняется.

Для получения информации о создании резервных копий кластера посмотрите раздел 4.7.2. Если необходимо знать, какие резервные копии доступны (если таковые имеются), надо использовать list backups.

4.4.8. Команда stop cluster

stop cluster cluster_name

Эта команда останавливает кластер cluster_name, если это работает:

mcm> stop cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster stopped successfully |
+------------------------------+
1 row in set (21.31 sec)

stop cluster терпит неудачу, если кластер не находится в рабочем состоянии (см. раздел 4.4.6):

mcm> show status --cluster mycluster;
+-----------+---------+---------+
| Cluster   | Status  | Comment |
+-----------+---------+---------+
| mycluster | stopped |         |
+-----------+---------+---------+
1 row in set (0.01 sec)

mcm> stop cluster mycluster;
ERROR 5006 (00MGR): Cluster mycluster is stopped

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

4.4.9. Команда autotune

autotune [--dryrun] [--sequential-restart]
         [--writeload=writeload]
         template
         cluster_name
         writeload: {low|medium|high}
         template: {web|realtime|test}

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

Допустимые значения template:

Допустимые значения для --writeload:

Кластер должен быть в статусе created или fully operational для работы этой команды. Команда настраивает кластер, создавая много команд set, чтобы приспособить различные параметры, затем выполняет перезапуск для кластера. Для MySQL Cluster Manager 1.4.8 и позже: используйте опцию --sequential-restart, чтобы сделать перезапуск последовательным.

Когда применена опция --dryrun, команда не вносит фактических изменений в кластер, но пишет команды set в файл / path-to-mcm-data-repository/clusters/ clustername /tmp/autotune.message_id .mcm.

mcm> autotune --dryrun --writeload=high realtime mycluster;
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Command result                                                                                                                                                     |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Autotuning calculation complete. Please check /opt/mcm_data/clusters/mycluster/tmp/autotune.30fcce24_2184_0.mcm on host flundra for settings that will be applied. |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.62 sec)
shell> cat /opt/mcm_data/clusters/mycluster/tmp/autotune.30fcce24_2184_0.mcm
# The following will be applied to the current cluster config:
set HeartbeatIntervalDbDb:ndbmtd=1500 mycluster;
set HeartbeatIntervalDbApi:ndbmtd=1500 mycluster;
set RedoBuffer:ndbmtd=64M mycluster;
set SharedGlobalMemory:ndbmtd=20M mycluster;
set DataMemory:ndbmtd=83886080 mycluster;
set IndexMemory:ndbmtd=18874368 mycluster;
set MaxNoOfExecutionThreads:ndbmtd=2 mycluster;
set FragmentLogFileSize:ndbmtd=256M mycluster;
set NoOfFragmentLogFiles:ndbmtd=3 mycluster;

После проверки изменений в файле .mcm, если вы не хотите применять их все к своему кластеру, можно отредактировать файл .mcm, а затем выполнить его в клиенте mcm (см. раздел 3.5.2.3 ). Если вы довольны всеми изменениями, описанными в файле, выполните команду autotune снова, но уже без опции --dryrun :

mcm> autotune --writeload=high realtime mycluster;
+-----------------------------------------------------+
| Command result                                      |
+-----------------------------------------------------+
| Cluster successfully autotuned to template realtime |
+-----------------------------------------------------+
1 row in set (2 min 58.09 sec)

Команда поддерживается только для MySQL NDB Cluster 7.4 и позже.

4.4.10. Команда upgrade cluster

upgrade cluster {--package=|-P }package_name
        [{--nodeid|-n }node_id_list]
        [--force|-f] [--retry|-L] [--set=attribute_assignment_list]
        cluster_name
        node_id_list:
        node_id[,
        node_id[, ...]]
        attribute_assignment_list:
        attribute_assignment[,
        attribute_assignment][,...]
        attribute_assignment:
        attribute_name:
        process_name[=
        value]

Эта команда модернизирует кластер cluster_name к пакету программного обеспечения package_name, определенному --package. Это заканчивает модернизацию, выполняя перезапуск для кластера, в котором узлы данных перезапущены с опцией --initial, чтобы пересоздать данные их файловых систем.

Новый пакет должен быть зарегистрирован, используя add package прежде, чем можно будет использовать его для модернизации, иначе upgrade cluster терпит неудачу с ошибкой.

Используя команду, чтобы выполнить модернизацию на кластере, если некоторые специальные варианты не используются (см. объяснения на опции --force, --retry и --nodeid), кластер должен быть в статусе fully operational (можно проверить это, используя команду show status --cluster cluster_name ). Кластер, созданный для импорта, не может быть модернизирован, пока импорт не был закончен. Посмотрите разделы 4.4.1 и раздел 3.5.

Предположим, что mycluster использует MySQL NDB Cluster 7.4.8, двоичные модули зарегистрированы в пакете 7.4.8, как показано этой командой list clusters:

mcm> list clusters mysite;
+-----------+---------+
| Cluster   | Package |
+-----------+---------+
| mycluster | 7.4.8   |
+-----------+---------+
1 row in set (1.80 sec)

Теперь вы хотите модернизировать mycluster до MySQL NDB Cluster. Предположим, что вы поместили NDB 7.6.13 в тот же самый каталог на каждом хосте, команда add package , чтобы создать новый пакет 7.6.13, который содержит эти модули, будет выглядеть примерно так:

mcm> add package --basedir=/usr/local/ndb-7.6.13 7.6.13;
+----------------------------+
| Command result             |
+----------------------------+
| Package added successfully |
+----------------------------+
1 row in set (0.88 sec)

В Windows необходимо заменить любую наклонную черту влево (\) в пути, используемом для опции --basedir, наклонными чертами вправо (/). См. раздел 4.3.1.

Оба пакета должны теперь быть перечислены в выводе команды list packages mysite. Чтобы выполнить модернизацию пакета 7.6.13, используйте команду upgrade cluster:

mcm> upgrade cluster --package=7.6.13 mycluster;
+-------------------------------+
| Command result                |
+-------------------------------+
| Cluster upgraded successfully |
+-------------------------------+
1 row in set (3 min 17.00 sec)

Когда команда upgrade cluster была успешно выполнена, можно проверить что mycluster теперь использует пакет 7.6.13 в выводе соответствующей команды list clusters:

mcm> list clusters mysite;
+-----------+---------+
| Cluster   | Package |
+-----------+---------+
| mycluster | 7.6.13  |
+-----------+---------+
1 row in set (1.80 sec)

Команда может выполнить основные, а также незначительные последовательные модернизации. Несмотря на название этой команды, upgrade cluster может также использоваться, чтобы выполнить даунгрейд MySQL NDB Cluster.

Не все модернизации между различными версиями MySQL NDB Cluster поддерживаются командой. Нужно соответствовать трем критериям:

Используя команду upgrade cluster, можно использовать опцию --set , чтобы повторно формировать ваш MySQL NDB Cluster в то же время. Это особенно полезно, когда модернизация требует изменений конфигурации вашего кластера. Этот опция берет в качестве аргумента список признаков в формате как для команд get и set. Например: если вы хотите изменить память, назначенную на каждый узел данных для хранения отчетов базы данных к 750M, определите это опцией --set в вашей команде upgrade cluster:

mcm> upgrade cluster --package=7.6.13 --set=DataMemory:ndbd=750M mycluster;
+-------------------------------+
| Command result                |
+-------------------------------+
| Cluster upgraded successfully |
+-------------------------------+
1 row in set (3 min 17.04 sec)

В отличие от пути, которым вы используете set, знак равенства (=) немедленно после опции --set нужен.

Возможности для контакта с неудавшимися модернизациями

Опция --force (краткая форма -f) должна использоваться, когда вы хотите выполнить upgrade cluster снова после неудавшейся попытки модернизации, которая заканчивается сбоем узла управления или данных. Без опции --force команда upgrade cluster работает только когда кластер будет в статусе fully operational.

Опция --retry (краткая форма -L) должна использоваться, когда вы хотите повторить команду upgrade cluster после неудачной попытки, которая заканчивается тем, что некоторые узлы модернизированы, а некоторые нет. Без опции --retry команда upgrade cluster не может быть выполнена на том же самом кластере дважды, используя тот же самый пакет.

В случае неудавшейся или неполной модернизации вместо того, чтобы использовать опцию --force и --retry, вы также можете повторить модернизацию только на неудавшихся узлах, определив их, используя опцию --nodeid (краткая форма -n). Проверьте на любые неудавшиеся узлы после неудавшейся модернизации:

mcm> upgrade cluster -P next mycluster;
ERROR 7006 (00MGR): Process error: <reason of failure>
mcm> show status --process mycluster;
+--------+----------+----------+---------+-----------+---------+
| NodeId | Process  | Host     | Status  | Nodegroup | Package |
+--------+----------+----------+---------+-----------+---------+
| 49     | ndb_mgmd | thinkpad | running |           | next    |
| 1      | ndbmtd   | thinkpad | running | 0         | next    |
| 2      | ndbmtd   | thinkpad | running | 0         | next    |
| 50     | mysqld   | thinkpad | running |           | next    |
| 51     | mysqld   | thinkpad | failed  |           | next    |
| 52     | ndbapi   | *        | added   |           |         |
+--------+----------+----------+---------+-----------+---------+
6 rows in set (0.03 sec)

Затем дайте команду снова, определив неудавшийся узел с опцией --nodeid:

mcm> upgrade cluster --nodeid=51 -P next mycluster;
+-------------------------------+
| Command result                |
+-------------------------------+
| Cluster upgraded successfully |
+-------------------------------+
1 row in set (26.03 sec)

Использование опции --nodeid неуместно с upgrade cluster, так как команда может привести к частичной модернизации. Используйте это только когда предыдущая попытка модернизировать кластер провалилась и только с руководством от надлежащего персонала поддержки.

4.5. Команды настройки MySQL Cluster Manager

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

Атрибуты конфигурации. Традиционно, управляя MySQL NDB Cluster, было необходимо различать 3 типа данных конфигурации:

MySQL Cluster Manager упрощает эту схему конфигурации, рассматривая все 3 типа данных конфигурации как атрибуты, где термин атрибуты относится к параметру конфигурации MySQL NDB Cluster, переменной MySQL Server или параметру командной строки, используемому с одной или более программами MySQL NDB Cluster. Это делает управление прозрачным, обращаясь со всеми необходимыми изменениями в объединенном интерфейсе.

Предположим, что вы хотите знать, сколько памяти данных ассигнуется узлам данных в данном MySQL NDB Cluster. Вместо того, чтобы управлять этим, используя параметр конфигурации DataMemory, который написан в файл config.ini и затем читая тот файл, чтобы найти значение, вы просто вызоваете в MySQL Cluster Manager команду get и MySQL Cluster Manager читает файл для вас и показывает значение без необходимости открытия файла в отдельном приложении. Если вы хотите изменить память объема данных, ассигнованную узлам данных, можно в MySQL Cluster Manager использовать команду set (или reset), MySQL Cluster Manager тогда пишет требуемое значение в config.ini. Если, как имеет место с DataMemory, обновление значения конфигурации в MySQL NDB Cluster требует, чтобы перезапуск был выполнен, MySQL Cluster Manager может выполнить эту операцию автоматически так, чтобы изменение конфигурации вступило в силу без дальнейшего вмешательства со стороны оператора.

Уровни признака конфигурации. Значение атрибута конфигурации применяется на одном из этих трех уровней, описанных здесь:

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

Устанавливая или перезагружая значение атрибута конфигурации, необходимо определить уровень, на котором оно применяется.

MySQL Cluster Manager определяет, какое значение использовать для признака конфигурации, касающегося данного процесса, выполняя эти шаги для каждого процесса MySQL NDB Cluster:

Для каждого признака конфигурации:

  1. Значение атрибута определяется для ID узла этого процесса?

    Да: Используйте значение, которое было определено для ID этого узла.

    Нет: Продолжите двигаться к следующему шагу.

  2. Значение атрибута определяется на уровне процесса то есть, для всех процессов этого типа?

    Да: Используйте значение, которое было определено для всех процессов этого типа.

    Нет: Используйте значение по умолчанию, которое относится к процессам этого типа.

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

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

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

mcm> reset NodeId:ndb_mgmd:1 mycluster;
ERROR 6007 (00MGR): Config attribute NodeId is mandatory and cannot be reset
mcm> reset NodeId:ndbd:2 mycluster;
ERROR 6007 (00MGR): Config attribute NodeId is mandatory and cannot be reset
mcm> reset NodeId:mysqld:4 mycluster;
ERROR 6007 (00MGR): Config attribute NodeId is mandatory and cannot be reset

Атрибуты "только для чтения". Атрибут "только для чтения" это признак, который должен быть определен MySQL Cluster Manager, когда кластер создается. Атрибут "только для чтения" не может быть ни изменен, ни перезагружен пользователем. Это означает, что атрибут "только для чтения" всегда обязательный признак.

Один такой признак HostName, который только читается для любого типа процесса MySQL NDB Cluster. Любая попытка изменить или перезагрузить атрибут "только для чтения" терпит неудачу, как показано здесь:

mcm> reset HostName:ndb_mgmd mycluster;
ERROR 6008 (00MGR): Config attribute HostName is readonly and cannot be changed
mcm> reset HostName:ndbd mycluster;
ERROR 6008 (00MGR): Config attribute HostName is readonly and cannot be changed
mcm> reset HostName:mysqld mycluster;
ERROR 6008 (00MGR): Config attribute HostName is readonly and cannot be changed
mcm> set HostName:ndb_mgmd mycluster;
ERROR 6008 (00MGR): Config attribute HostName is readonly and cannot be changed
mcm> set HostName:ndbd mycluster;
ERROR 6008 (00MGR): Config attribute HostName is readonly and cannot be changed
mcm> set HostName:mysqld mycluster;
ERROR 6008 (00MGR): Config attribute HostName is readonly and cannot be changed

Признак, который обязателен или только для чтения, установлен, когда кластер создается. Ни обязательный признак, ни атрибут "только для чтения" не могут быть перезагружены. Ни у какого типа признака нет значения по умолчанию кроме того, что установлено для него, когда кластер создается. Обязательный признак может быть изменен в любое время пользователем, атрибут "только для чтения" не может быть изменен, как только кластер был создан. Можно получить список обязательных и атрибутов "только для чтения", используя команду get.

Список свойств признака также может быть найден в выводе ndb_config --configinfo --xml (см. здесь).

MySQL Cluster Manager определяет внутренне, какие атрибуты только для чтения по причинам стабильности кластера. Можно использовать команду get, чтобы видеть, какие атрибуты только для чтения.

Атрибуты командной строки. Атрибуты командной строки это, которые при работе за пределами MySQL Cluster Manager должны быть определены как параметры командной строки вместо параметров в конфигурационном файле (например, config.ini или my.cnf). Они включают все параметры командной строки узлов ndb_mgmd, ndbd и ndbmtd, а также опции mysqld, перечисленные здесь как недействительные в файлах опций. Небольшое количество этих параметров может, однако, формироваться с MySQL Cluster Manager, используя команды set и reset, их значения могут быть проверены командой get:

Эти атрибуты, поддержанные командами get, set и reset, отмечены как Command Line в столбце Comment вывода команды get:

mcm> set core-file:ndb_mgmd mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (32.43 sec)

mcm> get -d core-file:ndb_mgmd mycluster;
+-----------+-------+----------+---------+----------+---------+---------+--------------+
| Name      | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment      |
+-----------+-------+----------+---------+----------+---------+---------+--------------+
| core-file |       | ndb_mgmd | 49      |          |         | Process | Command Line |
+-----------+-------+----------+---------+----------+---------+---------+--------------+
1 row in set (0.07 sec)

mcm> reset core-file:ndb_mgmd mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (9.57 sec)

mcm> get -d core-file:ndb_mgmd mycluster;
+-----------+-------+----------+---------+----------+---------+---------+--------------+
| Name      | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment      |
+-----------+-------+----------+---------+----------+---------+---------+--------------+
| core-file | false | ndb_mgmd | 49      |          |         | Default | Command Line |
+-----------+-------+----------+---------+----------+---------+---------+--------------+
1 row in set (0.05 sec)

4.5.1. Команда get

get [--include-defaults|-d] [filter_specification_list]
    cluster_name
    filter_specification_list:
    filter_specification[,
    filter_specification][,...]
    filter_specification:
    [attribute_name]
    [:process_specification]
    [+process_specification]]
    process_specification:
    [process_name]
    [:process_id]
    process_name:
    {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

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

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

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

mcm> get mycluster\G
*************************** 1. row ***************************
Name: Name
 Value: mycluster
Process1:
 NodeId1:
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 2. row ***************************
Name: DataDir
 Value: /opt/mcm_data/clusters/mycluster/49/data
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 3. row ***************************
Name: HostName
 Value: torsk
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 4. row ***************************
Name: NodeId
 Value: 49
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 5. row ***************************
Name: PortNumber
 Value: 1186
Process1: ndb_mgmd
 NodeId1: 49
Process2:
 NodeId2:
 Level: Process
 Comment:
*************************** 6. row ***************************
Name: DataDir
 Value: /opt/mcm_data/clusters/mycluster/1/data
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 7. row ***************************
Name: HostName
 Value: torsk
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 8. row ***************************
Name: NodeId
 Value: 1
Process1: ndbmtd
 NodeId1: 1
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 9. row ***************************
Name: DataDir
 Value: /opt/mcm_data/clusters/mycluster/2/data
Process1: ndbmtd
 NodeId1: 2
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 10. row ***************************
Name: HostName
 Value: torsk
Process1: ndbmtd
 NodeId1: 2
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 11. row ***************************
Name: NodeId
 Value: 2
Process1: ndbmtd
 NodeId1: 2
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 12. row ***************************
Name: datadir
 Value: /opt/mcm_data/clusters/mycluster/50/data
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 13. row ***************************
Name: default_storage_engine
 Value: ndbcluster
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level: Process
 Comment:
*************************** 14. row ***************************
Name: HostName
 Value: torsk
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 15. row ***************************
Name: ndb_nodeid
 Value: 50
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 16. row ***************************
Name: ndbcluster
 Value: on
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 17. row ***************************
Name: NodeId
 Value: 50
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 18. row ***************************
Name: port
 Value: 3306
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 19. row ***************************
Name: socket
 Value: /tmp/mysql.mycluster.50.sock
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 20. row ***************************
Name: tmpdir
 Value: /opt/mcm_data/clusters/mycluster/50/tmp
Process1: mysqld
 NodeId1: 50
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 21. row ***************************
Name: datadir
 Value: /opt/mcm_data/clusters/mycluster/51/data
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 22. row ***************************
Name: default_storage_engine
 Value: ndbcluster
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level: Process
 Comment:
*************************** 23. row ***************************
Name: HostName
 Value: torsk
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 24. row ***************************
Name: ndb_nodeid
 Value: 51
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 25. row ***************************
Name: ndbcluster
 Value: on
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 26. row ***************************
Name: NodeId
 Value: 51
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 27. row ***************************
Name: port
 Value: 3307
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 28. row ***************************
Name: socket
 Value: /tmp/mysql.mycluster.51.sock
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 29. row ***************************
Name: tmpdir
 Value: /opt/mcm_data/clusters/mycluster/51/tmp
Process1: mysqld
 NodeId1: 51
Process2:
 NodeId2:
 Level:
 Comment:
*************************** 30. row ***************************
Name: NodeId
 Value: 52
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
 Level:
 Comment: Read only
30 rows in set (0.07 sec)

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

Хотя признак socket для узлов mysqld показывают в выводе get из предыдущего примера, и он не отмечен как Read only, MySQL Cluster Manager не поддерживает файлы сокета в Windows. Поэтому вы не должны пытаться установить атрибуты socket для процессов Windows mysqld через MySQL Cluster Manager.

Чтобы включать значения по умолчанию для признаков, у которых нет значения, заданного явно, можно вызвать эту команду с опцией --include-defaults option (краткая форма: -d):

mcm> get --include-defaults mycluster\G
*************************** 1. row ***************************
Name: Name
 Value: mycluster
Process1:
 NodeId1:
Process2:
 NodeId2:
 Level:
 Comment: Read only
*************************** 2. row ***************************
Name: Checksum
 Value: false
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 3. row ***************************
Name: Group
 Value: 55
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 4. row ***************************
Name: HostName1
 Value: NULL
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 5. row ***************************
Name: HostName2
 Value: NULL
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 6. row ***************************
Name: NodeId1
 Value: NULL
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment: Mandatory
*************************** 7. row ***************************
Name: NodeId2
 Value: NULL
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment: Mandatory
*************************** 8. row ***************************
Name: NodeIdServer
 Value: NULL
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment: Mandatory
*************************** 9. row ***************************
Name: OverloadLimit
 Value: 0
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 10. row ***************************
Name: Proxy
 Value: NULL
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 11. row ***************************
Name: ReceiveBufferMemory
 Value: 2097152
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 12. row ***************************
Name: SendBufferMemory
 Value: 2097152
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 13. row ***************************
Name: SendSignalId
 Value: true
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:
*************************** 14. row ***************************
Name: TCP_MAXSEG_SIZE
 Value: 0
Process1: ndb_mgmd
 NodeId1: 49
Process2: ndbmtd
 NodeId2: 1
 Level: Default
 Comment:

...

*************************** 1901. row ***************************
Name: StartConnectBackoffMaxTime
 Value: 0
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
 Level: Default
 Comment:
*************************** 1902. row ***************************
Name: TotalSendBufferMemory
 Value: 0
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
 Level: Default
 Comment:
*************************** 1903. row ***************************
Name: wan
 Value: false
Process1: ndbapi
 NodeId1: 52
Process2:
 NodeId2:
 Level: Default
 Comment:
1903 rows in set (0.11 sec)

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

[attribute_name]
[:[process_name]
[:process_id]]

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

Чтобы получить значение данного признака для всех процессов, к которым это применяется в кластере, вы должны только использовать название признака как фильтр. Например, чтобы получить HostName всех процессов в кластере mycluster,

mcm> get HostName mycluster;
+----------+----------+----------+---------+----------+---------+-------+-----------+
| Name     | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment   |
+----------+----------+----------+---------+----------+---------+-------+-----------+
| HostName | flundra  | ndbd     | 1       |          |         |       | Read only |
| HostName | tonfisk  | ndbd     | 2       |          |         |       | Read only |
| HostName | grindval | ndb_mgmd | 49      |          |         |       | Read only |
| HostName | haj      | mysqld   | 50      |          |         |       | Read only |
| HostName | torsk    | mysqld   | 51      |          |         |       | Read only |
+----------+----------+----------+---------+----------+---------+-------+-----------+
5 rows in set (0.04 sec)

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

mcm> get Host* mycluster;
+----------+----------+----------+---------+----------+---------+-------+-----------+
| Name     | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment   |
+----------+----------+----------+---------+----------+---------+-------+-----------+
| HostName | flundra  | ndbd     | 1       |          |         |       | Read only |
| HostName | tonfisk  | ndbd     | 2       |          |         |       | Read only |
| HostName | grindval | ndb_mgmd | 49      |          |         |       | Read only |
| HostName | haj      | mysqld   | 50      |          |         |       | Read only |
| HostName | torsk    | mysqld   | 51      |          |         |       | Read only |
+----------+----------+----------+---------+----------+---------+-------+-----------+
5 rows in set (0.04 sec)

mcm> get H* yourcluster;
+------------------------+---------+----------+---------+----------+---------+---------+-----------+
| Name                   | Value   | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment   |
+------------------------+---------+----------+---------+----------+---------+---------+-----------+
| HostName               | tonfisk | ndb_mgmd | 49      |          |         |         | Read only |
| HostName               | flundra | ndb_mgmd | 53      |          |         |         | Read only |
| HeartbeatIntervalDbApi | 1500    | ndbmtd   | 1       |          |         | Process |           |
| HeartbeatIntervalDbDb  | 1500    | ndbmtd   | 1       |          |         | Process |           |
| HostName               | tonfisk | ndbmtd   | 1       |          |         |         | Read only |
| HeartbeatIntervalDbApi | 1500    | ndbmtd   | 2       |          |         | Process |           |
| HeartbeatIntervalDbDb  | 1500    | ndbmtd   | 2       |          |         | Process |           |
| HostName               | flundra | ndbmtd   | 2       |          |         |         | Read only |
| HostName               | tonfisk | mysqld   | 50      |          |         |         | Read only |
| HostName               | flundra | mysqld   | 51      |          |         |         | Read only |
+------------------------+---------+----------+---------+----------+---------+---------+-----------+
10 rows in set (0.09 sec)

Чтобы получить значение данного признака для всех процессов данного типа, можно определить фильтр формы attribute_name: process_name. Следующая команда получает HostName всех процессов (только) ndbd в кластере mycluster:

mcm> get HostName:ndbd mycluster;
+----------+---------+----------+-----+----------+-----+-------+----------+
| Name     | Value   | Process1 | Id1 | Process2 | Id2 | Level | Comment  |
+----------+---------+----------+-----+----------+-----+-------+----------+
| HostName | flundra | ndbd     | 1   |          |     |       | Readonly |
| HostName | tonfisk | ndbd     | 2   |          |     |       | Readonly |
+----------+---------+----------+-----+----------+-----+-------+----------+
2 rows in set (0.12 sec)

Чтобы получить значение данного признака для конкретного экземпляра процесса, можно использовать фильтр, который принимает форму attribute_name: process_name: process_id. Например, можно использовать следующую команду, чтобы получить имя хоста для процесса с ID = 2:

mcm> get HostName:ndbd:2 mycluster;
+----------+---------+----------+-----+----------+-----+-------+----------+
| Name     | Value   | Process1 | Id1 | Process2 | Id2 | Level | Comment  |
+----------+---------+----------+-----+----------+-----+-------+----------+
| HostName | tonfisk | ndbd     | 2   |          |     |       | Readonly |
+----------+---------+----------+-----+----------+-----+-------+----------+
1 row in set (1.67 sec)

Команда работает так же, если тип процесса опущен:

mcm> get HostName::2 mycluster;
+----------+---------+----------+-----+----------+-----+-------+----------+
| Name     | Value   | Process1 | Id1 | Process2 | Id2 | Level | Comment  |
+----------+---------+----------+-----+----------+-----+-------+----------+
| HostName | tonfisk | ndbd     | 2   |          |     |       | Readonly |
+----------+---------+----------+-----+----------+-----+-------+----------+
1 row in set (1.67 sec)

Можно получить информацию о многих атрибутах одной командой get, определяя список фильтров, отделенных запятыми. Каждый в списке должен быть полным, действительным фильтром. Команда, показанная здесь, получает HostName и DataDir для всех процессов в mycluster:

mcm> get HostName,DataDir mycluster;
+----------+--------------+----------+---------+----------+---------+-------+-----------+
| Name     | Value        | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment   |
+----------+--------------+----------+---------+----------+---------+-------+-----------+
| DataDir  | /opt/c1data  | ndbd     | 1       |          |         |       |           |
| HostName | flundra      | ndbd     | 1       |          |         |       | Read only |
| DataDir  | /opt/c2data  | ndbd     | 2       |          |         |       |           |
| HostName | tonfisk      | ndbd     | 2       |          |         |       | Read only |
| DataDir  | /opt/c49data | ndb_mgmd | 49      |          |         |       |           |
| HostName | grindval     | ndb_mgmd | 49      |          |         |       | Read only |
| datadir  | /opt/c50data | mysqld   | 50      |          |         |       |           |
| HostName | haj          | mysqld   | 50      |          |         |       | Read only |
| datadir  | /opt/c51data | mysqld   | 51      |          |         |       |           |
| HostName | torsk        | mysqld   | 51      |          |         |       | Read only |
+----------+--------------+----------+---------+----------+---------+-------+-----------+
10 rows in set (0.05 sec)

Чтобы получить значения HostName и DataDir для всех узлов в mycluster, можно использовать такую команду get:

mcm> get HostName:ndbd,DataDir:ndbd mycluster;
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| Name     | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| DataDir  | /opt/c2data | ndbd     | 1   |          |     |       |           |
| HostName | tonfisk     | ndbd     | 1   |          |     |       | Read only |
| DataDir  | /opt/c3data | ndbd     | 2   |          |     |       |           |
| HostName | flundra     | ndbd     | 2   |          |     |       | Read only |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
4 rows in set (1.36 sec)

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

mcm> get HostName,DataDir:ndbd mycluster;
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| Name     | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| HostName | grindval    | ndb_mgmd | 49  |          |     |       | Read only |
| DataDir  | /opt/c2data | ndbd     | 1   |          |     |       |           |
| HostName | tonfisk     | ndbd     | 1   |          |     |       | Read only |
| DataDir  | /opt/c3data | ndbd     | 2   |          |     |       |           |
| HostName | flundra     | ndbd     | 2   |          |     |       | Read only |
| HostName | haj         | mysqld   | 50  |          |     |       | Read only |
| HostName | torsk       | mysqld   | 51  |          |     |       | Read only |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
6 rows in set (0.58 sec)

Список фильтров HostName,DataDir:ndbd совершенно нормален. Однако, это на самом деле состоит из фильтров HostName и DataDir:ndbd. Другими словами, это означает HostName для всех процессов и DataDir для процессов ndbd .

Предположим, что вы хотите получить значения для HostName для процессов ndb_mgmd и mysqld в mycluster. Вы могли бы попытаться использовать что-то вроде HostName:ndb_mgmd,mysqld для списка фильтров, но это не работает, как вы видите здесь:

mcm> get HostName:ndb_mgmd,mysqld mycluster;
ERROR 6003 (00MGR): No such config variable mysqld for process

Это получается вследствие того, что каждый фильтр в списке должен быть действительным фильтром и должен включать название атрибута. В списке фильтра, показанном здесь, MySQL Cluster Manager пытается интерпретировать первую последовательность после запятой как название атрибута. Правильный список фильтров, чтобы использовать в команде get для получения HostName для процессов ndb_mgmd и mysqld в mycluster:

mcm> get HostName:ndb_mgmd,HostName:mysqld mycluster;
+----------+----------+----------+-----+----------+-----+-------+-----------+
| Name     | Value    | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+----------+----------+----------+-----+----------+-----+-------+-----------+
| HostName | grindval | ndb_mgmd | 49  |          |     |       | Read only |
| HostName | haj      | mysqld   | 50  |          |     |       | Read only |
| HostName | torsk    | mysqld   | 51  |          |     |       | Read only |
+----------+----------+----------+-----+----------+-----+-------+-----------+
2 rows in set (0.21 sec)

Также возможно получить список признаков и их значений для данного типа процесса или экземпляра процесса. Для данного типа процесса используйте фильтр, имеющий форму :process_name . Например, чтобы получить все атрибуты не по умолчанию, относящиеся к процессам ndbd в кластере mycluster, можно использовать фильтр :ndbd:

mcm> get :ndbd mycluster;
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| Name     | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| DataDir  | /opt/c2data | ndbd     | 1   |          |     |       |           |
| HostName | tonfisk     | ndbd     | 1   |          |     |       | Read only |
| NodeId   | 1           | ndbd     | 1   |          |     |       | Read only |
| DataDir  | /opt/c3data | ndbd     | 2   |          |     |       |           |
| HostName | flundra     | ndbd     | 2   |          |     |       | Read only |
| NodeId   | 2           | ndbd     | 2   |          |     |       | Read only |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
6 rows in set (0.77 sec)

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

Чтобы получить список всех признаков не по умолчанию для единственного экземпляра процесса, используйте фильтр, имеющий форму :process_name :process_id, как показано в этом примере, который получает все атрибуты не по умолчанию для процесса ndbd, где ID процесса 2:

mcm> get :ndbd:2 mycluster;
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| Name     | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| DataDir  | /opt/c2data | ndbd     | 2   |          |     |       |           |
| HostName | flundra     | ndbd     | 2   |          |     |       | Read only |
| NodeId   | 2           | ndbd     | 2   |          |     |       | Read only |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
4 rows in set (0.32 sec)

Если при попытке получить значения для признака, который поддерживается вашей версией MySQL NDB Cluster, вы получили пустой результат, это почти наверняка означает, что это атрибут по умолчанию, который не был изменен после того, как кластер был создан или перезагружен. Чтобы смотреть атрибуты по умолчанию, используйте get, необходимо выполнить команду, используя опцию --include-defaults (краткая форма: -d).

Предположим, что вы хотите видеть, сколько DataMemory формируется для процессов ndbd в кластере mycluster и вы выполняете то, что кажется правильной командой get, но пустой результат возвращен, как показано здесь:

mcm> get DataMemory:ndbd mycluster;
Empty set (1.19 sec)

Это означает, что атрибут DataMemory имеет свое значение по умолчанию для всех узлов данных в кластере. Если вы не помните, каково это значение, можно определить его легко, повторив ту же самую команду с добавлением опции --include-defaults ( -d):

mcm> get --include-defaults DataMemory:ndbd mycluster;
+------------+----------+----------+-----+----------+-----+---------+---------+
| Name       | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+----------+----------+-----+----------+-----+---------+---------+
| DataMemory | 83886080 | ndbd     | 1   |          |     | Default |         |
| DataMemory | 83886080 | ndbd     | 2   |          |     | Default |         |
+------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (0.62 sec)

Теперь предположите, что вы увеличиваете DataMemory до 500 мегабайт на узел данных, затем повторите get, чтобы проверить новое значение:

mcm> set DataMemory:ndbd=500M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.77 sec)

mcm> get --include-defaults DataMemory:ndbd mycluster;
+------------+-------+----------+-----+----------+-----+---------+---------+
| Name       | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+-------+----------+-----+----------+-----+---------+---------+
| DataMemory | 500M  | ndbd     | 1   |          |     | Process |         |
| DataMemory | 500M  | ndbd     | 2   |          |     | Process |         |
+------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.46 sec)

Вы видите, что есть не только колонка Value в выводе get показывает обновленное значение, но и Level также обновлена от Default до Process. Это означает, что вам больше не нужно указывать опцию --include-defaults, чтобы смотреть этот признак, как показано здесь:

mcm> get DataMemory:ndbd mycluster;
+------------+-------+----------+-----+----------+-----+---------+---------+
| Name       | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+-------+----------+-----+----------+-----+---------+---------+
| DataMemory | 500M  | ndbd     | 1   |          |     | Process |         |
| DataMemory | 500M  | ndbd     | 2   |          |     | Process |         |
+------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (0.63 sec)

Однако, если вы перезагружаете DataMemory (также на уровне процесса), это больше не имеет место. Затем DataMemory еще раз принимает значение по умолчанию, после чего необходимо использовать опцию --include-defaults, как показано в этом примере:

mcm> reset DataMemory:ndbd mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.65 sec)

mcm> get DataMemory:ndbd mycluster;
Empty set (1.76 sec)

mcm> get --include-defaults DataMemory:ndbd mycluster;
+------------+----------+----------+-----+----------+-----+---------+---------+
| Name       | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+----------+----------+-----+----------+-----+---------+---------+
| DataMemory | 83886080 | ndbd     | 1   |          |     | Default |         |
| DataMemory | 83886080 | ndbd     | 2   |          |     | Default |         |
+------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.01 sec)

Команда get также помечает многократные атрибуты репликации в поле Comment:

mcm> get replicate_ignore_table:mysqld mycluster;
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
| Name                   | Value        | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment     |
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
| replicate_ignore_table | mydb.t1      | mysqld   | 50      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.t50     | mysqld   | 50      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.mytable | mysqld   | 50      |          |         | Process | Multi-entry |
| replicate_ignore_table | mydb.t51     | mysqld   | 51      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.mytable | mysqld   | 51      |          |         | Process | Multi-entry |
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
5 rows in set (0.05 sec)

О том, как перезагрузить многократные атрибуты посмотрите раздел 4.5.2.

Команда get обычно не показывает атрибуты конфигурации, относящиеся к TCP или связям SHM. Однако, такие атрибуты могут быть установлены в клиенте MySQL Cluster Manager (командой set), как только они были установлены, они будут показаны командой get.

4.5.2. Команда reset

reset [--sequential-restart] filter_specification_list
      cluster_name
      filter_specification_list:
      filter_specification[,
      filter_specification][,...]
      filter_specification:
      attribute_name[:
      process_specification]
      [+process_specification]]
      process_specification:
      [process_name]
      [:process_id]
      process_name:
      {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

Эта команда перезагружает признак к его значению по умолчанию. Атрибуты могут быть установлены на уровне процесса или на уровне экземпляра. Чтобы перезагрузить признак на уровне процесса, используйте спецификацию фильтра, имеющую форму attribute_name :process_name, где attribute_name это имя признака, который будет перезагружен, а process_name это имя процесса MySQL NDB Cluster. Чтобы перезагрузить признак конфигурации на уровне экземпляра, используйте спецификацию фильтра формы attribute_name :process_name: process_id, где process_id это ID процесса.

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

mcm> reset DataMemory mycluster;
ERROR 3 (00MGR): Illegal syntax

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

mcm> reset :ndbd mycluster;
ERROR 3 (00MGR): Illegal syntax

mcm> reset :ndbd:3 mycluster;
ERROR 3 (00MGR): Illegal syntax

Предположим, что память данных для всех процессов ndbd в кластере mycluster была установлена в 500 МБ, как показано в выводе этой команды get:

mcm> get DataMemory mycluster;
+------------+-------+----------+-----+----------+-----+---------+---------+
| Name       | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+-------+----------+-----+----------+-----+---------+---------+
| DataMemory | 500M  | ndbd     | 2   |          |     | Process |         |
| DataMemory | 500M  | ndbd     | 3   |          |     | Process |         |
+------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.91 sec)

Мы видим из записей в столбце Level, что DataMemory задан для обоих процессов ndbd на уровне процесса. Значение уровня процесса не может быть перезагружено на уровне экземпляра, как показано здесь:

mcm> reset DataMemory:ndbd:2 mycluster;
ERROR 6010 (00MGR): No matching user defined setting was
found for config attribute DataMemory

mcm> reset DataMemory:ndbd:3 mycluster;
ERROR 6010 (00MGR): No matching user defined setting was
found for config attribute DataMemory

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

mcm> reset DataMemory:ndbd:2,DataMemory:ndbd:3 mycluster;
ERROR 6010 (00MGR): No matching user defined setting was
found for config attribute DataMemory

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

mcm> reset DataMemory:ndbd mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.16 sec)

Если вы выполняете команду get как показано ранее, результат теперь будет пуст:

mcm> get DataMemory mycluster;
Empty set (0.74 sec)

Это потому что команда get по умолчанию не сообщает о значениях по умолчанию. Чтобы получить DataMemory после сброса, необходимо вызвать get с опцией --include-defaults (краткая форма: -d):

mcm> get --include-defaults DataMemory mycluster;
+------------+----------+----------+-----+----------+-----+---------+---------+
| Name       | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------+----------+----------+-----+----------+-----+---------+---------+
| DataMemory | 83886080 | ndbd     | 2   |          |     | Default |         |
| DataMemory | 83886080 | ndbd     | 3   |          |     | Default |         |
+------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.21 sec)

Значения DataMemory теперь включены в вывод и отмечены словом Default в столбце Comments.

Теперь предположите, что атрибут конфигурации mysqld wait_timeout для процесса mysqld с ID 4 кластера mycluster был ранее установлен в значение value 200 и что никакие другие изменения не были применены к этому признаку:

mcm> set wait_timeout:mysqld:4=200 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.78 sec)

mcm> get -d wait_timeout:mysqld:4 mycluster;
+--------------+-------+----------+-----+----------+-----+-------+---------+
| Name         | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment |
+--------------+-------+----------+-----+----------+-----+-------+---------+
| wait_timeout | 200   | mysqld   | 4   |          |     |       |         |
+--------------+-------+----------+-----+----------+-----+-------+---------+
1 row in set (0.98 sec)

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

mcm> reset wait_timeout:mysqld mycluster2;
ERROR 6010 (00MGR): No matching user defined setting was
found for config attribute wait_timeout

Если вы хотите перезагрузить этот признак к его значению по умолчанию, необходимо использовать команду reset с уровнем экземпляра wait_timeout:mysqld:4:

mcm> reset wait_timeout:mysqld:4 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.6 sec)

Как только вы перезагрузили wait_timeout, это больше не появляется в выводе get:

mcm> get wait_timeout:mysqld mycluster;
Empty set (1.42 sec)

Это потому, что поведение по умолчанию get должно показать только те значения, которые были установлены MySQL Cluster Manager или пользователем. С тех пор, как wait_timeout был возвращен к его значению по умолчанию, необходимо использовать опцию --include-defaults (краткая форма: -d), чтобы получить его, как показано здесь:

mcm> get -d wait_timeout:mysqld mycluster;
+--------------+-------+----------+-----+----------+-----+---------+---------+
| Name         | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+--------------+-------+----------+-----+----------+-----+---------+---------+
| wait_timeout | 28800 | mysqld   | 4   |          |     | Default |         |
+--------------+-------+----------+-----+----------+-----+---------+---------+
1 row in set (1.66 sec)

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

mcm> get -d IndexMemory mycluster;
+-------------+----------+----------+-----+----------+-----+---------+---------+
| Name        | Value    | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+----------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 18874368 | ndbd     | 2   |          |     | Default |         |
| IndexMemory | 18874368 | ndbd     | 3   |          |     | Default |         |
+-------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.24 sec)

Теперь примените изменение уровня процесса и изменение уровня экземпляра этого признака. Можно сделать это одной командой set:

mcm> set IndexMemory:ndbd=500M,IndexMemory:ndbd:3=750M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.29 sec)

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

mcm> get IndexMemory mycluster;
+-------------+-------+----------+-----+----------+-----+---------+---------+
| Name        | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+-------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 500M  | ndbd     | 2   |          |     | Process |         |
| IndexMemory | 750M  | ndbd     | 3   |          |     |         |         |
+-------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (0.85 sec)

Если уровень экземпляра IndexMemory для процесса ndbd с ID процесса 3 перезагружается, уровень процесса все еще, применяется, как показано здесь:

mcm> reset IndexMemory:ndbd:3 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.4 sec)

mcm> get IndexMemory mycluster;
+-------------+-------+----------+-----+----------+-----+---------+---------+
| Name        | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+-------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 500M  | ndbd     | 2   |          |     | Process |         |
| IndexMemory | 500M  | ndbd     | 3   |          |     | Process |         |
+-------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.09 sec)

Теперь повторно используйте уровень экземпляра IndexMemory и используйте get, чтобы проверить, что это вступило в силу:

mcm> set IndexMemory:ndbd:3=750M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.79 sec)

mcm> get IndexMemory mycluster;
+-------------+-------+----------+-----+----------+-----+---------+---------+
| Name        | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+-------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 500M  | ndbd     | 2   |          |     | Process |         |
| IndexMemory | 750M  | ndbd     | 3   |          |     |         |         |
+-------------+-------+----------+-----+----------+-----+---------+---------+
2 rows in set (1.76 sec)

Если вы перезагружаете настройку уровня процесса, настройка уровня экземпляра остается, и только процесс ndbd с ID процесса 2 имеет IndexMemory сброшенный к значению по умолчанию, настройка уровня экземпляра остается в силе, как вы видите из следующей последовательности команд:

mcm> reset IndexMemory:ndbd mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.36 sec)

mcm> get -d IndexMemory mycluster;
+-------------+----------+----------+-----+----------+-----+---------+---------+
| Name        |  Value   | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+-------------+----------+----------+-----+----------+-----+---------+---------+
| IndexMemory | 18874368 | ndbd     | 2   |          |     | Default |         |
| IndexMemory | 750M     | ndbd     | 3   |          |     |         |         |
+-------------+----------+----------+-----+----------+-----+---------+---------+
2 rows in set (0.10 sec)

Если порядок спецификаторов в оригинальной команде, которые устанавливают IndexMemory был полностью изменен, как IndexMemory:ndbd:3=750M,IndexMemory:ndbd=500M, изменение уровня экземпляра было бы отвергнуто изменением уровня процесса и IndexMemory для обоих процессов ndbd был 500M.

Команды get и reset полностью поддерживают многократные атрибуты репликации, например, если у признака replicate_ignore_table есть много входов:

mcm> get replicate_ignore_table:mysqld mycluster;
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
| Name                   | Value        | Process1 | NodeId1 | Process2 | NodeId2 | Level   | Comment     |
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
| replicate_ignore_table | mydb.t1      | mysqld   | 50      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.t50     | mysqld   | 50      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.mytable | mysqld   | 50      |          |         | Process | Multi-entry |
| replicate_ignore_table | mydb.t51     | mysqld   | 51      |          |         |         | Multi-entry |
| replicate_ignore_table | mydb.mytable | mysqld   | 51      |          |         | Process | Multi-entry |
+------------------------+--------------+----------+---------+----------+---------+---------+-------------+
5 rows in set (0.05 sec)

Не определяя ID узла, все записи признака, связанные с указанным типом процесса, перезагружаются со следующей командой:

mcm> reset replicate_ignore_table:mysqld mycluster;
# removes all process level entries
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (0.47 sec)

mcm> get replicate_ignore_table:mysqld mycluster;
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
| Name                   | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment     |
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
| replicate_ignore_table | mydb.t1  | mysqld   | 50      |          |         |       | Multi-entry |
| replicate_ignore_table | mydb.t50 | mysqld   | 50      |          |         |       | Multi-entry |
| replicate_ignore_table | mydb.t51 | mysqld   | 51      |          |         |       | Multi-entry |
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
3 rows in set (0.08 sec)

С определенным ID узла только записи экземпляра, связанные с узлом с этим ID, перезагружаются следующей командой:

mcm> reset replicate_ignore_table:mysqld:51 mycluster;
# removes all instance level entries for nodeid 51
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (0.57 sec)

mcm> get replicate_ignore_table:mysqld mycluster;
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
| Name                   | Value    | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment     |
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
| replicate_ignore_table | mydb.t1  | mysqld   | 50      |          |         |       | Multi-entry |
| replicate_ignore_table | mydb.t50 | mysqld   | 50      |          |         |       | Multi-entry |
+------------------------+----------+----------+---------+----------+---------+-------+-------------+
2 rows in set (0.09 sec)

Команды reset выполняются, был ли кластер запущен или нет. В кластере, который не работает, MySQL Cluster Manager просто обновляет конфигурационные файлы. Однако, в работающем кластере MySQL Cluster Manager кроме того автоматически выполняет любые перезапуски узла или всего кластера, которые требуются, чтобы заставлять изменения признака вступать в силу. Для MySQL Cluster Manager 1.4.8 и позже: используйте опцию --sequential-restart, чтобы сделать перезапуск кластера последовательным). Однако, так как операции по перезапуску могут занять много времени, предпочтительно сделать изменения конфигурации прежде, чем запустить кластер.

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

Точно так же возможно перезагрузить такой признак на уровне процесса или экземпляра, в зависимости от уровня или уровней, на которых это было установлено. В любом случае требуется расширенная форма спецификатора процесса, устанавливая признак, который относится к связи между процессами. Предположите, что параметр SendBufferMemory был ранее установлен для всех связей между двумя процессами ndbd и двумя процессами mysqld, которые работают в MySQL NDB Cluster с именем mycluster2:

mcm> get SendBufferMemory mycluster2;
+------------------+-------+----------+-----+----------+-----+---------+---------+
| Name             | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------------+-------+----------+-----+----------+-----+---------+---------+
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 5   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 4   | Process |         |
| SendBufferMemory | 8M    | ndbd     | 3   | mysqld   | 5   |         |         |
+------------------+-------+----------+-----+----------+-----+---------+---------+
4 rows in set (0.59 sec)

Предположим, что вы хотите перезагрузить SendBufferMemory только для связи между процессом ndbd с ID 3 и процессом mysqld с ID 5. Значение SendBufferMemory, которое относится к этой связи, определяется на уровне экземпляра, потому что значение столбца Level, соответствующее этой связи, пусто, это означает, что возможно перезагрузить это значение на уровне экземпляра. Можно сделать это использованием reset:

mcm> reset SendBufferMemory:ndbd:3+mysqld:5 mycluster2;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.03 sec)

Можно проверить, что признак был перезагружен, используя команду get. Однако, как отмечено ранее, как только настройка уровня экземпляра была удалена, настройка уровня процесса для этого признака снова вступает в силу, чтобы то же самое значение относилось ко всем связям между процессами ndbd и mysqld:

mcm> get SendBufferMemory mycluster2;
+------------------+-------+----------+-----+----------+-----+---------+---------+
| Name             | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------------+-------+----------+-----+----------+-----+---------+---------+
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 5   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 5   | Process |         |
+------------------+-------+----------+-----+----------+-----+---------+---------+
4 rows in set (0.87 sec)

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

mcm> reset SendBufferMemory:ndbd+mysqld mycluster2;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (8.01 sec)

Можно проверить, что признак был перезагружен для всех связей между процессами ndbd и mysqld, используя команду get:

mcm> get -d SendBufferMemory mycluster2;
Empty set (1.39 sec)

Как отмечено в другом месте в этом руководстве (см. раздел 4.5.1), пустой набор результатов должен ожидаться в этом случае, даже когда get вызвана, используя опцию --include-defaults (или -d), так как клиент MySQL Cluster Manager не показывает атрибутов, которые появляются в разделах [tcp] или [shm] файла config.ini, если они не были явно установлены пользователем.

4.5.3. Команда set

set [--sequential-restart] attribute_assignment_list
    cluster_name
    attribute_assignment_list:
    attribute_assignment[,
    attribute_assignment][,...]
    attribute_assignment:
    attribute_name:
    process_specification
    [+process_specification][=value]
    process_specification:
    [process_name][:
    process_id]
    process_name:
    {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}

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

Команды set выполняются безотносительно запуска кластера. В кластере, который не работает, MySQL Cluster Manager просто обновляет конфигурационные файлы. Однако, в работающем кластере MySQL Cluster Manager кроме того автоматически выполняет любые перезапуски узла или всего кластера (см. здесь), которые требуются, чтобы заставлять изменения признака вступать в силу (в MySQL Cluster Manager 1.4.8 и позже используйте опцию --sequential-restart, чтобы сделать перезапуск последовательным. Однако, так как операции по перезапуску, особенно для всего кластера, могут занять много времени, предпочтительно сделать изменения конфигурации прежде, чем запустить кластер и поместить его в рабочую среду.

Чтобы установить признак на уровне процесса, используйте set, которая содержит назначение признака, имеющее форму attribute_name: process_name= value.

Например, чтобы установить DataMemory в 500 MB на уровне процесса ndbd, чтобы новое значение относилось ко всем процессам ndbd кластера, вы можете использовать команду set, содержащую назначение признака DataMemory:ndbd=500M:

mcm> set DataMemory:ndbd=500M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (5.68 sec)

Чтобы проверить, что новое значение используется, можно применить команду get:

mcm> get DataMemory mycluster;
+------------+-------+----------+------+----------+------+---------+---------+
| Name       | Value | Process1 | Id1  | Process2 | Id2  | Level   | Comment |
+------------+-------+----------+------+----------+------+---------+---------+
| DataMemory | 500M  | ndbd     | 1    |          |      | Process |         |
| DataMemory | 500M  | ndbd     | 2    |          |      | Process |         |
+------------+-------+----------+------+----------+------+---------+---------+
2 rows in set (0.79 sec)

См. раздел 4.5.1.

Чтобы установить признак для определенного экземпляра процесса, включайте ID процесса в назначение признака, форма такого назначения признака attribute_name: process_name: process_id= value. Например, чтобы установить признак wait_timeout для процесса mysqld с ID 50 в 200, надо указать назначение признака wait_timeout:mysqld:51=200:

mcm> set wait_timeout:mysqld:50=200 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.18 sec)

Можно проверить, что назначение вступило в силу, используя применимую команду get:

mcm> get wait_timeout mycluster;
+--------------+-------+----------+------+----------+------+-------+---------+
| Name         | Value | Process1 | Id1  | Process2 | Id2  | Level | Comment |
+--------------+-------+----------+------+----------+------+-------+---------+
| wait_timeout | 200   | mysqld   | 50   |          |      |       |         |
+--------------+-------+----------+------+----------+------+-------+---------+
1 row in set (0.50 sec)

Атрибуты, которые отмечены Read only нельзя менять. Попытка это сделать терпит неудачу с ошибкой, как показано здесь:

mcm> get :ndbd mycluster;
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| Name     | Value       | Process1 | Id1 | Process2 | Id2 | Level | Comment   |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
| DataDir  | /opt/c2data | ndbd     | 1   |          |     |       |           |
| HostName | tonfisk     | ndbd     | 1   |          |     |       | Read only |
| NodeId   | 2           | ndbd     | 1   |          |     |       | Read only |
| DataDir  | /opt/c3data | ndbd     | 2   |          |     |       |           |
| HostName | grindval    | ndbd     | 2   |          |     |       | Read only |
| NodeId   | 3           | ndbd     | 2   |          |     |       | Read only |
+----------+-------------+----------+-----+----------+-----+-------+-----------+
6 rows in set (1.42 sec)
mcm> set HostName:ndbd:1=lax mycluster;
ERROR 6008 (00MGR): Config attribute HostName is read only and cannot be changed

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

Обязательный атрибут NoOfReplicas должен быть установлен только на уровне процесса. Попытка установить его на уровне экземпляра может оставить кластер, MySQL Cluster Manager или обоих в непригодной конфигурации.

В отличие от экземпляра с командой get, вы не можете использовать command, you cannot issue a set, действуя на глобальную область видимости то есть, вы не можете в единственном назначении признака устанавливать единственное значение для признака, таким образом, что новое значение атрибута относится ко всем процессам, независимо от типа процесса, даже если признак, имеющий это имя, может быть применен ко всем типам процесса. При этом вы не можете определить много типов процесса в единственном назначении признака. Пытаясь сделать любую из этих вещей, вы получите ошибку, как показано здесь:

mcm> set DataDir=/var/cluster-data mycluster;
ERROR 3 (00MGR): Illegal syntax

mcm> set DataDir:ndb_mgmd,ndbd,mysqld=/var/cluster-data mycluster;
ERROR 3 (00MGR): Illegal syntax

Вместо этого необходимо использовать назначение признака уровня процесса на каждый тип процесса. Однако, вы не обязательно обязаны давать отдельную команду для каждого типа процесса. Вместо этого можно также сделать мног назначений признака в одной команде set, поставляя назначения как список разделенных запятой значений. Эта команда set назначает /var/cdata как каталог данных (DataDir) для всех процессов MySQL NDB Cluster в mycluster:

mcm> set DataDir:ndb_mgmd=/var/cdata, \
DataDir:ndbd=/var/cdata, \
DataDir:mysqld=/var/cdata mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.66 sec)

mcm> get DataDir mycluster;
+---------+------------+----------+---------+----------+---------+-------+---------+
| Name    | Value      | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment |
+---------+------------+----------+---------+----------+---------+-------+---------+
| DataDir | /var/cdata | ndbmtd   | 1       |          |         |       |         |
| DataDir | /var/cdata | ndbmtd   | 2       |          |         |       |         |
| DataDir | /var/cdata | ndb_mgmd | 49      |          |         |       |         |
| datadir | /var/cdata | mysqld   | 50      |          |         |       |         |
| datadir | /var/cdata | mysqld   | 51      |          |         |       |         |
+---------+------------+----------+---------+----------+---------+-------+---------+
5 rows in set (0.08 sec)

Как вы видите из команды get, назначения признака были успешны и вступили в силу на уровне процесса.

В MySQL Cluster Manager названия атрибута конфигурации нечувствительны к регистру. Посмотрите здесь подробности.

Точно так же вы не можете сослаться на много ID процессов в единственном назначении признака, даже если это процессы того же самого типа, следующая команда не работает:

mcm> set DataMemory:ndbd:1,2=750M mycluster;
ERROR 3 (00MGR): Illegal syntax

Вместо этого необходимо было бы использовать следующую команду:

mcm> set DataMemory:ndbd:1=750M,DataMemory:ndbd:2=750M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.70 sec)

Конечно, если это только два узла данных в mycluster, команда set DataMemory:ndbd=750M mycluster также выполняет ту же самую задачу.

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

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

mcm> set UndoDataBuffer=32M,UndoIndexBuffer=8M:ndbd mycluster;
ERROR 3 (00MGR): Illegal syntax

mcm> set DataMemory,IndexMemory:ndbd=1G mycluster;
ERROR 3 (00MGR): Illegal syntax

Однако, если вы пишете полное и действительное назначение признака на каждый признак, значение которого вы хотите обновить, можно переписать эти две команды так, чтобы они выполнились успешно, как показано здесь:

mcm> set UndoDataBuffer:ndbd=32M,UndoIndexBuffer:ndbd=8M mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.62 sec)

mcm> set DataMemory:ndbd=1G,IndexMemory:ndbd=1G mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.04 sec)

На самом деле нет никакой причины, что вы не можете выполнить все четыре назначения одной командой set, используя список из четырех назначений признака:

mcm> set UndoDataBuffer:ndbd=32M,UndoIndexBuffer:ndbd=8M, \
            DataMemory:ndbd=1G, IndexMemory:ndbd=1G mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.24 sec)

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

В Windows, устанавливая атрибуты, значения которых содержат пути (например, DataDir), необходимо заменить любые знаки наклонной черты влево в пути наклонными чертами вправо. Предположим, что вы хотите использовать C:\temp\node50 для атрибута tmpdir в процессе mysqld с ID 50 в MySQL NDB Cluster mycluster, который работает под Windows. Исходное значение для этого признака может быть найдено через get :

mcm> get tmpdir mycluster;
+--------+----------------+----------+-----+----------+-----+-------+---------+
| Name   | Value          | Process1 | Id1 | Process2 | Id2 | Level | Comment |
+--------+----------------+----------+-----+----------+-----+-------+---------+
| tmpdir | c:\c50data\tmp | mysqld   | 50  |          |     |       |         |
+--------+----------------+----------+-----+----------+-----+-------+---------+
1 row in set (0.22 sec)

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

mcm> set tmpdir:mysqld:50=c:/temp/node50 mycluster;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (2.62 sec)

Когда вы проверяете использование значения get даже при том, что это первоначально указали, используя наклонные черты влево, наклонные черты вправо используются, показывая новое значение:

mcm> get tmpdir mycluster;
+--------+----------------+----------+-----+----------+-----+-------+---------+
| Name   | Value          | Process1 | Id1 | Process2 | Id2 | Level | Comment |
+--------+----------------+----------+-----+----------+-----+-------+---------+
| tmpdir | c:/temp/node50 | mysqld   | 50  |          |     |       |         |
+--------+----------------+----------+-----+----------+-----+-------+---------+
1 row in set (0.22 sec)

Однако, при попытке использовать наклонные черты влево в пути в команде set команда терпит неудачу:

mcm> set tmpdir:mysqld:4=c:\temp\4 mycluster;
Outfile disabled. ERROR: Unknown command '\4'.
ERROR 6014 (00MGR): Path name for parameter tmpdir must be absolute.
The value 'c:mp4' is illegal.

Урегулирование признаков соединения по протоколу TCP. Для нескольких признаков, которые применяются только используя соединения по протоколу TCP (например, SendBufferMemory и ReceiveBufferMemory) необходимо использовать измененный синтаксис для назначений значения атрибута. В этом случае назначение признака содержит два технических требований процесса, один для каждого типа процесса или экземпляра, к которому урегулирование применяется, объединяемых знаком плюс (+). Для следующего примера считайте кластер mycluster2 состоящим из процессов, показанных здесь:

mcm> list processes mycluster2;
+----+----------+----------+
| Id | Name     | Host     |
+----+----------+----------+
| 49 | ndb_mgmd | grindval |
| 1  | ndbd     | tonfisk  |
| 2  | ndbd     | flundra  |
| 50 | mysqld   | haj      |
| 51 | mysqld   | torsk    |
+----+----------+----------+
5 rows in set (0.16 sec)

См. раздел 4.6.3.

Атрибуты соединения по протоколу TCP не показывают в выводе команды get, если они не были установлены. Это означает, что до указания SendBufferMemory впервые, вы получаете пустой результат при попытке получить его значение, как показано здесь:

mcm> get SendBufferMemory mycluster2;
Empty set (0.18 sec)

mcm> get --include-defaults SendBufferMemory mycluster2;
Empty set (0.93 sec)

Чтобы установить параметр SendBufferMemory в 4 MB для всех соединений по протоколу TCP между узлами данных и узлами SQL, можно использовать команду, показанную здесь:

mcm> set SendBufferMemory:ndbd+mysqld=4M mycluster2;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (6.44 sec)

Если вы проверяете значение признака впоследствии, используя get, вы видите, что значение применяется ко всем возможным связям между каждым из двух процессов ndbd и каждым из двух процессов mysqld в mycluster2, таким образом в выводе есть четыре строки:

mcm> get SendBufferMemory mycluster2;
+------------------+-------+----------+-----+----------+-----+---------+---------+
| Name             | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------------+-------+----------+-----+----------+-----+---------+---------+
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 5   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 4   | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 5   | Process |         |
+------------------+-------+----------+-----+----------+-----+---------+---------+
4 rows in set (1.63 sec)

Чтобы сменить эту настройку только для связи между узлом данных с ID процесса 2 и процессом mysqld (ID процесса 4), можно включать ID процесса в каждую из двух частей спецификации процесса, как показано здесь:

mcm> set SendBufferMemory:ndbd:2+mysqld:4=8M mycluster2;
+-----------------------------------+
| Command result                    |
+-----------------------------------+
| Cluster reconfigured successfully |
+-----------------------------------+
1 row in set (7.95 sec)

Когда вы проверяете результат, используя get, вы видите, что новое значение применяется на уровне экземпляра и только к связи между процессами, имеющими ID 2 и 4, настройка уровня процесса, сделанная ранее, все еще относится к оставшимся 3 связям:

mcm> get SendBufferMemory mycluster2;
+------------------+-------+----------+-----+----------+-----+---------+---------+
| Name             | Value | Process1 | Id1 | Process2 | Id2 | Level   | Comment |
+------------------+-------+----------+-----+----------+-----+---------+---------+
| SendBufferMemory | 8M    | ndbd     | 2   | mysqld   | 50  |         |         |
| SendBufferMemory | 4M    | ndbd     | 2   | mysqld   | 51  | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 50  | Process |         |
| SendBufferMemory | 4M    | ndbd     | 3   | mysqld   | 51  | Process |         |
+------------------+-------+----------+-----+----------+-----+---------+---------+
4 rows in set (0.24 sec)

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

mcm> set SendBufferMemory:ndbd+mysqld:4=2M mycluster2;
ERROR 3 (00MGR): Illegal syntax

mcm> set SendBufferMemory:ndbd:2+mysqld=2M mycluster2;
ERROR 3 (00MGR): Illegal syntax

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

Настройка пула соединений mysqld. Предоставление возможности объединения связи для mysqld может быть сделано, установив параметр ndb-cluster-connection-pool к желаемому количеству связей, но также требует дополнительного шага в создании кластера.

Так как процесс mysqld пытается установить многократные связи с кластером, когда объединение связи позволено, кластер должна формироваться с запасными или пустыми соединениями. Можно сделать это, добавив (в других отношениях) не используемую запись ndbapi в список process_host, используемом в create cluster:

mcm> create cluster -P mypackage \
   >        -R ndb_mgmd@10.100.10.97,ndbd@10.100.10.98,ndbd@10.100.10.99, \
               mysqld@10.100.10.100,ndbapi@10.100.10.100, \
               ndbapi@10.100.10.100,ndbapi@10.100.10.100 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster created successfully |
+------------------------------+
1 row in set (6.58 sec)

После этого можно использовать команду set, чтобы установить размер пула связи согласно количеству избыточных связей, доступных в файле config.ini:

mcm> set ndb_cluster_connection_pool:mysqld=4;

Атрибут user не поддержан для mysqld. Попытка установить параметр user для процесса mysqld в настоящее время не поддерживается и приводит к предупреждению, написанному в журнал MySQL Cluster Manager.

4.6. Команды процессов MySQL Cluster Manager

Эта секция содержит информацию о командах клиента MySQL Cluster Manager, которые начинают и останавливают процессы MySQL NDB Cluster, а также определяют, какие процессы в настоящее время работают.

MySQL Cluster Manager, ndb_mgm и старт или остановка процессов. Для управления MySQL NDB Cluster из MySQL Cluster Manager рекомендуется не применять клиент ndb_mgm, который идет в дистрибутиве MySQL NDB Cluster, чтобы выполнить операции, которые включают старт или остановку узлов. Они включают, но не ограничиваются следующими командами клиента:

4.6.1. Команда add process

add process {--processhosts=|-R }process_host_list
            [--set=attribute_assignment_list]
            [--verbose | -v] [--sequential-restart] cluster_name
            process_host_list:
            process_name[:
            node_id]@host[,
            process_name@host[,...]]
            process_name:
            {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi}
            attribute_assignment_list:
            attribute_assignment[,
            attribute_assignment][, ...]
            attribute_assignment:
            attribute_name:
            process_name[=
            value]

Эта команда добавляет к существующему кластеру один или несколько процессов, которые определяются, используя process_host_list с опцией --processhosts, формат которой совпадает с используемым в create cluster . Любые хосты, на которые ссылаются в списке, должны быть зарегистрированными в месте, которому принадлежит кластер. Кроме того, все хосты должны быть разрешимыми.

Например, следующая команда add process добавляет два процесса mysqld на хостах tonfisk и flundra в кластер mycluster:

mcm> add process --processhosts=mysqld@tonfisk,mysqld@flundra mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 10.39 sec)

С опцией --verbose команда показывает обновленный список процессов, после того, как новые процессы были добавлены:

mcm> add process --processhosts=ndbmtd@tonfisk,ndbmtd@flundra --verbose mycluster;
+--------+----------+---------+
| NodeId | Name     | Host    |
+--------+----------+---------+
| 49     | ndb_mgmd | tonfisk |
| 53     | ndb_mgmd | flundra |
| 1      | ndbmtd   | tonfisk |
| 2      | ndbmtd   | flundra |
| 3      | ndbmtd   | tonfisk |
| 4      | ndbmtd   | flundra |
| 50     | mysqld   | tonfisk |
| 51     | mysqld   | flundra |
| 52     | ndbapi   | *       |
+--------+----------+---------+
9 rows in set (2 min 7.57 sec)

Можно также вручную назначить узлу ID на новый процесс, который вы добавляете к кластеру, добавляя : node_ID после process_name. MySQL Cluster Manager 1.3.3 и ранее, пытаясь вручную назначить узлу ID меньше, чем 49 для 49 for ndb_mgmd, mysqld, или ndbapi, вылетает с ошибкой, ограничение, однако, было снято начиная с MySQL Cluster Manager 1.3.4. Тем не менее, вам все еще рекомендуют применить наиболее успешную практику сохранения ID узла от 1 до 48 для узлов данных. Следующая команда добавляет два процесса ndbd с ID узлов 10 и 11 на хостах tonfisk и flundra, соответственно, к mycluster:

mcm> add process --processhosts=ndbd:10@tonfisk,ndbd:11@flundra mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 13.40 sec)

NDB 8.0 поддерживает до 144 узлов данных (для выпуска 8.0.18 и позже). Управляя кластером NDB 8.0, вам рекомендуют применить наиболее успешную практику сохранения ID узла от 1 до 144 для узлов данных.

Если кластер не работает, когда вы выполняете add process , рекомендуется, чтобы вы запустили все новые процессы, добавленные этой командой, вместе, используя start process --added или запустили их вместе с кластером, используя команду start cluster . Помимо старта узлов, любая из двух команд также инициализирует добавленные узлы и заставляет новую группу узлов кластера быть сформированной через команду CREATE NODEGROUP. Если добавленные узлы начаты с помощью start process --initial, вы тогда обязаны выполнить CREATE NODEGROUP вручную через клиент ndb_mgm.

Если кластер работает, когда вы выполняете add process , перезапуск для кластера выполняется в конце add process . MySQL Cluster Manager 1.4.8 и позже : используйте опцию --sequential-restart, чтобы сделать перезапуск последовательным.

Добавление свободных процессов

Используя add process, можно добавить неуправляемые процессы mysqld или слоты ndbapi для приложений ndbapi, таких как ndb_restore. Чтобы добавить неуправляемый процесс mysqld, укажите имя хоста с подстановочным знаком * (символ звездочки):

mcm> add process --processhosts=mysqld@*tonfisk,mysqld@*flundra mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 3.14 sec)

Чтобы позволить неуправляемым узлам mysqld соединяться от любого хоста, используйте подстановочный знак * (символ звездочки) вместо имени хоста или IP-адреса:

mcm> add process --processhosts=mysqld@*,mysqld@* mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 3.14 sec)

То же самое относится к слотам ndbapi для приложений ndbapi: укажите имя хоста с подстановочным символом, чтобы ограничить возможность соединения определенным хостом или используйте только подстановочный знак без имени хоста, чтобы позволить приложение ndbapi от любого хоста:

mcm> add process --processhosts=ndbapi@*tonfisk,ndbapi@* mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Processes added successfully |
+------------------------------+
1 row in set (2 min 8.13 sec)

Поскольку свободные процессы не организованы MySQL Cluster Manager, нет никакой потребности выполнять команду start process --added после того, как они были успешно добавлены к кластеру.

Применение add process для упрощения create cluster

Процессы, добавленные перед первым запуском кластера, начаты вместе с кластером. Это позволяет использовать эту команду, чтобы упростить очень длинную команду create cluster . Рассмотрите следующий набор команд, который создает и затем запускает кластер mycluster:

create cluster --processhosts=ndb_mgmd@host1,ndbd@host1,ndbd@host2, \
       mysqld@host3,mysqld@host4 mycluster;
start cluster mycluster;

Длинная create cluster может быть разделена на более короткое (и более понятные) команды. Этот набор команд выполняет ту же самую задачу, как предыдущий набор, создавая mycluster с точно теми же самыми процессами и хостами как прежде:

create cluster --processhosts=ndb_mgmd@host1 mycluster;
add process --processhosts=ndbd@host1,ndbd@host2 mycluster;
add process --processhosts=mysqld@host3,mysqld@host4 mycluster;
start cluster mycluster;

Заметьте, что процесс, который добавляется к кластеру, который был создан, используя create cluster --import перед импортом, добавляется со статусом import, что означает, что этот кластер не может быть запущен или остановлен через start process или stop process до выполнения импорта.

Формирование нового процесса, добавляя его

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

Унаследованные параметры настройки признака могут быть отвергнуты, добавляя процессы, чтобы сделать это, используйте в команде add process опцию --set . Эта опция берет в качестве аргумента список значений признаков в формате, используемом с командами get и set. Предположим, что сейчас для процесса ndbd кластера mycluster параметр уровня процесса DataDir = /home/users/ndb/cluster-data, но вы хотите добавить два новых процесса ndbd, которые используют /tmp/cluster/data вместо этого. Можно сделать это с использованием следующей команды:

mcm> add process --set=ndbd:DataDir=/tmp/cluster/data \
   >     --processhosts=mysqld@tonfisk,mysqld@flundra mycluster;

В отличие от пути, которым вы используете команду set, знак равенства (=) немедленно после опции --set обязателен.

Устанавливая таким образом атрибуты, которые содержат пути для процессов, работающих в Windows, необходимо заменить любые наклонные черты влево (\) наклонными чертами вправо (/) так же, как с командой set.

После того, как процесс был добавлен, используя add process, можно также использовать команду set, чтобы изменить параметры настройки (или определить дополнительные), как с любым другим процессом кластера, организуемым MySQL Cluster Manager.

Когда IPv6-системы Windows используются в качестве хостов MySQL NDB Cluster под MySQL Cluster Manager, необходимо сослаться на эти хосты, используя адреса IPv4. Иначе MySQL Cluster Manager не способен соединиться с процессами агента на тех хостах. Посмотрите раздел 5.1.

4.6.2. Команда change process

change process [--sequential-restart] old_proc_type
               [:proc-id]=
               new_proc_type
               cluster_name
               old_proc_type |
               new_proc_type:
               {ndbd|ndbmtd}

Эта команда используется (MySQL NDB Cluster 7.0 и позже), чтобы изменить тип процесса для данного процесса MySQL NDB Cluster или группы процессов MySQL NDB Cluster с одного типа процесса (old-process-type) к другому типу процесса (new-process-type).

В настоящее время только два типа процесса доступны для использования с этой командой: ndbd и ndbmtd. Это означает, что change process может использоваться, чтобы изменить процесс узла данных на одном или более узлах данных от однопоточного демона узла данных (ndbd) на многопоточный демон узла данных (ndbmtd) или наоборот.

По умолчанию change process влияет на все узлы данных, работающие с old-process-type. Определяя дополнительно process_id, действие может быть ограничено узлом данных, имеющим этот ID процесса.

Предположим, что у вас есть кластер mycluster , у которого есть два узла данных ndbd, как отражено в выводе следующей команды show status:

mcm> show status --process mycluster;
+--------+----------+----------+---------+-----------+
| NodeId | Process  | Host     | Status  | Nodegroup |
+--------+----------+----------+---------+-----------+
| 49     | ndb_mgmd | flundra  | running |           |
| 1      | ndbd     | tonfisk  | running | n/a       |
| 2      | ndbd     | grindval | running | n/a       |
| 50     | mysqld   | haj      | running |           |
| 51     | mysqld   | torsk    | running |           |
| 52     | ndbapi   | *        | running |           |
+--------+----------+----------+---------+-----------+
6 rows in set (0.06 sec)

Чтобы изменить оба узла данных, чтобы они использовали многопоточный ndbmtd, дайте команду, показанную здесь, без указания process_id:

mcm> change process ndbd=ndbmtd mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process changed successfully |
+------------------------------+
1 row in set (2 min 17.51 sec)

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

mcm> show status --process mycluster;
+--------+----------+----------+---------+-----------+
| NodeId | Process  | Host     | Status  | Nodegroup |
+--------+----------+----------+---------+-----------+
| 49     | ndb_mgmd | flundra  | running |           |
| 1      | ndbmtd   | tonfisk  | running | n/a       |
| 2      | ndbmtd   | grindval | running | n/a       |
| 50     | mysqld   | haj      | running |           |
| 51     | mysqld   | torsk    | running |           |
| 52     | ndbapi   | *        | running |           |
+--------+----------+----------+---------+-----------+
6 rows in set (0.09 sec)

Перезапуск для кластера выполняется в конце команды change process. MySQL Cluster Manager 1.4.8 и позже: используйте опцию --sequential-restart, чтобы сделать его последовательным.

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

Возможно (и иногда желательно) использовать процессы узла данных ndbd и ndbmtd одновременно, таким образом также возможно использование change process, чтобы изменить единственный процесс узла данных. Чтобы сделать это, необходимо определить процесс узла данных, используя его ID процесса.

Сначала мы останавливаем кластер и проверяем, что все процессы больше не работают, как показано здесь:

mcm> stop cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster stopped successfully |
+------------------------------+
1 row in set (22.93 sec)

mcm> show status --process mycluster;
+--------+----------+----------+---------+-----------+
| NodeId | Process  | Host     | Status  | Nodegroup |
+--------+----------+----------+---------+-----------+
| 49     | ndb_mgmd | flundra  | stopped |           |
| 1      | ndbmtd   | tonfisk  | stopped | n/a       |
| 2      | ndbmtd   | grindval | stopped | n/a       |
| 50     | mysqld   | haj      | stopped |           |
| 51     | mysqld   | torsk    | stopped |           |
| 52     | ndbapi   | *        | stopped |           |
+--------+----------+----------+---------+-----------+
6 rows in set (0.05 sec)

Следующая команда изменяет только узел, имеющий ID процесса ID 2:

mcm> change process ndbmtd:2=ndbd mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process changed successfully |
+------------------------------+
1 row in set (6.52 sec)

Как вы видите, change process работает намного более быстро, когда процесс, который будет изменен, не работает. Как прежде, можно проверить, что команда выполнена, через show status :

mcm> show status --process mycluster;
+--------+----------+----------+----------+-----------+
| NodeId | Process  | Host     | Status   | Nodegroup |
+--------+----------+----------+----------+-----------+
| 49     | ndb_mgmd | flundra  | stopped  |           |
| 1      | ndbmtd   | tonfisk  | stopped  | n/a       |
| 2      | ndbd     | grindval | stopped  | n/a       |
| 50     | mysqld   | haj      | stopped  |           |
| 51     | mysqld   | torsk    | stopped  |           |
| 52     | ndbapi   | *        | stopped  |           |
+--------+----------+----------+----------+-----------+
6 rows in set (0.07 sec)

Чтобы закончить пример, мы запускаем кластер снова, используя start cluster, затем снова меняем узел 2 с ndbd на ndbmtd через change process и проверяем результат через show status :

mcm> start cluster mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Cluster started successfully |
+------------------------------+
1 row in set (36.43 sec)

mcm> change process ndbd:2=ndbmtd mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process changed successfully |
+------------------------------+
1 row in set (2 min 10.41 sec)

mcm> show status --process mycluster;
+--------+----------+----------+---------+-----------+
| NodeId | Process  | Host     | Status  | Nodegroup |
+--------+----------+----------+---------+-----------+
| 49     | ndb_mgmd | flundra  | running |           |
| 1      | ndbmtd   | tonfisk  | running | n/a       |
| 2      | ndbmtd   | grindval | running | n/a       |
| 50     | mysqld   | haj      | running |           |
| 51     | mysqld   | torsk    | running |           |
| 52     | ndbapi   | *        | running |           |
+--------+----------+----------+---------+-----------+
6 rows in set (0.11 sec)

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

Как отмечено ранее, change process работает только с процессами ndbd и ndbmtd, попытка использовать любой другой тип процесса заставляет команду терпеть неудачу с ошибкой, как показано здесь:

mcm> change process ndb_mgmd=mysqld mycluster;
ERROR 7009 (00MGR): Processes ndb_mgmd and mysqld are not interchangeable in this package

mcm> change process ndbd=mysqld mycluster;
ERROR 7009 (00MGR): Processes ndbd and mysqld are not interchangeable in this package

4.6.3. Команда list processes

list processes cluster_name

Эта команда показывает все процессы, составляющие данный кластер. Следующий пример демонстрирует, как перечислить все процессы, которые являются частью кластера mycluster:

mcm> list processes mycluster;
+--------+----------+----------+
| NodeId | Name     | Host     |
+--------+----------+----------+
| 49     | ndb_mgmd | flundra  |
| 1      | ndbd     | tonfisk  |
| 2      | ndbd     | grindval |
| 50     | mysqld   | haj      |
| 51     | mysqld   | torsk    |
| 52     | ndbapi   | *        |
+--------+----------+----------+
6 rows in set (0.03 sec)

Параметр cluster_name обязателен. Если этот аргумент опущен, команда терпит неудачу с ошибкой, как показано здесь:

mcm> list processes;
ERROR 6 (00MGR): Illegal number of operands

4.6.4. Команда start process

start process {[--initial|-i] process_id | --added} cluster_name

Эта команда начинает процесс MySQL NDB Cluster, имеющий ID процесса process_id в кластере cluster_name. Статус процесса, который будет начат, как показано show status --process, должен быть added, stopped или failed (только если сбойный процесс завершился правильно, он может быть перезапущен этой командой).

Этот пример демонстрирует, как начать процесс, имеющий ID 1 в кластере mycluster:

mcm> start process 1 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process started successfully |
+------------------------------+
1 row in set (13.93 sec)

Можно получить ID для всех процессов в кластере через show status --process или list processes. Они совпадают с ID узла для этих процессов, как показано в выводе других клиентских команд mcm, например, get, или выводе ndb_mgm -e "show" .

При использовании опции --initial (краткая форма: -i) происходит следующее:

Вызов этой команды с опцией --added, а не с ID процесса запускает все узлы, которые были добавлены ранее к кластеру командой add process , но не были запущены. Для добавленных узлов данных и mysqld применение опции --added также подразумевает использование опции --initial, то есть mcmd попытается инициализировать добавленные узлы (см. описание для опции --initial выше). Кроме того, когда используется опция --added, как только все добавленные узлы работают, команда CREATE NODEGROUP дается узлу управления для создания новой группы узлов.

Вы не можете использовать эту команду, чтобы начать процесс mysqld в остановленном или недоступном кластере, это вызовет ошибку. Это применяется, например, к случаю, в котором кластер был создан для импорта кластера, но импорт еще не закончен (см. разделы 4.4.1 и 3.5).

4.6.5. Команда stop process

stop process process_id
             cluster_name

Эта команда останавливает процесс MySQL NDB Cluster с ID процесса process_id в кластере cluster_name. Статус процесса в show status --process должен быть running.

Предположим что ID процесса узла данных в кластере mycluster = 3. Тогда этот узел данных может быть остановлен как показано здесь:

mcm> stop process 3 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process stopped successfully |
+------------------------------+
1 row in set (33.07 sec)

Можно использовать show status --process или list processes, чтобы получить ID для всех процессов в данном кластере.

В случае отказа диска, где MySQL Cluster Manager теряет каталог менеджера (включая хранилище), агент в состоянии возвратить информацию от других агентов, но он на самом деле не управляет процессами больше, хотя он может обнаружить их. Это потому, что агент MySQL Cluster Manager не может получить доступ к файлам PID. В этом случае stop process больше не работает, а вы должны завершать такие процессы вручную. Следует иметь в виду это, если StopOnError установлен в 0, агент MySQL Cluster Manager перезапускает процесс узла данных автоматически, если StopOnError = 1 (по умолчанию), необходимо выполнить start process вручную.

Эта команда не работает с процессами в кластере, созданном для импорта, где импорт еще не был на самом деле закончен. Посмотрите разделы 4.4.1 и 3.5.

4.6.6. Команда update process

update process [--remove-angel] --pid=os_pid process_id cluster_name

MySQL Cluster Manager 1.4.2 и позже: Эта команда обновляет статус процесса MySQL NDB Cluster с ID process_id в кластере cluster_name, когда статус процесса больше не отражается правильно в выводе show status --process. Это, как правило, происходит в следующих ситуациях:

Команда работает, импортируя процесс под контроль mcmd . Проверки, выполненные на процессе mcmd во время импорта кластера, выполнены для команды update process. Оба ID процесса в кластере (process_id) и его PID в операционной системе (определенный с помощью опции --pid) обязательны. Предположим что ID процесса узла данных в кластере mycluster это 3, а его PID в ОС это 9846, тогда узел данных может быть обновлен как показано здесь:

mcm> update process --pid=9846 3 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process updated successfully |
+------------------------------+
1 row in set (33.07 sec)

Для узла данных или узла SQL команда работает только, если есть по крайней мере 1 репликация на работающую группу узлов.

MySQL Cluster Manager 1.4.7 и позже, update process понимает опцию --remove-angel, которая должна использоваться, обновляя узлы данных: это закрывает любой работающий процесс ангела для узла данных и обновляет его файл PID до фактического обновления, эти шаги необходимы для процесса обновления.

4.6.7. Команда remove process

remove process [--removedirs] process_id_list cluster_name
process_id_list:
process_id[, process_id[, ...]]

Эта команда удаляет процессы в process_id_list из кластера cluster_name. Это обеспечивает средство сократить кластер офлайн.

При применении опции --removedirs все данные для указанных процессов будут удалены.

Следующие ограничения применяются, используя эту команду:

  1. Кластер должен быть в статусе created или stopped.

  2. Процессы, которые будут удалены, должны быть в статусе stopped, added или import.

  3. Команда не может удалить все процессы из кластера в статусе created, по крайней мере один процесс нужно оставить.

  4. Команда не может удалить все процессы того же самого типа из кластера со статусом stopped, по крайней мере один процесс нужно оставить в кластере для каждого типа узлов (управление, данные и API).

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

Можно использовать команды show status --process или list processes, чтобы получить ID для всех процессов в данном кластере:

mcm> show status --process mycluster;
+--------+----------+---------+--------+-----------+-----------+
| NodeId | Process  | Host    | Status | Nodegroup | Package   |
+--------+----------+---------+--------+-----------+-----------+
| 49     | ndb_mgmd | flundra | added  |           | mypackage |
| 1      | ndbmtd   | flundra | added  | n/a       | mypackage |
| 2      | ndbmtd   | flundra | added  | n/a       | mypackage |
| 50     | mysqld   | flundra | added  |           | mypackage |
| 51     | mysqld   | flundra | added  |           | mypackage |
| 52     | ndbapi   | *       | added  |           |           |
| 53     | ndbapi   | *       | added  |           |           |
+--------+----------+---------+--------+-----------+-----------+
7 rows in set (0.03 sec)

ID процесса совпадает с ID узла для процессов, показанных в выводе вышеупомянутой или некоторых других клиентских команд mcm или в выводе команды ndb_mgm -e "show" (см. здесь). В вышеупомянутом примере узел SQL с ID процесса 50 в mycluster может быть удален следующей командой:

mcm> remove process 50 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process removed successfully |
+------------------------------+
1 row in set (0.48 sec)

И в этом случае, так как кластер никогда не запускался, мы можем также удалить оба узла данных:

mcm> remove process 1,2 mycluster;
+------------------------------+
| Command result               |
+------------------------------+
| Process removed successfully |
+------------------------------+
1 row in set (0.40 sec)

4.7. Команды резервирования и восстановления в MySQL Cluster Manager

Эта секция содержит информацию о командах клиента MySQL Cluster Manager, касающихся поддержки MySQL NDB Cluster.

4.7.1. Команда abort backup

abort backup --backupid=backup_id cluster_name

Эта команда прерывает резервную копию кластера cluster_name с ID backup_id, определенным опцией --backupid. Можно получить список резервных копий и их ID, известных этому экземпляру MySQL Cluster Manager, через list backups. Если резервная копия не происходит на самом деле, команда не имеет никакого эффекта.

4.7.2. Команда backup cluster

backup cluster [--backupid=backup_id]
               [--snapshotstart | --snapshotend]
               [--waitstarted | --waitcompleted] cluster_name

Эта команда создает резервную копию MySQL NDB Cluster cluster_name. backup cluster делает только резервную копию таблиц NDB, таблицы, использующие другие механизмы хранения MySQL (например, InnoDB или MyISAM), игнорируются.

По умолчанию эта команда использует резервный ID, назначенный и возвращенный ndb_mgmd (см. здесь), можно отвергнуть это поведение, определив резервный ID, используя опцию --backupid.

Опция --snapshotstart заставляет резервную копию соответствовать статусу кластера, когда резервная копия началась.

Опция --snapshotend заставляет резервную копию отражать состояние кластера, когда резервная копия была закончена. Если никакой опция не определяется, клиент MySQL Cluster Manager действует как будто определена --snapshotend.

При использовании опции --waitstarted клиент MySQL Cluster Manager ждет, пока резервная копия не началась перед возвращением контроля пользователю, после чего пользователь может проверить статус процесса резервного копирования через команду show status и опцию --backup.

При использовании опции --waitcompleted клиент MySQL Cluster Manager ждет, пока процесс резервного копирования не будет завершен перед возвращением контроля пользователю. Если ни одна из опций --waitstarted или --waitcompleted не задана, клиент ведет себя как будто задана --waitcompleted.

mcm> backup cluster mycluster;
+-------------------------------+
| Command result                |
+-------------------------------+
| Backup completed successfully |
+-------------------------------+
1 row in set (33.50 sec)

Можно проверить, что резервная копия была выполнена, проверив вывод list backups:

mcm> list backups mycluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 1        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 1        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
+----------+--------+---------+----------------------+---------+
4 rows in set (0.02 sec)

Каждый строка в выводе представляет образ то есть, ряд резервных файлов, определенных для данной резервной копии кластера на заданном узле данных. Значение Timestamp в UTC. Образ резервной копии сохраняется в каталоге BackupDataDir /BACKUP/BACKUP-Id, где BackupDataDir параметр кластера. Если не указано BackupDataDir, это принимает значение DataDir, чтобы образ был сохранен в каталоге Datadir /BACKUP/BACKUP-backup_id.

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

BackupId используется с abort backup и restore cluster.

Логическая резервная копия для метаданных таблицы NDB

Чтобы позволить больше гибкости для реконфигурации кластера во время восстановления, начиная с версии 1.4.1, команда backup cluster также создает логическую резервную копию для метаданных таблиц NDB в кластере. Используйте опцию --all с командой list backups, чтобы перечислить все резервные копии, включая логические резервные копии для метаданных таблиц NDB, которые отмечены комментарием Schema:

mcm> list backups --all newcluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 1        | 1      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 2      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 3      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 4      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 50     | tonfisk | 2016-08-12 16:55:55Z | Schema  |
+----------+--------+---------+----------------------+---------+
5 rows in set (0.02 sec)

Логическая резервная копия была создана, используя утилиту mysqldump. Резервная копия сохраняется с именем файла BACKUP-BackupID .mysql_nodeid.schema.sql в каталоге backupdatadir/BACKUP/BACKUP-id , где backupdatadir (заметьте, что имя в строчных буквах) это параметр mysqld, используемый только для определения местоположения логической резервной копии, созданной MySQL Cluster Manager. Если backupdatadir не определяется, используя команду set в клиенте mcm , значение по умолчанию /mcm_data_repository /clusters/clustername /mysqld_nodeid/, чтобы логическая резервная копия была сохранена в каталоге /mcm_data_repository /clusters/clustername /mysqld_nodeid /BACKUP/BACKUP-Id.

Следующие ограничения применяются к созданию логических резервных копий для метаданных таблицы NDB:

Резервная копия для метаданных таблицы NDB полезна для восстановления данных с одного кластера на другой с различной конфигурацией (например, когда целевой кластер для восстановления имеет различное количество узлов данных), посмотрите разделы 3.6.2.4 и 3.6.2.5 для некоторых вариантов использования.

4.7.3. Команда list backups

list backups [{--backupid=|-I }backup_id] [-all|-a] cluster_name
list backups [{--backupid=|-I }backup_id] [--agent|-A] site_name

Без опции --agent команда перечислит все резервные копии MySQL NDB Cluster кластера cluster_name, которые известны этому экземпляру MySQL Cluster Manager. Вывод включает резервную копию и ID узла, а также метку времени UTC для каждой резервной копии, как показано здесь:

mcm> list backups mycluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 1        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 1        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
+----------+--------+---------+----------------------+---------+
4 rows in set (0.02 sec)

Столбец Timestamp показывает метку времени (в UTC) первого файла в любом резервном каталоге экземпляра. Есть 3 файла в каждой резервной копии: *.ctl, *.data и *.log. Если резервный каталог экземпляра пуст, показывают метку времени самого каталога.

С опцией --backupid команды перечисляют резервные копии только с указанным ID:

mcm> list backups --backupid=2 mycluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 2        | 1      | tonfisk | 2016-10-24 22:24:54Z |         |
| 2        | 2      | tonfisk | 2016-10-24 22:24:54Z |         |
+----------+--------+---------+----------------------+---------+
2 rows in set (0.02 sec)

MySQL Cluster Manager 1.4.1 и позже: backup cluster также создает резервную копию метаданных для NDB-таблиц кластера, которые перечисляются list backups при использовании опции --all . Резервные копии метаданных отмечены комментарием Schema:

mcm> list backups --all newcluster;
+----------+--------+---------+----------------------+---------+
| BackupId | NodeId | Host    | Timestamp            | Comment |
+----------+--------+---------+----------------------+---------+
| 1        | 1      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 2      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 3      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 4      | tonfisk | 2016-08-12 16:55:52Z |         |
| 1        | 50     | tonfisk | 2016-08-12 16:55:55Z | Schema  |
+----------+--------+---------+----------------------+---------+
5 rows in set (0.02 sec)

MySQL Cluster Manager 1.4.6 и позже: при использовании опции --agent и указании параметра site_name команда перечислит резервные копии агента, созданные для определенного места:

mcm> list backups --agent mysite;
+------------+-------+---------+----------------------+---------+
| BackupId   | Agent | Host    | Timestamp            | Comment |
+------------+-------+---------+----------------------+---------+
| 1522914101 | 0     | tonfisk | 2018-04-05 07:41:41Z |         |
| 1522914105 | 0     | tonfisk | 2018-04-05 07:41:45Z |         |
| 1522914121 | 0     | tonfisk | 2018-04-05 07:42:01Z |         |
+------------+-------+---------+----------------------+---------+
3 rows in set (0.00 sec)

Резервные ID отражают времена Эпохи Unix, в которые были сделаны резервные копии.

Вывод может быть отфильтрован с опцией --backupid:

mcm> list backups --agent --backupid=1522914121 mysite;
+------------+-------+---------+----------------------+---------+
| BackupId   | Agent | Host    | Timestamp            | Comment |
+------------+-------+---------+----------------------+---------+
| 1522914121 | 0     | tonfisk | 2018-04-05 07:42:01Z |         |
+------------+-------+---------+----------------------+---------+
1 row in set (0.07 sec)

4.7.4. Команда restore cluster

restore cluster
{--backupid=|-I }backup_id
[--disable-indexes|-x]
[--disable-metadata|-M]
[--epoch|-e]
[--exclude-databases=db_name]
[--exclude-intermediate-sql-tables]
[--exclude-missing-columns]
[--exclude-missing-tables]
[--exclude-tables=db_name.tbl_name[,db_name.tbl_name][,...]]
[--include-databases=db_name
[--include-stored-grants]
[--include-tables=db_name.tbl_name[,db_name.tbl_name][,...]]
[--lossy-conversions]
[--no-binlog|-l]
[--no-restore-disk-objects]
[{--parallelism=|-p }#]
[--privilege-tables|-P]
[--progress-frequency]
[--promote-attributes]
[--rewrite-database]
[--skip-broken-objects]
[{--skip-nodeid=|-s }id_list]
[--skip-table-check]
[--skip-unknown-objects]
cluster_name

Эта команда восстанавливает кластер из резервной копии, имеющей указанный резервный ID (опция --backupid, краткая форма: -I) в MySQL NDB Cluster cluster_name. В его самой простой форме это может использоваться как показано здесь, чтобы восстановить кластер mycluster к состоянию в резервной копии, имеющей резервный ID 3:

mcm> restore cluster --backupid=3 mycluster;
+--------------------------------+
| Command result                 |
+--------------------------------+
| Restore completed successfully |
+--------------------------------+
1 row in set (18.60 sec)

Если вы вернули существующий кластер известному хорошему состоянию, необходимо сначала стереть любые существующие данные. Остановите использование кластера: stop cluster, перезапустите его: start cluster с опцией --initial, которая заставляет очистить файловые системы узлов данных. Обратите внимание на то, что для MySQL NDB Cluster 7.5 и ранее дисковые файлы данных должны быть удалены вручную. После этого можно восстановить кластер от желаемой резервной копии через restore cluster.

Чтобы восстановить резервную копию с использованием restore cluster, у кластера должен быть неиспользуемый слот для процесса ndbapi. Иначе команда терпит неудачу с ошибкой Unable to perform restore - no vacant ndbapi slots in config for cluster cluster_name. См. здесь.

Дополнительные опции, которые могут использоваться с этой командой, включают:

--disable-indexes и --disable-metadata. Чтобы заставить индексы быть проигнорированными, восстанавливая данные таблиц, используйте опцию --disable-indexes (краткая форма: -x, только MySQL Cluster Manager 1.4.7 и ранее ). Выполнение этого может уменьшить время, требуемое, чтобы восстановить большой набор данных, особенно там, где много индексов использовалось. Точно так же можно заставить метаданные быть проигнорированными во время процесса восстановления при помощи опции --disable-metadata (краткая форма: -M).

--epoch. При использовании опции --epoch (краткая форма: -e) информация об эпохе восстанавливается в таблице состояния репликации кластера (mysql.ndb_apply_status), что может быть полезно для точных копий в репликации MySQL NDB Cluster.

--exclude-databases и --exclude-tables. Препятствует тому, чтобы одна или более баз данных или таблиц были восстановлены, используя параметры --exclude-databases и --exclude-tables. --exclude-databases принимает разграниченный запятой список из одной или более баз данных, которые не должны быть восстановлены. --exclude-tables принимает разграниченный запятой список из одной или более таблиц (в формате database. table), которые не должны быть восстановлены. При использовании --exclude-databases или --exclude-tables только базы данных или таблицы, названные опцией, исключены, все другие базы данных и таблицы восстановлены.

--exclude-missing-columns. При использовании этой опции restore cluster игнорирует любые колонки, отсутствующие в восстанавливаемых таблицах, по сравнению с версиями тех таблиц, найденных в резервной копии.

--exclude-missing-tables. При использовании этой опции restore cluster игнорирует любые таблицы из резервной копии, которые не найдены в целевой базе данных.

--exclude-intermediate-sql-tables[=TRUE|FALSE] . При выполнении ALTER TABLE mysqld составляет промежуточные таблицы (чьи имена имеют префикс #sql-). Когда TRUE, опция --exclude-intermediate-sql-tables не дает restore cluster восстановить такие таблиц, которые, возможно, были перенесены от таких операций. Эта опция по умолчанию TRUE.

--include-databases и --include-tables. Применение опции --include-databases или --include-tables нужно для восстановления только определенных баз данных или таблиц, соответственно. --include-databases берет разграниченный запятой список баз данных, которые будут восстановлены. --include-tables берет разграниченный запятой список таблиц (в формате database.table для восстановления. При использовании --include-databases или --include-tables восстановлены только базы данных или таблицы, названные опцией, все другие базы данных и таблицы исключены из restore cluster и не восстановлены.

--include-stored-grants. При работе с NDB Cluster 8.0.19 и позже restore cluster по умолчанию не восстанавливает разделенных пользователей и права доступа в таблице mysql.ndb_sql_metadata, используйте опцию --include-stored-grants (доступную только в MySQL Cluster Manager 1.4.8 и позже), чтобы отвергнуть это поведение и позволить восстановить эти данных.

--lossy-conversions. Использование --lossy-conversions позволяет преобразования с потерями значений столбцов, восстанавливая данные из резервной копии. За некоторыми исключениями правила совпадают с правилами для репликации MySQL, см. здесь. restore cluster сообщает о любом усечении данных, которые это выполняет во время преобразований с потерями один раз на признак и колонку.

--no-binlog. Опция --no-binlog (краткая форма: -l) защищает любые узлы SQL (процессы mysqld) в кластере от написания данных из резервной копии в их двоичные журналы.

--no-restore-disk-objects. Опция не дает restore cluster восстановить любые объекты MySQL NDB Cluster Disk Data, например, табличные пространства и группы файлов журнала, см. здесь.

--parallelism= #. Опция --parallelism (краткая форма: -p) определяет максимальное число параллельных транзакций, используемых restore cluster. По умолчанию 128, максимум 1024, минимум 1.

--privilege-tables. Опция --privilege-tables (краткая форма: -P) восстанавливает таблицы для распределенных прав доступа (см. здесь).

--progress-frequency=N. Напечатать отчет о состоянии каждые N секунд во временный файл stdout mcm, созданный как mcm_data/clusters/ cluster_name/nodeid /tmp, в то время, как резервная копия происходит. 0 (по умолчанию) = не печатать. Максимум 65535.

--promote-attributes. Позволить раскрутку признаков, когда MySQL Cluster Manager восстановит данные из резервной копии. Посмотрите подробности здесь for.

--rewrite-database= old_dbname,new_dbname . Эта опция предписывает восстановить базу данных с именем old_dbname в резервной копии под новым именем new_dbname.

--skip-nodeid. Опция --skip-nodeid (краткая форма: -s) берет список разделенных запятой значений ID узла. Узлы, ID которых перечисляются, могут включать узлы данных, SQL или обоих типов. Узлы, имеющие эти ID, пропускаются процессом восстановления.

--skip-broken-objects. Проигнорировать поврежденные таблицы, читая резервную копию, и продолжить восстанавливать любые остающиеся таблицы (которые не испорчены). В настоящее время --skip-broken-objects работает только в случае недостающих частей blob таблицы.

--skip-table-check. Возможно восстановить данные, не восстанавливая метаданные таблицы. Поведение по умолчанию restore cluster: потерпеть неудачу с ошибкой, если данные о таблице не соответствуют схеме таблицы, это может быть отвергнуто, используя опцию --skip-table-check.

--skip-unknown-objects. Проигнорировать любые непонятные объекты схемы, читая резервную копию. Это может использоваться для восстановления, например, резервной копии, сделанная из более новой версии MySQL NDB Cluster.

4.7.5. Команда backup agents

backup agents [--hosts=host_list] [site_name]
              host_list: host[, host[, ...]]

Эта команда сохраняет данные конфигурации для агентов mcmd на хостах, определенных в host_list опцией --hosts (краткая форма: -h) для места site_name. Если никакие имена хоста не определяются, все агенты места сохраняются. Если нет site_name, резервируется только агент, с которым связан mcm.

Резервная копия для каждого агента создается в подкаталоге rep_backup/timestamp под хранилищем агента (mcm_data ), где timestamp отражая время, когда резервная копия началась. Если вы хотите, чтобы резервная копия была в другом месте, создайте мягкую ссылку из mcm_data/rep_backup.

MySQL Cluster Manager 1.4.2 и позже : Пустой файл с именем INCOMPLETE создается в каталоге, в котором создается резервная копия, когда резервная копия начинается, и удален после того, как резервная копия закончена. Непрерывное существование файла после окончания процесса резервного копирования указывает, что резервная копия неполная.

Заметьте, что backup agents работает по-другому по сравнению с backup cluster, которая поддерживает данные кластера, backup agents поддерживает данные конфигурации агента. Используя вместе резервные копии, созданные обеими командами, можно восстановить не только кластер, но и полную установку кластера плюс менеджер. Дополнительную информацию см. в разделе 3.7.

4.8. Команды импорта MySQL Cluster Manager Cluster

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

4.8.1. Команда import cluster

import cluster [--dryrun|-y] [--remove-angel] cluster_name

Эта команда импортирует кластер MySQL NDB, созданный вне MySQL Cluster Manager, в кластер cluster_name , созданный в MySQL Cluster Manager. Вам настоятельно рекомендуют создать cluster_name с помощью create cluster с опцией --import.

import cluster требует отдельного аргумента, названия кластера, созданного, используя MySQL Cluster Manager (cluster_name), в который вы хотите импортировать кластер MySQL NDB, созданный вне MySQL Cluster Manager. Кластер, названный в команде, должен уже существовать в MySQL Cluster Manager.

import cluster понимает опцию --dryrun. Когда эта опция используется, только проверки, требуемые для импорта, выполнены. Это позволяет проверить данную конфигурацию, на самом деле не помещая процессов кластера под контроль MCM. -y это краткая форма опции.

MySQL Cluster Manager 1.4.7 и позже, import cluster понимает опцию --remove-angel. Когда эта опция используется, любые работающие процессы ангела для узлов данных импортируемого кластера будут остановлены mcmd до фактического импорта, что является необходимым шагом для импорта, если процессы ангела не были уже остановлены вручную. Когда эта опция используется вместе с --dryrun, никакие удаления процессов ангела не будут на самом деле выполнены, но проверки на процессы ангела (которые происходят, когда используется опция --dryrun) будет пропущены. Рекомендуется, чтобы вы использовали эти две опции отдельно: выполните проверки с --dryrun, определите наблюдаемые ошибки с процессами ангела, выполните import cluster снова только с опцией --remove-angel и посмотрите, что получится.

4.8.2. Команда import config

import config [--dryrun|-y] cluster_name

Эта команда импортирует конфигурацию автономного кластера в кластер cluster_name.

import config требует отдельного аргумента, cluster_name, который является названием кластера, созданного, используя MySQL Cluster Manager, в который вы хотите импортировать конфигурацию MySQL NDB Cluster. Кластер, названный в команде, должен уже существовать в MySQL Cluster Manager, вам также настоятельно рекомендуют использовать create cluster --import для создания cluster_name .

import config также понимает опцию --dryrun (краткая форма: -y). Когда эта опция используется, проверки, требуемые для импортирования данных конфигурации, выполнены, и команды set для выполнения фактического импорта написаны в файл / path-to-mcm-data-repository/clusters/ clustername /tmp/import_config.message_id .mcm для вашей экспертизы. Это позволяет проверить импорт конфигурации, на самом деле не копируя ни один из параметров настройки в кластер, которым управляет MySQL Cluster Manager. Можно тогда импортировать все параметры настройки, используя import config (без опции --dryrun), или отрегулировать некоторые параметры настройки в файле / path-to-mcm-data-repository/clusters/ clustername /tmp/import_config.message_id .mcm, а затем импортировать параметры настройки, выполняя файл с помощью агента mcm, см. раздел 3.5.2.3.

Когда импортируются параметры конфигурации для узла mysqld, если относительный путь используется для socket или для любого директивного значения (например, plugin_dir), импорт будет отклонен клиентом mcm. Удостоверьтесь, что абсолютный путь используется и при необходимости внесите изменения в атрибуты в файле .mcm, созданном командой import config --dryrun, затем импортируйте параметры настройки, выполнив файл с помощью клиента mcm.