Секции в этой главе описывают команды, используемые в 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 состоит из любой последовательности знаков из числа следующего:
Буквы от a
до
z
и от
A
до Z
.
Цифры от 0
до
9
.
Тире (-
), точка
(.
) и подчеркивание
(_
).
Идентификатор MySQL Cluster Manager должен начинаться с буквы или цифры.
Чувствительность к регистру для команд клиента. Правила для чувствительности к регистру идентификаторов MySQL Cluster Manager, команд, вариантов команд, имен процессов и признаков конфигурации следующие:
Идентификаторы чувствительные к
регистру. Например,
delete
site mycluster
не может использоваться, чтобы удалить место
myCluster
.
Ключевые слова команды и длинные формы
вариантов команды нечувствительны к регистру.
Например, любая из трех команд
delete cluster mycluster
,
DELETE CLUSTER mycluster
и
DeLeTe cLuStEr mycluster
работает, чтобы удалить экземпляр MySQL NDB Cluster
mycluster
.
В этом руководстве мы показываем ключевые слова команды и длинные формы вариантов команды в строчных буквах, но вы не обязаны следовать этому соглашению, если вы не хотите делать так.
Краткие формы вариантов команды
чувствительны к регистру. Например,
-b
(строчные буквы) это краткая форма
опции --basedir
, но
-B
(верхний регистр) это краткая форма
опции
--background
.
Названия процессов MySQL NDB Cluster
нечувствительны к регистру. Например, любая из команд
get --include-defaults
DataMemory:ndbd mycluster
или get
--include-defaults datamemory:NDBD mycluster
сообщает о памяти данных,
ассигнованной для каждого процесса
ndbd в
кластере mycluster
.
В этом руководстве мы показываем названия процессов группы MySQL NDB в строчных буквах. Вы не обязаны следовать этому соглашению, если вы не хотите делать так, однако, так как соответствующие исполняемые файлы называются и их нужно вызывать в строчных буквах, мы предлагаем, чтобы вы использовали строчные буквы.
Названия атрибута конфигурации
нечувствительны к регистру. Например, любая из команд
get --include-defaults
DataMemory:ndbd mycluster
или get
--include-defaults datamemory:ndbd mycluster
вернет память данных,
ассигнованную для каждого процесса
ndbd
в кластере mycluster
, любая из команд
set
engine-condition-pushdown:mysqld:4=0 mycluster
или
set Engine-Condition-Pushdown:mysqld:4=0
mycluster
отключает условие pushdown-оптимизации в процессе
mysqld,
имеющем ID узла 4
в кластере MySQL NDB Cluster
mycluster
.
Признаки конфигурации в MySQL Cluster Manager происходят из двух
источников: параметры кластерной конфигурации MySQL NDB и опции MySQL
Server. Параметры настройки MySQL NDB Cluster нечувствительны к регистру, но
их канонические формы используют верхний регистр Camel-регистр (то есть,
средняя капитализация включая первые буквы).
Это означает, что устанавливая значение для памяти данных, используя
MySQL Cluster Manager или файл config.ini
,
можно обратиться к нему как к DataMemory
,
datamemory
или
dATAmEMORY
. Но опции MySQL Server
чувствительны к регистру и используют только строчные буквы. Это означает,
что, например, set
Engine-Condition-Pushdown:mysqld:4=0 mycluster
в MySQL Cluster
Manager работает, чтобы отключить условие pushdown в обозначенном процессе
mysqld,
но если вы вызываете исполняемый файл
mysqld из
командной строки, используя
--Engine-Condition-Pushdown=0
,
mysqld
не начинается.
В этом руководстве мы показываем названия атрибута конфигурации с
использованием того же самого регистра, что и в другой документации MySQL,
таким образом мы всегда обращаемся к
DataMemory
, а не к
datamemory
или
DATAMEMORY
и к
engine-condition-pushdown
вместо
Engine-Condition-Pushdown
или
ENGINE-CONDITION-PUSHDOWN
.
В то время, как вы не обязаны делать это, используя 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, состоит из одного из следующего:
Единственная строка, которая содержит сообщение, указывающее
на результат команды.
create site
в последнем примере возвратила
результат Site created successfully
,
чтобы сообщить пользователю, что команда имела успех.
Одну или более строк, перечисляющих нужные объекты или свойства.
Пример такой команды:
list processes
:
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)
В случае
list processes
каждая строка в результате содержит ID и тип узла в
кластере MySQL NDB Cluster mycluster
вместе с именем хоста на котором работает процесс.
Пустой набор результатов. Это может произойти с одной из команд
list
, когда нет ничего, чтобы сообщить,
например, когда
list sites
используется прежде, чем любые
места были созданы:
mcm> list sites;
Empty set (0.72 sec)
Каждая команда должна быть введена отдельно, невозможно объединить многократные команды на одной строке.
Варианты, характерные для команд клиента. Следующие три варианта характерны для большей части команд клиента MySQL Cluster Manager:
--help
(краткая форма:
-?
):
Характерна для всех команд клиента. Обеспечивает помощь для данной команды.
Посмотрите раздел
4.1.
--force
(краткая форма
-f
):
Отключает любые проверки безопасности, которые будут обойдены, выполняя
команду. Например,
delete cluster
терпит неудачу, если какой-либо процесс MySQL NDB Cluster в кластере MySQL
NDB mycluster
mycluster
работает, однако,
delete cluster --force
вызывает закрытие
mycluster
mycluster
, сопровождаемое удалением
mycluster
из инвентаря
MySQL Cluster Manager.
--force
поддерживается для следующих команд MySQL Cluster Manager:
--background
(краткая форма
-B
): Вместо того, чтобы ждать окончания исполнения команды, MySQL
Cluster Manager немедленно возвращает командную строку, позволяя вам
выполнить дополнительные задачи в клиенте в то время, как та команда
продолжает выполняться в фоновом режиме. Это может быть полезно, выполняя
команды, которые могли бы потребовать некоторое время
(такие, как старт кластера с очень многими узлами).
Этот выбор поддерживается всеми командами клиента за исключением
create site
,
delete site
,
add hosts
,
add package
и
delete package
.
Помощь онлайн доступна в 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
.
В этой секции мы обсуждаем команды, используемые, чтобы работать с
MySQL Cluster Manager. Кроме того, есть команды
stop agents
,
show settings
,
version
и
show warnings
, которые
касаются агентов управления.
Место с точки зрения MySQL NDB Cluster и MySQL Cluster Manager является коллекцией из одного или более компьютеров, где работают агенты MySQL Cluster Manager. Каждый агент опознается комбинацией двух сведений:
Имя хоста или IP-адрес машины, где агент работает.
Номер порта, используется агентом для коммуникаций.
MySQL NDB Cluster делает чрезвычайно интенсивное использование сетевых соединений, и поиски DNS могут конфликтовать с MySQL NDB Cluster и MySQL Cluster Manager по пропускной способности, приводя к негативному воздействию на производительность MySQL NDB Cluster. Поэтому мы рекомендуем, чтобы вы использовали числовые IP-адреса, а не имена хоста для хостов MySQL NDB Cluster и MySQL Cluster Manager.
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-адресом.
Эта команда не поддерживает опцию
--force
.
Не следует использовать localhost
в списке хостов, поскольку MySQL Cluster Manager
полагается на операционную систему для резолюции имени хоста, и
localhost
мог бы быть разрешен по-другому на
различных системах. Используйте надлежащие имена хоста для списка хоста или,
предпочтительно, используйте IP-адреса для хостов вместо этого.
Когда IPv6-системы Windows используются в качестве хостов MySQL NDB Cluster под MySQL Cluster Manager, необходимо сослаться на эти хосты, используя адреса IPv4. Иначе MySQL Cluster Manager будет неспособен соединиться с процессами агента на тех хостах. Посмотрите раздел 5.1.
remove hosts
remove hosts {--hosts=|-h }host_list
site_name
host_list
:host
[,host
[, ...]]
Эта команда удаляет один или более
хостов из существующего места управления. Это принимает как аргумент
необходимую опцию
--hosts
(краткая форма
-h
), чье значение это список разделенных запятой значений одного или более
хостов, которые будут удалены, и название места, из которого должны быть
удалены хосты. Много ограничений применяются:
Имя хоста, который будет удален, не должно быть
localhost
или
127.0.0.1
.
У хоста, который будет удален, не должно быть управляемых процессов ни
от каких групп, назначенных на них (удалите те процессы сначала командой
remove process
), хотя можно назначить
неуправляемые процессы на них (как правило,
ndbapi@hostname
mysqld@*hostname
).
Не должно быть никаких пакетов, определенных с явными путями, указывающими на удаляемые хосты.
Кворум из большинства хостов (то есть, половина общего количества хостов
плюс один) должен существовать для места прежде и после удаления хоста или не
будет возможно выполнить remove host
.
Вы не можете удалить последний хост из места, используйте
delete site
.
Следующая команда удаляет два хоста
tonfisk
и flundra
с места управления mysite
:
mcm> remove hosts --hosts=tonfisk,flundra mysite;
+----------------------------+
| Command result |
+----------------------------+
| Hosts removed successfully |
+----------------------------+
1 row in set (0.48 sec)
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
. См. подробности
здесь.
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;
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
,
только файлы журнала агента собраны.
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
.
Применение localhost
как аргумента в
опции
--hosts
приведет к созданию сайта из единственного хоста
(состоящего из хоста, на котором выполнили команду), который не может быть
расширен позже командой
add hosts
. Также заметьте, что вы не можете
смешать localhost
с другими именами в списке
хостов. Поэтому рекомендуется, чтобы вы использовали IP-адреса (но не любые
адреса, принадлежащие подсети localhost
127.*.*.*) или надлежащие имена хостов в списке.
Когда IPv6-системы Windows используются в качестве хостов MySQL NDB Cluster под MySQL Cluster Manager, необходимо сослаться на эти хосты, используя адреса IPv4. Иначе MySQL Cluster Manager не будет способен соединиться с процессами агента на тех хостах. Посмотрите раздел 5.1.
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.
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
содержит следующие колонки:
Site
. Название места.
Port
. Порт TCP/IP, используемый
для связей между клиентами и агентами управления.
Local
.
Local
или
Remote
.
Hosts
.
Список разделенных запятой значений хостов, составляющих место.
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
может быть:
Available
:
Агент на хосте активен.
Recovery
:
Агент на хосте находится в процессе восстановления
(MySQL Cluster Manager 1.4.7 и позже).
Unresponsive
:
Агент на хосте отклонил попытку соединиться
(MySQL Cluster Manager 1.4.7 и позже).
Unavailable
:
Агент на хосте недостижим.
Если об агенте постоянно сообщают как
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)
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)
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.
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
не берет аргументов.
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 | +---------+------+-----------------------------------------------------------------------+
Эта секция содержит информацию о командах клиента MySQL Cluster Manager для регистрации, расширения, отмены и получения информации о пакетах программного обеспечения, составляющих экземпляры MySQL NDB Cluster, которыми нужно управлять, используя MySQL Cluster Manager.
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).
Вы не можете скомандовать add package
,
если вы еще не определили мест (каждый хост в команде
add package
должен быть связан с местом).
Посмотрите раздел 4.2.6.
Когда пакет сначала добавляется для места с
add package
, каждый раз, когда используется
опция
--hosts
, список хостов должен содержать хост для агента
mcmd
, с которым в настоящее время связывается клиент
mcm, чтобы позволить MySQL Cluster Manager
получать доступ к информации о версии пакета.
Предположим, что у нас есть два хоста 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)
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
со ссылкой на незарегистрированный пакет
также потерпит неудачу.
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
на обеих машинах.
Вывод содержит три колонки, они описаны в следующем списке:
Package
.
Название пакета. Это может иногда быть пусто, когда пакет включает установки
MySQL NDB Cluster, которые находятся в различных местоположениях на различных
хостах (см. следующий пример).
Path
.
Путь к инсталляционному каталогу MySQL NDB Cluster
на обозначенном хосте или хостах. Это совпадает со значением для
опции --basedir
команды
add package
, которая использовалась, чтобы
создать или обновить пакет.
В Windowsв путях, показанных в этой колонке, есть знаки наклонной черты
влево, преобразованные в наклонные черты вправо, как должно быть сделано для
опции --basedir
.
Hosts
.
Хост или хосты, где расположена установка MySQL NDB Cluster.
Можно отфильтровать результаты так, чтобы информация, касающаяся только единственного пакета, была показана, поставляя имя пакета перед названием места, как показано здесь:
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
Эта секция содержит описания команд MySQL Cluster Manager, которые выполняют операции на кластерх. Они включают создание и удаление кластеров, старт, остановку, перезапуск и модернизацию кластера (то есть, модернизацию программного обеспечения MySQL NDB Cluster, используемого данным кластером).
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
требует следующих аргументов:
package_name
,
поставляемый как значение опции
--package
(краткая форма:
-P
). Это должно быть названием пакета, ранее
зарегистрированного использованием
add package
.
Список (process_host_list
)
процессов MySQL NDB Cluster, хостов, на которых они должны работать, и
произвольно ID их узлов, поставляемые как значение опции
--processhosts
(краткая форма:
-R
), с пунктами списка, отделенными запятыми.
Как с другими списками, переданными как опция, значения в командах MySQL
Cluster Manager, не должны использовать пробелы прежде или после запятых.
Каждый пункт в process_host_list
состоит из названия процесса MySQL NDB Cluster возможно с двоеточием
(:
), сопровождаемый ID узла процесса, к которому
присоединяются с именем хоста, на котором это расположено, используя знак
@
. Разрешенные значения для процессов:
ndb_mgmd
, ndbd
и
mysqld
. Когда кластер использует MySQL
NDB Cluster 7.0 или позже, можно также использовать
ndbmtd
как имя, другими словами, действительное
имя процесса это название двоичного модуля демона MySQL NDB Cluster.
Если ID узла определяются, он должен быть в позволенном диапазоне для
определенного типа узла.
Чтобы поддержать управление вашими собственными приложениями API NDB с
кластером под MySQL Cluster Manager, также возможно использовать
ndbapi
как тип процесса. Такие запросы могут
быть связаны с управляемым кластером. В настоящее время MySQL Cluster Manager
признает только, что приложение NDB API связано с кластером, само приложение
API NDB должно запускаться, останавливаться и формироваться вручную.
Также возможно определить один или несколько
свободных процессов
mysqld
и ndbapi
без любых хостов. Чтобы сделать это, просто используйте подстановочный знак
*
(звездочка) вместо имени хоста или IP-адреса,
как показано ниже:
Свободный процесс
mysqld
: mysqld@*
Свободный процесс
ndbapi
: ndbapi@*
Также возможно определить ID узла для свободного процесса. Если это не определяется, MySQL Cluster Manager назначает подходящий ID узла автоматически.
Процессу mysqld
или
ndbapi
, который определяется без хоста этим
способом, разрешают соединиться с группой от любого хоста, который может
получить доступ к кластеру по сети. Иначе процесс может соединиться с
кластером только от указанного хоста.
В соответствии с соглашением, пункты в
process_host_list
перечисляются согласно типу процесса в следующем порядке:
Процессы узла управления
(ndb_mgmd
).
Процессы узла данных (MySQL NDB Cluster
6.3: ndbd
,
MySQL NDB Cluster 7.0 и позже:
ndbd
, ndbmtd
).
Процессы узла SQL (mysqld
).
Приложения NDB API (ndbapi
).
Для получения информации о написании ваших собственных приложений API NDB посмотрите The NDB API.
В то время как порядок, в котором перечисляются пункты, не затрагивает
результативность команды create cluster
,
мы предлагаем, чтобы вы следовали этому соглашению для удобочитаемости, а
также совместимости с другими инструментами управления MySQL NDB Cluster,
например ndb_mgm.
create cluster
применяет
ID узла, которые будут назначены последовательно в порядке, в котором
узлы определяются в process_host_list
, ID для процессов узла данных, начинаются с 1, ID для процессов кроме
процессов узла данных, начинаются с 49. MySQL Cluster Manager 1.3.3 и ранее:
пытаясь вручную назначить узлу ID меньше, чем 49 для
ndb_mgmd
,
mysqld
или ndbapi
,
получите ошибку, ограничение, однако, было полностью снято для MySQL Cluster
Manager 1.3.4 и позже. Тем не менее, вам все еще рекомендуют применить
наиболее успешную практику сохранения ID узла от 1 до 48 для узлов данных.
NDB 8.0 поддерживает до 144 узлов данных (для выпуска 8.0.18 и позже).
Поэтому create cluster
назначает ID
для процессов узла данных, начиная с 1, а ID для процессов кроме процессов
узла данных, начиная с 145. Вручную назначая узлу ID для группы NDB 8.0, вам
рекомендуют применить наиболее успешную практику сохранения ID узла от 1 до
144 для узлов данных.
Каждый хост, на который ссылаются в списке, должен быть частью места, для
которого пакет используется в определении create
cluster
.
Для процессов типов mysqld
и
ndbapi
имя хоста требуется, но не проводится в
жизнь в работающем кластере. Другими словами, раздел
[api]
создается в кластерном файле
config.ini
, но параметр не определяется
HostName
, таким образом,
mysqld
или ndbapi
может соединиться от любого хоста. В настоящее время нет никакого способа
использовать MySQL Cluster Manager, чтобы определить, что процесс
mysqld
или ndbapi
ограничивается соединением от единственного хоста.
Название кластера. Как только кластер был создан, это имя
используется, чтобы отослать к нему в других командах управления, например,
в delete
cluster
,
start cluster
и
stop cluster
.
Как другие имена объектов, используемые с MySQL Cluster Manager,
cluster_name
должно быть
действительным согласно правилам, данным в другом месте в этом документе для
идентификаторов (см. главу 4).
Дополнительная опция
--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.
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
.
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
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)
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 по выполнению системных перезапусков кластера. Это означает, что атрибуты, которые требуют для изменения начального перезапуска, должны быть установлены прежде, чем кластер впервые запущен.
show status
show status --cluster|-ccluster_name
show status --operation|-ocluster_name
show status --backup|-bcluster_name
show status --process|-rcluster_name
show status --progresscluster_name
show status --progressbarcluster_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 колонки:
Command
.
Текст команды (до show status
)
без любых опций или аргументов.--operation
Status
. Текущее состояние команды.
Возможные значения перечисляются позже в этой секции.
Description
. В некоторых ситуациях
в зависимости от команды и ее статуса эта колонка может содержать
дополнительную информацию. Иначе здесь будет
<no message>
.
Возможные значения столбца 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 колонок, описанных в следующем списке:
Id
. Это ID узла процесса как
узла в кластере cluster_name
.
Process
. Тип процесса, то есть,
название соответствующего исполняемого файла кластера MySQL NDB. Позволенные
значения: ndb_mgmd
, ndbd
, ndbmtd
и
mysqld
.
Host
. Имя хоста или IP-адрес
компьютера, где процесс работает.
Status
.
Статус или условие этого процесса. Возможные значения для этой колонки
даны позже в этой секции.
Nodegroup
.
Если Process
=
ndbd
или ndbmtd
то есть, если процесс это процесс узла данных, тогда эта колонка показывает
ID узла, которому принадлежит процесс. Для любого другого значения
value of Process
эта колонка пуста.
Возможные значения для столбца 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
.
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
) вызывает следующее:
Все узлы данных кластера начаты, как будто
start process
--initial
использовался на них, что означает, что все узлы данных стирают
свои данные и начинаются с чистыми файловыми системами узла данных. Таблицы
NDB
, которые были ранее
сохранены в кластере, потеряны.
MySQL Cluster Manager 1.4.3 и позже:
Все узлы SQL начаты, как будто
start process
--initial
использовались на них, что
означает, что MySQL Cluster Manager восстанавливает каталог данных
mysqld с
mysqld
--initialize-insecure
для MySQL
5.7 и с mysql_install_db
для MySQL 5.6. Однако, каталог данных узла должен быть пустым, или
реинициализация не будет предпринята.
Чтобы пропустить реинициализацию для любых узлов SQL, перечислите их ID
процесса (отделенные запятыми, если есть больше одного), используя опцию
--skip-init
=
process_id_list
:
mcm> start cluster --initial --skip-init=50,51 mycluster;
Опция
--skip-init
принимает только ID узлов SQL
как аргумент, это не может использоваться, чтобы пропустить
инициализацию узлов данных.
При нормальных обстоятельствах необходимо использовать эту опцию,
чтобы запустить кластер только, когда вы не хотите сохранять любые данные
(и хотеть сделать чистый запуск) или вы намереваетесь восстановить кластер из
резервной копии до известного хорошего состояния (см.
раздел 4.7.4).
Необходимо также знать, что никакие специальные предупреждения не печатаются
клиентом
mcm, когда используется
--initial
с
start cluster
, команда немедленно выполняется.
Для получения информации о создании резервных копий кластера посмотрите
раздел 4.7.2.
Если необходимо знать, какие резервные копии доступны (если таковые имеются),
надо использовать
list backups
.
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.
autotune
autotune [--dryrun] [--sequential-restart] [--writeload=writeload
]template
cluster_name
writeload
: {low|medium|high}template
: {web|realtime|test}
Команда настраивает много параметров для кластера, согласно указанным
значениям для аргумента template
и возможно
опции writeload
, чтобы
оптимизировать работу кластера.
web
:
Максимизируйте производительность для данных аппаратных средств.
realtime
:
Максимизируйте производительность, максимизируя чувствительность к
тайм-аутам, чтобы минимизировать время, нужное для обнаружения
упавших процессов кластера.
test
: Минимальное использование ресурсов
для небольшого тестирования. Не предназначено для производственных сред.
Допустимые значения для
--writeload
:
low
:
Ожидаемая нагрузка включает меньше 100 транзакций записи в секунду.
medium
: Ожидаемая нагрузка включает от
100 до 1000 транзакций записи в секунду. Это значение по умолчанию,
используемое когда не задана
--writeload
.
high
:
Ожидаемая нагрузка включает свыше 1000 транзакций записи в секунду.
Кластер должен быть в
статусе 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 и позже.
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
). Кластер, созданный для импорта, не может быть модернизирован, пока
импорт не был закончен. Посмотрите разделы
4.4.1 и
раздел 3.5.cluster_name
Предположим, что 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 поддерживаются командой. Нужно соответствовать трем критериям:
Модернизация должна быть поддержана включенными версиями MySQL NDB Cluster. Посмотрите следующие разделы в руководствах MySQL NDB Cluster для списков позволенных модернизаций:
MySQL NDB Cluster 7.3 и 7.4: см. Upgrading and Downgrading NDB Cluster.
MySQL NDB Cluster 7.5 и 7.6: см. Upgrading and Downgrading NDB Cluster.
Версии, которые вы модернизируете, должны быть поддержаны версией MySQL Cluster Manager (например, модернизация от MySQL NDB Cluster 6.3 до 7.5 должна быть выполнена вручную, потому что MySQL Cluster Manager больше не поддерживает MySQL NDB Cluster 6.3).
Используя команду
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
, так как команда может привести к частичной модернизации.
Используйте это только когда предыдущая попытка модернизировать кластер
провалилась и только с руководством от надлежащего персонала поддержки.
Эта секция покрывает команды, используемые в MySQL Cluster Manager, чтобы получить и установить значения различных типов, используемые в кластерной конфигурации MySQL NDB Cluster. Мы начинаем с обсуждения того, что мы подразумеваем под признаком конфигурации и как это касается ручной конфигурации MySQL NDB Cluster через параметры MySQL NDB Cluster, а также связанные опции и переменные MySQL Server.
Атрибуты конфигурации. Традиционно, управляя MySQL NDB Cluster, было необходимо различать 3 типа данных конфигурации:
Параметры конфигурации в
глобальном конфигурационном файле MySQL NDB Cluster, прочитанном сервером
управления (или серверами), в соответствии с соглашением, называемом
config.ini
.
Переменные конфигурации, заданные
в работающем сервере MySQL (узел SQL) при помощи SQL-запроса
SET
в клиенте
mysql
(или в другом клиентском приложении MySQL).
Параметры конфигурации переданные к исполняемым программам MySQL NDB Cluster, вызывая их.
Параметры конфигурации, переданные mysqld, часто имеют эффект установки значений для переменных конфигурации, многие, но не все из которых могут быть отвергнуты в работающем сервере MySQL.
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 может выполнить эту операцию
автоматически так, чтобы изменение конфигурации вступило в силу без
дальнейшего вмешательства со стороны оператора.
Уровни признака конфигурации. Значение атрибута конфигурации применяется на одном из этих трех уровней, описанных здесь:
Default: Это значение всегда используется любым процессом MySQL NDB Cluster типа или типов (таких как ndbd или mysqld), к которому применяется признак, если это значение не отвергнуто пользователем.
Process: Это значение используется для всех экземпляров данного типа процесса MySQL NDB Cluster.
Instance: Это значение используется для определенного экземпляра процесса MySQL NDB Cluster, определяемого его ID узла MySQL NDB Cluster.
Значения по умолчанию жестко закодированы в MySQL NDB Cluster,
можно отвергнуть значение по умолчанию для данного признака конфигурации
(используя команду set
) или сбросить данное значение атрибута к его значению по
умолчанию (используя
reset
), но вы не можете изменить само значение по умолчанию.
Можно установить или перезагрузить значение признака конфигурации на уровне
процесса или на уровне экземпляра, используя
set
или
reset
.
Как только вы установили или перезагрузили значение признака конфигурации,
это значение сохраняется, пока это не изменяется командой
set
или reset
.
Устанавливая или перезагружая значение атрибута конфигурации, необходимо определить уровень, на котором оно применяется.
MySQL Cluster Manager определяет, какое значение использовать для признака конфигурации, касающегося данного процесса, выполняя эти шаги для каждого процесса MySQL NDB Cluster:
Для каждого признака конфигурации:
Значение атрибута определяется для ID узла этого процесса?
Да: Используйте значение, которое было определено для ID этого узла.
Нет: Продолжите двигаться к следующему шагу.
Значение атрибута определяется на уровне процесса то есть, для всех процессов этого типа?
Да: Используйте значение, которое было определено для всех процессов этого типа.
Нет: Используйте значение по умолчанию, которое относится к процессам этого типа.
Последнее указанное значение имеет приоритет. Это означает, что если вы устанавливаете признак конфигурации для определенного процесса, а позже определите значение уровня процесса для этого признака, значение уровня процесса используется для всех процессов того типа, включая случай, для которого вы ранее устанавливаете определенное для экземпляра значение.
Обязательные атрибуты. Некоторые атрибуты должны быть определены в 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
:
Для ndb_mgmd:
--core-file
,
--log-name
,
--verbose
Для ndbd и
ndbmtd:
--core-file
,
--verbose
Эти атрибуты, поддержанные командами
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)
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. Вывод включает следующие колонки:
Name
:
Эта колонка содержит название признака конфигурации.
Value
:
Эта колонка показывает текущее значение признака.
Process1
:
Эта колонка держит тип процесса, к которому применяется признак.
Это одно из ndb_mgmd
,
ndbd
, ndbmtd
(MySQL NDB Cluster 7.0 и позже) или mysqld
.
Id1
:
ID процесса, к которому применяется признак.
Process2
:
Для признаков, которые требуют определения двух узлов, таких как те, которые
касаются связей TCP/IP, эта колонка показывает тип
процесса второго узла.
Id2
: Для признаков, которые требуют
определения двух узлов, эта колонка показывает ID процесса
для второго узла.
Level
: Это уровень процесса признака.
Значение в этой колонке может быть
Default
, Process
или пустым, эта колонка пуста, это означает, что признак применяется
на уровне экземпляра.
Comment
:
Эта колонка используется, чтобы показать, является ли признак
Mandatory
,
Read only
, Default
или определяется пользователем (в этом случае столбец
Comment
пустой).
По умолчанию 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)
Также возможно получить список признаков и их значений для данного типа
процесса или экземпляра процесса. Для данного типа процесса используйте
фильтр, имеющий форму
:
. Например, чтобы получить все атрибуты не по
умолчанию, относящиеся к процессам
ndbd в
кластере process_name
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)
Пример предполагает, что никакие атрибуты не установлены в значения не по умолчанию.
Чтобы получить список всех признаков не по умолчанию для единственного
экземпляра процесса, используйте фильтр, имеющий форму
:
,
как показано в этом примере, который получает все атрибуты не по
умолчанию для процесса
ndbd,
где ID процесса process_name
:process_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
.
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
, если они не были явно
установлены пользователем.
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.
Эта секция содержит информацию о командах клиента MySQL Cluster Manager, которые начинают и останавливают процессы MySQL NDB Cluster, а также определяют, какие процессы в настоящее время работают.
MySQL Cluster Manager, ndb_mgm и старт или остановка процессов. Для управления MySQL NDB Cluster из MySQL Cluster Manager рекомендуется не применять клиент ndb_mgm, который идет в дистрибутиве MySQL NDB Cluster, чтобы выполнить операции, которые включают старт или остановку узлов. Они включают, но не ограничиваются следующими командами клиента:
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.
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
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
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
) происходит следующее:
Для процесса узла данных MySQL Cluster Manager
запускает его с опцией
--initial
, заставляя узел
данных пересоздать его файловую систему.
Для процесса узла SQL (только для MySQL Cluster Manager 1.4.2 и позже)
MySQL Cluster Manager пересоздает каталог данных
mysqld
с опцией mysqld
--initialize-insecure
для
MySQL 5.7 или с помощью команды
mysql_install_db
для MySQL 5.6. Каталог данных узла должен быть пустым, или
реинициализация не будет предпринята.
Вызов этой команды с опцией
--added
, а не с ID процесса запускает все узлы, которые были
добавлены ранее к кластеру командой
add process
, но не были запущены. Для добавленных узлов данных и
mysqld
применение опции
--added
также подразумевает использование опции
--initial
, то есть
mcmd
попытается инициализировать добавленные узлы (см. описание для опции
--initial
выше). Кроме того, когда используется
опция
--added
, как только все добавленные
узлы работают, команда
CREATE NODEGROUP
дается узлу управления для создания новой группы узлов.
Вы не можете использовать эту команду, чтобы начать процесс mysqld в остановленном или недоступном кластере, это вызовет ошибку. Это применяется, например, к случаю, в котором кластер был создан для импорта кластера, но импорт еще не закончен (см. разделы 4.4.1 и 3.5).
stop process
stop processprocess_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.
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
. Это, как правило, происходит в следующих ситуациях:
Процесс это узел данных, формируемый с
StopOnError=true
,
чтобы это не было бы автоматически перезапущено
mcmd
. Вместо того, чтобы использовать
using the
start process
, чтобы перезапустить процесс, пользователь,
возможно, перезапустил процесс вручную, что восстановит процесс, но оставит
mcmd без знания того, что восстановить.
update process
тогда необходима, чтобы восстановить контроль
mcmd
над процессом.
Процесс это узел, который остановлен mcmd , но по некоторым причинам его PID остается действительным для операционной системы. В некоторых ситуациях процесс мог бы даже заработать снова без знания или способности mcmd управлять им.
mcmd не может соединиться с узлом SQL из-за
различных причин (например, уже есть слишком много связей с узлом), статус
процесса для узла становится failed
,
в то время, как файл PID продолжает существовать.
Команда работает, импортируя процесс под контроль
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 до
фактического обновления, эти шаги необходимы для процесса обновления.
remove process
remove process [--removedirs] process_id_list cluster_name process_id_list: process_id[, process_id[, ...]]
Эта команда удаляет процессы в
process_id_list
из кластера
cluster_name
.
Это обеспечивает средство сократить кластер офлайн.
При применении опции
--removedirs
все данные для указанных процессов будут удалены.
Следующие ограничения применяются, используя эту команду:
Кластер должен быть в статусе
created
или
stopped
.
Процессы, которые будут удалены, должны быть в статусе
stopped
, added
или
import
.
Команда не может удалить все процессы из кластера в статусе
created
, по крайней мере один
процесс нужно оставить.
Команда не может удалить все процессы того же самого типа из кластера
со статусом stopped
, по крайней мере один
процесс нужно оставить в кластере для каждого типа узлов
(управление, данные и API).
Команда не может удалить узел данных, который находится в статусе
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)
Эта секция содержит информацию о командах клиента MySQL Cluster Manager, касающихся поддержки MySQL NDB Cluster.
abort backup
abort backup --backupid=backup_id cluster_name
Эта команда прерывает резервную копию кластера
cluster_name
с ID
backup_id
, определенным опцией
--backupid
. Можно получить список резервных копий и их ID,
известных этому экземпляру MySQL Cluster Manager, через
list
backups
. Если резервная копия не происходит на самом деле, команда
не имеет никакого эффекта.
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
.
Чтобы позволить больше гибкости для реконфигурации кластера во время
восстановления, начиная с версии 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:
По крайней мере один узел mysqld должен работать в кластере для логической резервной копии.
Никакая резервная копия не была создана ни для какого узла mysqld, который не работает.
Метаданные для не-NDB таблиц не поддерживаются.
Логическая резервная копия это НЕ резервная копия момента времени, никакие операции DDL не должны быть выполнены на кластере, когда процесс резервного копирования будет работать, или поддержанные метаданные станут несовместимыми с поддержанными данными.
Резервная копия для метаданных таблицы NDB полезна для восстановления данных с одного кластера на другой с различной конфигурацией (например, когда целевой кластер для восстановления имеет различное количество узлов данных), посмотрите разделы 3.6.2.4 и 3.6.2.5 для некоторых вариантов использования.
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)
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/
, в то время, как резервная копия происходит.
0 (по умолчанию) = не печатать. Максимум 65535.cluster_name
/nodeid
/tmp
--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.
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.
Эта секция содержит описания команд MySQL Cluster Manager, связанные с импортированием в MySQL Cluster Manager. Эти операции включают миграцию процессов кластера и копированик данных конфигурации.
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
и посмотрите, что получится.
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
для выполнения фактического импорта написаны в файл
/
для вашей экспертизы. Это позволяет проверить импорт
конфигурации, на самом деле не копируя ни один из параметров настройки в
кластер, которым управляет MySQL Cluster Manager. Можно тогда импортировать
все параметры настройки, используя
path-to-mcm-data-repository
/clusters/
clustername
/tmp/import_config.message_id
.mcmimport config
(без опции
--dryrun
), или отрегулировать некоторые
параметры настройки в файле
/
, а затем импортировать параметры настройки, выполняя
файл с помощью агента
mcm, см.
раздел 3.5.2.3.
path-to-mcm-data-repository
/clusters/
clustername
/tmp/import_config.message_id
.mcm
Когда импортируются параметры конфигурации для узла
mysqld,
если относительный путь используется для
socket
или для любого
директивного значения (например,
plugin_dir
),
импорт будет отклонен клиентом
mcm.
Удостоверьтесь, что абсолютный путь используется и при необходимости внесите
изменения в атрибуты в файле .mcm
, созданном
командой import
config --dryrun
, затем импортируйте параметры настройки, выполнив
файл с помощью клиента
mcm.