WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 4. Команды клиента MySQL Cluster Manager Секции в этой главе описывают команды, используемые в MySQL Cluster Manager 1.4.8 для таких задач, как определение мест, пакетов и экземпляров ySQL NDB Cluster, настройки MySQL NDB Cluster и получения статуса MySQL NDB Cluster. Эти команды даются агенту управления, используя клиент mysql, включенную в MySQL NDB Cluster. Каждая команда клиента MySQL Cluster Manager принимает форму, показанную здесь: instruction [options] [arguments] options: option [option] [...] option: --option-long-name[=value-list] | -option-short-name [value-list] value-list: value[,value[,...]] arguments: argument[argument] [...] Эта команда MySQL Cluster Manager запускает MySQL NDB Cluster mycluster и отправляет процесс в фон, чтобы клиент мог использоваться, чтобы выполнить другие команды, не имея необходимости ждать завершения start cluster: start cluster --background mycluster; В этом примере команда содержит инструкцию start cluster. Инструкция состоит из одного или двух ключевых слов, например, set или show status. Эта инструкция изменяется опцией --background, однако, это не назначает значений. У большинства вариантов команды есть краткие формы, состоящие из одних букв, в дополнение к их подробным формам. Используя краткую форму --background, предыдущий пример мог также быть написан так: start cluster -B mycluster; Длинной форме выбора должна предшествовать двойная черта (--), форма не чувствительна к регистру (нижний регистр, являющийся канонической формой). Краткой форме выбора должна предшествовать единственная черта (-), форма чувствительна к регистру. В любом случае символ тире следует непосредственно перед опцией и не должно быть никаких пробелов между ними. Иначе MySQL Cluster Manager не может разобрать команду правильно. Больше информации о подробных формах и кратких формах вариантов дано позже в этой секции. Не путайте варианты, данные командам MySQL Cluster Manager, с опциями mysql. Опции команд MySQL Cluster Manager всегда передаются как часть команды MySQL Cluster Manager, они не передаются клиенту mysql. Кроме того, вы не можете выпустить запросы или другие SQL-операторы в MySQL Cluster Manager. Они не признаны клиентом и отклонены с ошибкой. Обратное из этого также верно: команды клиента MySQL Cluster Manager не распознаются клиентом mysql. Инструкция просто берет аргумент. Аргумент обычно идентификатор, который называет объект, который будет обработан, в этом случае команда удаляет место, имя которого соответствует аргументу. Дополнительная опция --verbose может использоваться для create cluster, add process и list hosts . В обоих случаях использование выбора заставляет команду возвращать список из процессов группы MySQL NDB, затронутых командой: это включает ID их узлов, типы процесса и хосты, где они расположены. Идентификаторы в командах клиента. Идентификатор MySQL Cluster Manager состоит из любой последовательности знаков из числа следующего: Буквы от 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 mycluster терпит неудачу, если какой-либо процесс MySQL NDB Cluster в кластере MySQL NDB mycluster работает, однако, delete cluster --force mycluster вызывает закрытие mycluster, сопровождаемое удалением mycluster из инвентаря MySQL Cluster Manager. --force поддерживается для следующих команд MySQL Cluster Manager: delete site start cluster restart cluster stop cluster delete cluster upgrade cluster add process start process stop process remove process set reset --background (краткая форма -B ): Вместо того, чтобы ждать окончания исполнения команды, MySQL Cluster Manager немедленно возвращает командную строку, позволяя вам выполнить дополнительные задачи в клиенте в то время, как та команда продолжает выполняться в фоновом режиме. Это может быть полезно, выполняя команды, которые могли бы потребовать некоторое время (такие, как старт кластера с очень многими узлами). Этот выбор поддерживается всеми командами клиента за исключением create site, delete site, add hosts, add package и delete package. 4.1. Помощь онлайн и информационные команды Помощь онлайн доступна в MySQL Cluster Manager. Клиент может предоставить общую и определенную для команды информацию. Кроме того, можно получить информацию о командах клиента mysql, которые независимы от сервера MySQL и таким образом также доступны для использования, когда есть связь с агентом MySQL Cluster Manager. Листинг команд клиента MySQL Cluster Manager. Для получения списка всех команд с краткими описаниями используйте list commands: mcm> list commands; +---------------------------------------------------------------------------+ | Help | +---------------------------------------------------------------------------+ | COMMANDS | | | | abort backup Abort an ongoing cluster backup. | | add hosts Add hosts to site. | | add package Add a package alias. | | add process Add cluster process. | | autotune Autotune a cluster to given use-case template. | | backup agents Backup the agents repository and metadata. | | backup cluster Backup a cluster. | | change log-level Change the log-level. | | change process Change process type. | | collect logs Collect log files. | | create cluster Create a cluster. | | create site Create a site. | | delete cluster Delete a cluster. | | delete package Delete a package. | | delete site Delete a site. | | get Get configuration variables. | | import cluster Import a running cluster. | | import config Import the configuration of a running cluster. | | list backups List backup images. | | list clusters List all clusters. | | list commands List the help text. | | list hosts List hosts in site. | | list nextnodeids List next nodeids to be allocated. | | list packages List all packages. | | list processes List processes. | | list sites List all sites. | | remove hosts Remove hosts from site. | | remove process Remove a cluster process. | | reset Reset configuration variables. | | restart cluster Restart a cluster. | | restore cluster Restore a cluster. | | rotate log Rotate the mcmd log. | | set Set configuration variables. | | show settings Show agent settings. | | show status Show cluster, process, operation or backup status. | | start cluster Start a cluster. | | start process Start a cluster process. | | stop agents Stop agents in site. | | stop cluster Stop a cluster. | | stop process Stop a cluster process. | | upgrade cluster Upgrade a cluster. | | version Print version information. | | | | GLOBAL OPTIONS | | Options that can be used with all commands | | | | --help | -? Print detailed help. | | | | Use '<COMMAND> --help' to see verbose help for individual commands. | +---------------------------------------------------------------------------+ 50 rows in set (0.03 sec) Получение информации об определенной команде MySQL Cluster Manager. Чтобы получить более подробную помощь, определенную для данной команды, вызовите команду, используя опцию --help : mcm> create site --help; +----------------------------------------------------------------+ | Help | +----------------------------------------------------------------+ | | | create site [options] <sitename> | | | | Creates a site from the hosts listed in --hosts. | | | | Required options: | | --hosts | -h Comma separated list of hostnames. | | Format: --hosts = <host>[,<host>]*. | | | +----------------------------------------------------------------+ 9 rows in set (0.00 sec) Для любой команды MySQL Cluster Manager опция --help может быть сокращена до -? : mcm> list processes -?; +-------------------------------------------------------------+ | Help | +-------------------------------------------------------------+ | | | list processes <sitename> | | | | Lists all processes defined in the specified cluster. | +-------------------------------------------------------------+ 4 rows in set (0.00 sec) Как упомянуто в другом месте в этом руководстве (см. главу 4), у многих вариантов команды есть краткие формы также. Они включены в документацию для каждой команды. Можно также узнать о них для данной команды, вызывая команду с опцией --help или -? . Можно получить версию выпуска программного обеспечения MySQL Cluster Manager командой version. Команды клиента mysql в MySQL Cluster Manager. Можно также использовать стандартные команды mysql в MySQL Cluster Manager (но не запросы SQL, которые зависят от того, чтобы быть связанным с сервером MySQL), например, prompt, quit и status. Например, вывод команды статуса, когда связано с агентом MySQL Cluster Manager выглядит примерно так (в зависимости от точной версии клиента и агента, которую вы используете и возможно других факторов): mcm> status -------------- /home/jon/bin/mcm/libexec/../cluster/bin/mysql Ver 14.14 Distrib 5.7.29-ndb-7.6.13, for linux2.6 (x86_64) using EditLine wrapper Connection id:1 Current database: <n/a> Current user: admin SSL:Not in use Current pager:less Using outfile:'' Using delimiter:; Server version: 1.4.8 MySQL Cluster Manager Protocol version: 10 Connection: 127.0.0.1 via TCP/IP Server characterset:<n/a> Db characterset:<n/a> Client characterset:<n/a> Conn.characterset:<n/a> TCP port: 1862 -------------- Можно использовать разделитель команды с командами mysql, но вы не обязаны делать так. Например, предполагая, что разделитель был точкой с запятой по умолчанию (;), мы, возможно, выполнили команду status: mcm> status; -------------- /home/jon/bin/mcm/cluster/bin/mysqlVer 14.14 Distrib 5.7.29-ndb-7.6.13,... Особенно полезна команда mysql, чтобы можно было также использовать в mcm с командой source (краткая форма: \.), которую можно использовать для выполнения скриптов, содержащих команды MySQL Cluster Manager. В Linux у вас мог бы быть текстовый файл get-attributes.mcm в вашем домашнем каталоге: get :ndb_mgmd mycluster\G get :ndbd mycluster\G get :mysqld mycluster\G Предположение, что вы создали кластер mycluster, можно управлять этим скриптом в клиенте, результаты варьируются согласно тому, как этот кластер на самом деле формируется, но должны быть подобны этому: mcm> \. ~/get-attributes.mcm mcm> get :ndb_mgmd mycluster\G *************************** 1. row *************************** Name: DataDir Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/49/data Process1: ndb_mgmd NodeId1: 49 Process2: NodeId2: Level: Comment: *************************** 2. row *************************** Name: HostName Value: flundra Process1: ndb_mgmd NodeId1: 49 Process2: NodeId2: Level: Comment: Read only *************************** 3. row *************************** Name: NodeId Value: 49 Process1: ndb_mgmd NodeId1: 49 Process2: NodeId2: Level: Comment: Read only *************************** 4. row *************************** Name: PortNumber Value: 1186 Process1: ndb_mgmd NodeId1: 49 Process2: NodeId2: Level: Process Comment: 4 rows in set (0.09 sec) mcm> get :ndbd mycluster\G *************************** 1. row *************************** Name: DataDir Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/1/data Process1: ndbd NodeId1: 1 Process2: NodeId2: Level: Comment: *************************** 2. row *************************** Name: HostName Value: tonfisk Process1: ndbd NodeId1: 1 Process2: NodeId2: Level: Comment: Read only *************************** 3. row *************************** Name: NodeId Value: 1 Process1: ndbd NodeId1: 1 Process2: NodeId2: Level: Comment: Read only *************************** 4. row *************************** Name: DataDir Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/2/data Process1: ndbd NodeId1: 2 Process2: NodeId2: Level: Comment: *************************** 5. row *************************** Name: HostName Value: grindval Process1: ndbd NodeId1: 2 Process2: NodeId2: Level: Comment: Read only *************************** 6. row *************************** Name: NodeId Value: 2 Process1: ndbd NodeId1: 2 Process2: NodeId2: Level: Comment: Read only 6 rows in set (0.10 sec) mcm> get :mysqld mycluster\G *************************** 1. row *************************** Name: datadir Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/50/data Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: *************************** 2. row *************************** Name: HostName Value: haj Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: Read only *************************** 3. row *************************** Name: log_error Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/50/data/mysqld_50_out.err Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: *************************** 4. row *************************** Name: ndb_nodeid Value: 50 Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: Read only *************************** 5. row *************************** Name: ndbcluster Value: Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: Read only *************************** 6. row *************************** Name: NodeId Value: 50 Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: Read only *************************** 7. row *************************** Name: port Value: 3306 Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: *************************** 8. row *************************** Name: socket Value: /tmp/mysql.mycluster.50.sock Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: *************************** 9. row *************************** Name: tmpdir Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/50/data/tmp Process1: mysqld NodeId1: 50 Process2: NodeId2: Level: Comment: *************************** 10. row *************************** Name: datadir Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/51/data Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: *************************** 11. row *************************** Name: HostName Value: torsk Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: Read only *************************** 12. row *************************** Name: log_error Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/51/data/mysqld_51_out.err Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: *************************** 13. row *************************** Name: ndb_nodeid Value: 51 Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: Read only *************************** 14. row *************************** Name: ndbcluster Value: Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: Read only *************************** 15. row *************************** Name: NodeId Value: 51 Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: Read only *************************** 16. row *************************** Name: port Value: 3307 Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: *************************** 17. row *************************** Name: socket Value: /tmp/mysql.mycluster.51.sock Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: *************************** 18. row *************************** Name: tmpdir Value: /home/jon/bin/mcm/mcm_data/clusters/mycluster/51/data/tmp Process1: mysqld NodeId1: 51 Process2: NodeId2: Level: Comment: 18 rows in set (0.05 sec) mcm> Вы не получите приглашение клиента до окончания работы скрипта. Точно так же в Windows можно создать пакетный файл, используя Notepad или другой текстовый редактор, скопировать те же самые команды get и сохранить файл как get-attributes.bat в удобном местоположении, таком как рабочий стол Windows. Можно смотреть список доступных команд mysql, используя команду help. 4.2. Команды агента MySQL Cluster Manager В этой секции мы обсуждаем команды, используемые, чтобы работать с MySQL Cluster Manager. Кроме того, есть команды stop agents, show settings, version и show warnings, которые касаются агентов управления. Место с точки зрения MySQL NDB Cluster и MySQL Cluster Manager является коллекцией из одного или более компьютеров, где работают агенты MySQL Cluster Manager. Каждый агент опознается комбинацией двух сведений: Имя хоста или IP-адрес машины, где агент работает. Номер порта, используется агентом для коммуникаций. MySQL NDB Cluster делает чрезвычайно интенсивное использование сетевых соединений, и поиски DNS могут конфликтовать с MySQL NDB Cluster и MySQL Cluster Manager по пропускной способности, приводя к негативному воздействию на производительность MySQL NDB Cluster. Поэтому мы рекомендуем, чтобы вы использовали числовые IP-адреса, а не имена хоста для хостов MySQL NDB Cluster и MySQL Cluster Manager. 4.2.1. Команда add hosts add hosts {--hosts=|-h }host_list site_name host_list: host[, host[, ...]] Эта команда добавляет один или более хостов существующего места управления. Агенты, использующие тот же самый порт в качестве места управления, должны работать на любых хостах, добавленных с использованием этой команды. Эта команда берет два обязательных аргумента: список хостов (использующий опцию --hosts или ее краткую форму -h ) и название места, к которому должны быть добавлены хосты. --hosts берет список из разделенных запятой значений одного или более хостов, чтобы добавить их к месту. Например, следующая команда добавляет два хоста torsk и kolja к месту управления mysite: mcm> add hosts --hosts=torsk,kolja mysite; +--------------------------+ | Command result | +--------------------------+ | Hosts added successfully | +--------------------------+ 1 row in set (0.48 sec) Ни один из хостов, добавленных этой командой, не может быть членом места управления site_name. Не пытайтесь добавить снова хост, который уже является членом места управления, используя его вторичный IP-адрес, процесс mcmd на хосте уже связан с IP-адресом, который поставлялся, когда хост был добавлен, это не может быть связано снова с другим IP-адресом. Эта команда не поддерживает опцию --force. Не следует использовать localhost в списке хостов, поскольку MySQL Cluster Manager полагается на операционную систему для резолюции имени хоста, и localhost мог бы быть разрешен по-другому на различных системах. Используйте надлежащие имена хоста для списка хоста или, предпочтительно, используйте IP-адреса для хостов вместо этого. Когда IPv6-системы Windows используются в качестве хостов MySQL NDB Cluster под MySQL Cluster Manager, необходимо сослаться на эти хосты, используя адреса IPv4. Иначе MySQL Cluster Manager будет неспособен соединиться с процессами агента на тех хостах. Посмотрите раздел 5.1. 4.2.2. Команда 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) 4.2.3. Команда change log-level change log-level [{--hosts=|-h }host_list] log_level site_name host_list: host[, host[,...]] Установите уровень регистрации группы агента управления. Это имеет тот же самый эффект, как использование опции --log-level, однако, в отличие от опции, эта команда может использоваться во время выполнения и не требует перезапуска mcmd. Выполнение этой команды отвергает любое значение для --log-level в командной строке или в конфигурационном файле агента. Когда log_level используется без host_list и site_name, эта команда применяется только к агенту, с которым связан mcm. В следующем примере уровень регистрации установлен в warning только на хосте, управляемом непосредственно агентом, с которым связан mcm: mcm> change log-level warning; +--------------------------------+ | Command result | +--------------------------------+ | Log-level changed successfully | +--------------------------------+ 1 row in set (0.00 sec) Можно определить название места, которое будет затронуто командой. Например, следующая команда относится к месту, названному mysite: mcm> change log-level debug mysite; +--------------------------------+ | Command result | +--------------------------------+ | Log-level changed successfully | +--------------------------------+ 1 row in set (0.05 sec) Можно также ограничить изменение одного или более хостов в данном месте, используя опцию --hosts option (краткая форма -h) с именами хостов, отделенными запятыми. Следующая команда изменяет уровень регистрации на debug на хостах tonfisk и haj, но не на любых других хостах в mysite: mcm> change log-level --hosts=tonfisk,haj debug mysite; +--------------------------------+ | Command result | +--------------------------------+ | Log-level changed successfully | +--------------------------------+ 1 row in set (0.09 sec) Необходимо определить место, используя опцию --hosts, попытка использовать только --hosts приведет к ошибке. Принятые значения для log_level совпадают со значениями для --log-level : debug, critical, error, info, message или warning. См. подробности здесь. 4.2.4. Команда rotate log rotate log [{--hosts=|-h }host_list] [site_name] host_list: host[, host[,...]] Ротирует журналы mcmd для связанного агента MySQL Cluster Manager для агентов на определенных хостах или для агентов на всех хостах в месте управления. Например, чтобы ротировать журналы для агента, с которым связана сессия клиента: mcm> rotate log; +--------------------------+ | Command result | +--------------------------+ | Log rotated successfully | +--------------------------+ 1 row in set (0.03 sec) Новый файл журнала с подчеркиванием и меткой времени, вставленной в имя файла перед расширением, создается в результате: -rw-r----- 1 mcmd cluster 74265 Jul 15 22:45 mcmd.log -rw-r----- 1 mcmd cluster 1197573 Jul 15 22:45 mcmd_2017-07-15-22-45-28.log MySQL Cluster Manager 1.4.4 и ранее: новое имя файла находится в формате old_filename .timestamp, это mcmd.log.2017-07-15T22-45-28 для примера выше. Чтобы ротировать журналы для агентов на определенных хостах nanna12 и nanna13, используйте --hosts (краткая форма -h ): mcm> rotate log --hosts=nanna12,nanna13 mysite; Чтобы ротировать журналы всех агентов в месте управления mysite: mcm> rotate log mysite; 4.2.5. Команда collect logs collect logs [cluster_name] Эта команда собирает файлы журнала и другие связанные файлы от всех хостов. Когда название (cluster_name ) поставляется командой, она собирает все файлы журнала (.log), а также конфигурационные файлы (.ini, .cnf), файлы ошибок (.err) и трассировки, используемые всеми процессами, принадлежащими кластеру, а также все файлы журнала агента. Когда агент mcmd получает команду collect logs от агента mcm, с которым это связано, это настраивает сокет сервера TCP, используя порт 0 по умолчанию и позволяет операционной системе назначить фактический номер порта. Всем агентам в месте тогда приказывают выполнить копирование, каждый из них порождает клиента TCP, который соединяется с сокетом сервера TCP, настроенным ранее, чтобы скопировать файлы. MySQL Cluster Manager 1.4.2 и позже: Чтобы назначить определенный порт вручную для копирования файла, используйте опцию --copy-port, запуская mcmd. По умолчанию 0. Команда collect logs имеет тайм-аут: если через 30 секунд никакие связи не могут быть установлены ни одним из клиентов, или никакие поступающие связи не обнаружены сервером TCP. Если брандмауэр или другие сетевые проблемы запрещают клиентам TCP соединяться с сокетом сервера TCP, collect logs никогда не будет заканчиваться. Собранные файлы складируются в репозиторий данных MySQL Cluster Manager (../mcm_data (относительно инсталляционного каталога MySQL Cluster Manager) по умолчанию или определенный опцией --manager-directory) в подкаталог collected_files, где файлы организованы под иерархией меток времени [для коллекций файлов], а затем по именам хостов. Например, журнал агента для хоста tonfisk, собранный 2014-07-31 в 07:44:05, лежит в: /opt/mcm_data/collected-files/2014-07-31T07:44:05Z/tonfisk/opt/mysql/logs/mcmd-tonfisk-19001.log Если не задано cluster_name, только файлы журнала агента собраны. 4.2.6. Команда create site create site {--hosts=|-h }host_list site_name host_list: host[, host[,...]] Команда create site используется, чтобы создать место управления MySQL Cluster Manager, то есть, агентов управления MySQL Cluster Manager, работающих на одном или более компьютерах. Команда требует список из одного или более хостов, где работают агенты управления, и название места. Список хоста передается как значение опции --hosts (краткая форма: -h ). Это пример команды create site, которая создает место mysite, состоящее из хостов tonfisk и flundra: mcm> create site --hosts=tonfisk,flundra mysite; +---------------------------+ | Command result | +---------------------------+ | Site created successfully | +---------------------------+ 1 row in set (0.31 sec) Можно проверить, что место было создано, как предназначено, используя list sites : mcm> list sites; +--------+------+-------+-----------------+ | Site | Port | Local | Hosts | +--------+------+-------+-----------------+ | mysite | 1862 | Local | tonfisk,flundra | +--------+------+-------+-----------------+ 1 row in set (0.06 sec) См. раздел 4.2.8. Агенты должны работать на всех хостах, определенных в --hosts при выполнении create site, иначе команда терпит неудачу с ошибкой Agent on host host: port is unavailable. Хост, где агент используется, чтобы дать команду, должен быть одним из перечисленных хостов. Иначе команда терпит неудачу с ошибкой Host host_name is not a member of site site_name . Кроме того, если клиент и агент, с которым это связано, находятся на том же самом хосте, этот хост должен быть включен в список хостов, используя его имя хоста или его собственный кольцевой адрес (который может быть чем-то другим, чем 127.0.0.1 на некоторых системах), иначе кластер мог бы стать не перезапускаемым в будущем. Данный агент может быть членом одного места только, если один из агентов управления, определенных в host_list уже принадлежит месту, команда терпит неудачу с ошибкой Host host is already a member of site site . Применение localhost как аргумента в опции --hosts приведет к созданию сайта из единственного хоста (состоящего из хоста, на котором выполнили команду), который не может быть расширен позже командой add hosts. Также заметьте, что вы не можете смешать localhost с другими именами в списке хостов. Поэтому рекомендуется, чтобы вы использовали IP-адреса (но не любые адреса, принадлежащие подсети localhost 127.*.*.*) или надлежащие имена хостов в списке. Когда IPv6-системы Windows используются в качестве хостов MySQL NDB Cluster под MySQL Cluster Manager, необходимо сослаться на эти хосты, используя адреса IPv4. Иначе MySQL Cluster Manager не будет способен соединиться с процессами агента на тех хостах. Посмотрите раздел 5.1. 4.2.7. Команда delete site delete site site_name Удаляет существующее место управления. Команда не останавливает или удаляет любых агентов, составляющих удаляемое место, вместо этого агенты продолжают работать и оставаться доступными для использования в других местах. Команда берет отдельный аргумент, название места, которое будет удалено. Этот пример показывает удаление места управления named mysite: mcm> delete site mysite; +---------------------------+ | Command result | +---------------------------+ | Site deleted successfully | +---------------------------+ 1 row in set (0.38 sec) Если место, которое будет удалено, не существует, команда терпит неудачу с ошибкой Command requires a site to be defined. Если есть какие-либо пакеты, ссылающиеся на хосты, принадлежащие месту, delete site терпит неудачу с ошибкой Packages exist in site site_name. Команда также терпит неудачу, если определяются какие-либо кластеры, которые включают хосты, принадлежащие месту. Клиент управления должен быть связан с местом, чтобы быть в состоянии удалить его. Кроме того, если вы выполняете delete site с опцией --force, используя один агент управления в то время, как иной агент управления не работает, необходимо удалить файлы места недостающего агента управления вручную. Для получения дополнительной информации о файлах места посмотрите раздел 2.4. 4.2.8. Команда list sites list sites Эта команда возвращает список мест, известных агенту управления. Это не требует никаких аргументов. Пример: mcm> list sites; +--------+------+-------+-----------------+ | Site | Port | Local | Hosts | +--------+------+-------+-----------------+ | mysite | 1862 | Local | tonfisk,flundra | +--------+------+-------+-----------------+ 1 row in set (0.06 sec) Вывод list sites содержит следующие колонки: Site. Название места. Port. Порт TCP/IP, используемый для связей между клиентами и агентами управления. Local. Local или Remote. Hosts. Список разделенных запятой значений хостов, составляющих место. 4.2.9. Команда list hosts list hosts [--verbose|-v]site_name list hosts используется, чтобы получить список хостов, составляющих данное место управления. Команда требует отдельный аргумент, название места. Для каждого перечисленного хоста возвращенная информация включает имя хоста, статус и версию программного обеспечения агента управления, как показано в этом примере: mcm> list hosts mysite; +---------+-----------+---------+ | Host | Status | Version | +---------+-----------+---------+ | tonfisk | Available | 1.4.8 | +---------+-----------+---------+ | flundra | Available | 1.4.8 | +---------+-----------+---------+ 2 rows in set (0.16 sec) Status может быть: 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) 4.2.10. Команда show settings show settings [--hostinfo] Эта команда перечисляет текущие значения многих опций mcmd : mcm> show settings; +-------------------+------------------------+ | Setting | Value | +-------------------+------------------------+ | log-file | /opt/mcm_data/mcmd.log | | log-level | message | | log-use-syslog | FALSE | | manager-directory | /opt/mcm_data | | manager-username | mcmd | | manager-password | ******** | | manager-port | 1862 | | xcom-port | 18620 | +-------------------+------------------------+ 8 rows in set (0.00 sec) Применение опции --hostinfo заставляет команду распечатать информацию о хосте, с которым связан клиент mcm: mcm> show settings --hostinfo; +-----------------+-------------------------------+ | Property | Value | +-----------------+-------------------------------+ | Hostname | localhost.localdomain | | Platform | Linux 3.13.11-100.fc19.x86_64 | | Processor cores | 1 | | Total memory | 1819 Mb | +-----------------+-------------------------------+ 4 rows in set (0.00 sec) 4.2.11. Команда stop agents stop agents[[--hosts=host_list] site_name] Эта команда останавливает одного или больше агентов MySQL Cluster Manager на одном или более хостах. Когда используется без любых аргументов, stop agents останавливает агента, с которым в настоящее время связывается клиент. Когда используется с названием места управления, команда останавливает всех агентов, работающих на хостах, составляющих место. Эта команда остановит все агенты MySQL Cluster Manager на хостах в mysite: mcm> stop agents mysite; Можно также остановить подмножество агентов в данном месте управления, перечислив хосты, где они работают с помощью опции --hosts (краткая форма: -h ), наряду с названием места, которому они принадлежат. Результат следующей команды состоит в том, чтобы остановить агентов MySQL Cluster Manager на хостах kolja и torsk, оба из которых являются членами места управления mysite: mcm> stop agents --hosts=kolja,torsk mysite; Многократные имена хостов после опции --hosts должны быть отделены запятыми без пробелов. Вызов stop agents с этой опцией, не поставляя site_name вызывает синтаксическую ошибку. Использование неопределенного site_name или имен хостов, не принадлежащих месту, с этой командой также приводит к ошибке. Когда IPv6-системы Windows используются в качестве хостов MySQL NDB Cluster под MySQL Cluster Manager, необходимо сослаться на эти хосты, используя адреса IPv4. Иначе MySQL Cluster Manager не будет способен соединиться с процессами агента на тех хостах. Посмотрите раздел 5.1. 4.2.12. Команда version version Эта команда показывает версию программного обеспечения MySQL Cluster Manager, используемого агентом MySQL Cluster Manager, с которым этот клиент связан, как показано здесь: mcm> version; +-------------------------------------+ | Version | +-------------------------------------+ | MySQL Cluster Manager 1.4.8 (64bit) | +-------------------------------------+ 1 row in set (0.00 sec) Команда version не берет аргументов. 4.2.13. Команда show warnings Используя команду show warnings, можно проверить предупреждения (максимум последние пять), записанные в журнал агента (mcmd.log): mcm> set delayed_insert_timeout:mysqld=400 mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ mcm> show warnings; +---------+------+-----------------------------------------------------------------------+ | Level | Code | Message | +---------+------+-----------------------------------------------------------------------+ | Warning | -1 | Config variable delayed_insert_timeout was deprecated in mysqld 5.6.7 | +---------+------+-----------------------------------------------------------------------+ 4.3. Команды пакетов MySQL Cluster Manager Эта секция содержит информацию о командах клиента MySQL Cluster Manager для регистрации, расширения, отмены и получения информации о пакетах программного обеспечения, составляющих экземпляры MySQL NDB Cluster, которыми нужно управлять, используя MySQL Cluster Manager. 4.3.1. Команда add package add package {--basedir=|-b }path [{--hosts=|-h }host_list] package_name host_list: host[, host[,...]] Эта команда создает новый пакет или, если пакет package_name уже есть, эта команда расширяет определение пакета. Опция --basedir (краткая форма: -b) указывает на местоположение инсталляционного каталога MySQL NDB Cluster на перечисленных хостах. Это должно быть путем к каталогу верхнего уровня, где расположено программное обеспечение MySQL NDB Cluster (например, /usr/local/mysql), и не должно включать каталоги MySQL NDB Cluster bin, libexec или другой подкаталог в рамках инсталляционного каталога. Хосты могут быть определены как список разделенных запятой значений, используя опцию --hosts (краткая форма: -h ), однако, эта опция не требуется. Если --hosts пропущена, path как предполагается, действителен для всех хостов в кластере, который создается, используя этот пакет (см. раздел 4.4.1). Вы не можете скомандовать 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) 4.3.2. Команда delete package delete package [{--hosts=|-h }host_list] package_name host_list: host[, host[,...]] Эта команда используется, чтобы снять регистрацию пакета. Более определенно это удаляет любые ссылки на установки программного обеспечения MySQL NDB Cluster, добавленные к хранилищу агента, когда пакет был создан. delete package не удаляет установок MySQL NDB Cluster, команда удаляет только ссылки на установки. Как только пакет был разрегистрирован, он больше не может использоваться для create cluster. Двоичные модули MySQL NDB Cluster остаются, но могут использоваться в кластере MySQL NDB Cluster, которым управляют, используя MySQL Cluster Manager, только после того как основной каталог, содержащий их, был зарегистрирован в другом пакете. Возможно зарегистрировать основной каталог в многих пакетах, посмотрите раздел 4.3.1. Если опция --hosts (краткая форма: -h ) используется, основные директивные параметры настройки для хоста или хостов заданные названной опцией, также удалены. Все хосты, данные в host_list, должны быть частью места, в котором зарегистрирован пакет. Иначе команда терпит неудачу. Пакет, который используется кластером, не может быть разрегистрирован, кластер должен сначала быть удален (см. раздел 4.4.2). Вот пример, который демонстрирует, как разрегистрировать пакет mypackage: mcm> delete package mypackage; +------------------------------+ | Command result | +------------------------------+ | Package deleted successfully | +------------------------------+ 1 row in set (1.23 sec) Можно также проверить, что пакет был разрегистрирован, с помощью list packages , имя пакета больше не должно появляться в выводе этой команды. При попытке использовать незарегистрированный пакет в create cluster команда терпит неудачу, как показано здесь: mcm> create cluster --package=mypackage > --processhosts=ndb_mgmd@tonfisk,ndbd@grindval,ndbd@flundra,mysqld@tonfisk mycluster; ERROR 4001 (00MGR): Package mypackage not defined upgrade cluster со ссылкой на незарегистрированный пакет также потерпит неудачу. 4.3.3. Команда list packages list packages [package_name] site_name Эта команда выводит список зарегистрированных пакетов. Это требует отдельного аргумента, являющегося названием места, в котором пакеты зарегистрированы, как показано в этом примере: mcm> list packages mysite; +-------------+---------------------------------------+-----------------+ | Package | Path | Hosts | +-------------+---------------------------------------+-----------------+ | yourpackage | /usr/local/ndb-host-10 | tonfisk | | | /usr/local/ndb-host-20 | flundra | | mypackage | /usr/local/mysql | tonfisk,flundra | +-------------+---------------------------------------+-----------------+ 3 rows in set (1.07 sec) Если tonfisk и flundra хосты Windows, список пакетов мог бы выглядеть примерно так: mcm> list packages mysite; +-------------+---------------------------------------+-----------------+ | Package | Path | Hosts | +-------------+---------------------------------------+-----------------+ | yourpackage | c:/cluster/ndb-host-10 | tonfisk | | | c:/cluster/ndb-host-20 | flundra | | mypackage | c:/mysql | tonfisk,flundra | +-------------+---------------------------------------+-----------------+ 3 rows in set (1.07 sec) В примере yourpackage использует MySQL NDB Cluster в C:\cluster\ndb-host-10 на хосте tonfisk и C:\cluster\ndb-host-20 на flundra, mypackage использует MySQL NDB Cluster в C:\mysql на обеих машинах. Вывод содержит три колонки, они описаны в следующем списке: 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 4.4. Команды MySQL Cluster Manager Cluster Эта секция содержит описания команд MySQL Cluster Manager, которые выполняют операции на кластерх. Они включают создание и удаление кластеров, старт, остановку, перезапуск и модернизацию кластера (то есть, модернизацию программного обеспечения MySQL NDB Cluster, используемого данным кластером). 4.4.1. Команда create cluster create cluster {--package=|-P}package_name {--processhosts=|-R }process_host_list cluster_name [(--import|-m) cluster_name] [--verbose | -v] process_host_list: process_name[: node_id]@host[, process_name@host[,...]] process_name: {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi} Эта команда создает кластер, который будет управляться MySQL Cluster Manager. Однако, это не запускает кластер (см. раздел 4.4.7). Эта команда может также использоваться, чтобы создать кластер, предназначенный определенно как цель импортирования другого кластера, который не находится под контролем MySQL Cluster Manager, как описано позже в этой секции, используя опцию --import. См. также раздел 3.5. create cluster требует следующих аргументов: 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. 4.4.2. Команда delete cluster delete cluster [--removedirs] cluster_name Эта команда удаляет кластер cluster_name, удаляя его из списка кластеров, управляемых MySQL Cluster Manager. delete cluster не удаляет модули MySQL NDB Cluster. Однако, это удаляет кластерную конфигурацию, данные и файлы журнала, которые хранятся в репозитории данных MySQL Cluster Manager. Этот пример демонстрирует, как удалить кластер mycluster: mcm> delete cluster mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster deleted successfully | +------------------------------+ 1 row in set (1.22 sec) Взгляд на репозиторий данных MySQL Cluster Manager (в данном случае /opt/mcm_data/) показывает, что каталог, который раньше хранил конфигурацию, данные и файлы журнала для for mycluster (/opt/mcm_data/clusters/mycluster), удален: shell> ls -l /opt/mcm_data/clusters total 0 Чтобы удалить конфигурационные файлы и файлы данных за пределами репозитория данных MySQL Cluster Manager, delete cluster должна быть вызвана с опцией --removedirs: mcm> delete cluster --removedirs mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster deleted successfully | +------------------------------+ 1 row in set (1.22 sec) Например, если один из узлов данных в mycluster имеет каталог данных за пределами репозитория данных MySQL Cluster Manager: mcm> get Datadir mycluster; +---------+---------------------------+----------+---------+----------+---------+---------+---------+ | Name | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment | +---------+---------------------------+----------+---------+----------+---------+---------+---------+ | DataDir | /home/dso/mycluster/cdata | ndbd | 1 | | | Process | | ... Удаление mycluster без использования --removedirs не удалит каталог данных для узла 1: shell> ls -l /home/dso/mycluster total 4 drwxr-xr-x . 3 dso dso 4096 Sep 10 18:00 cdata Однако, если использована опция --removedirs, каталог данных для узла 1 также удален: shell> ls -l /home/dso/mycluster total 0 delete cluster терпит неудачу, если кластер, который будет удален, работает: mcm> delete cluster mycluster; ERROR 5010 (00MGR): All processes must be stopped to delete cluster mycluster Необходимо сначала закрыть кластер, используя stop cluster. 4.4.3. Команда list clusters list clusters site_name Это перечисляет все кластеры, определенные для данного места управления site_name, вместе с пакетом, используемым каждым кластером. Например, команда, показанная здесь, показывает список всех кластеров, определенных для места mysite: mcm> list clusters mysite; +------------------+----------+ | Cluster | Package | +------------------+----------+ | mycluster | m-7.1.26 | | yourcluster | y-7.1.26 | | someothercluster | s-7.2.9 | +------------------+----------+ 3 rows in set (2.07 sec) Если site_name опущен, команда терпит неудачу с ошибкой, как показано здесь: mcm> list clusters; ERROR 6 (00MGR): Illegal number of operands 4.4.4. Команда list nextnodeids list nextnodeids cluster_name MySQL Cluster Manager обычно назначает ID на новые процессы узла автоматически (хотя это может быть отвергнуто командами create cluster или add process ). Команда list nextnodeids может использоваться, чтобы видеть следующий ID узла, который MySQL Cluster Manager зарезервировал для следующего нового процесса (каждого возможного типа процесса), чтобы добавить к кластеру cluster_name. mcm> list nextnodeids mycluster; +-----------+--------------+-------------+--------------------------+ | Category | NodeId Range | Next NodeId | Processes | +-----------+--------------+-------------+--------------------------+ | Datanodes | 1- 48 | 5 | ndbd, ndbmtd | | Others | 49 - 255 | 52 | ndb_mgmd, mysqld, ndbapi | +-----------+--------------+-------------+--------------------------+ 2 rows in set (0.07 sec) 4.4.5. Команда restart cluster restart cluster [--sequential-restart]cluster_name Эта команда выполняет перезапуск (см. Performing a Rolling Restart of an NDB Cluster) кластера cluster_name. Кластер должен уже работать Для получения информации о том, как определить операционное состояние кластера, посмотрите раздел 4.4.6. Например, команда, показанная здесь, выполняет перезапуск кластера mycluster: mcm> restart cluster mycluster; +--------------------------------+ | Command result | +--------------------------------+ | Cluster restarted successfully | +--------------------------------+ 1 row in set (1 min 22.53 sec) Если кластер уже не работает, restart cluster терпит неудачу с ошибкой, как показано здесь: mcm> show status --cluster mycluster; +-----------+---------+---------+ | Cluster | Status | Comment | +-----------+---------+---------+ | mycluster | stopped | | +-----------+---------+---------+ 1 row in set (1.49 sec) mcm> restart cluster mycluster; ERROR 5009 (00MGR): Restart can not be performed as processes are stopped in cluster mycluster MySQL Cluster Manager 1.4.8 и позже: По умолчанию перезапуск выполняется на узлах параллельным способом (то есть, половина узлов останавливается и перезапускается вместе, затем то же самое делается со второй половиной узлов). В некоторых ситуациях вы могли бы хотеть выполнить перезапуск последовательным способом, добавляя опцию --sequential-restart, в этом случае узлы будут остановлены и перезапущены один за другим. MySQL Cluster Manager 1.4.7 и ранее: перезапуск выполняется на узлах параллельным способом (то есть, половина узлов останавливается и перезапускается вместе, затем то же самое делается со второй половиной). В зависимости от количества узлов и объема данных, сохраненного в кластере, перезапуск может занять значительное количество времени до нескольких часов для кластера с очень многими узлами данных и большим объемом данных. Поэтому можно хотеть выполнить эту команду с опцией --background (краткая форма -B ), чтобы позволить ей работать в фоновом режиме, освобождая клиент MySQL Cluster Manager для других задач. В настоящее время нет никакого механизма в MySQL Cluster Manager по выполнению системных перезапусков кластера. Это означает, что атрибуты, которые требуют для изменения начального перезапуска, должны быть установлены прежде, чем кластер впервые запущен. 4.4.6. Команда show status show status --cluster|-c cluster_name show status --operation|-o cluster_name show status --backup|-b cluster_name show status --process|-r cluster_name show status --progress cluster_name show status --progressbar cluster_name Эта команда используется, чтобы проверить статус процессов кластера, резервных копий и команд в клиенте MySQL Cluster Manager. Тип возвращенного статуса зависит от четырех опций --cluster (краткая форма: -c), --operation (краткая форма: -o), --backup (краткая форма: -b), or --process (краткая форма -r) команды. Если ни одна из них не используется, предполагается --cluster. Эти варианты описаны более подробно в следующих нескольких параграфах. Опция --cluster При использовании этой опции show status сообщает о статусе кластера cluster_name : mcm> show status --cluster mycluster; +-----------+-------------------+---------+ | Cluster | Status | Comment | +-----------+-------------------+---------+ | mycluster | fully operational | | +-----------+-------------------+---------+ 1 row in set (0.01 sec) Когда используется с опцией --cluster (краткая форма: -c ), вывод этой команды состоят из двух колонок. Столбец Cluster содержит название кластера. Столбец Status содержит описание статуса кластера, возможные значения показывают в следующей таблице: Таблица 4.1. Значения статуса из show status --cluster Значение Status Смысл fully operational Все процессы кластера работают. operational Все узлы кластера в порядке, но по крайней мере один процесс узла данных (ndbd или ndbmtd) не работает. Кластер онлайн, но необходимо определить, почему любые недостающие узлы данных не работают и исправить проблему как можно скорее. non-operational Кластер не готов к эксплуатации, потому что по крайней мере один узел кластера офлайн. Необходимо исследовать и решить проблему или проблемы, затем перезапустить кластер, прежде чем он сможет использоваться для поисковых операций и хранения данных. stopped Кластер не работает, потому что он был остановлен пользователем. Это обычно не указывает ни на какую проблему как таковую, но необходимо перезапустить кластер, прежде чем это сможет использоваться любыми запросами. created Кластер был создан успешно, используя create cluster, но никогда не был использован. Необходимо запустить кластер, используя start cluster прежде, чем можно будет использовать его. unknown MySQL Cluster Manager не способен определить статус кластера. Это может и не указать на проблему с кластером, возможно, что проблема связана с одним или более агентами клиента MySQL Cluster Manager. Необходимо попытаться определить статус кластера другими средствами, такими как использование show status --process в клиенте MySQL Cluster Manager или использованием одной из команд, доступных в клиенте ndb_mgm (см. здесь), например, SHOW или ALL STATUS. Опция --operation Когда применена опция --operation (краткая форма: -o ), SHOW STATUS показывает статус последней команды, которая будет выполнена. Это включает команды, которые были даны, используя опцию --background (краткая форма -B ): mcm> show status --operation mycluster; +-----------------+-----------+--------------+ | Command | Status | Description | +-----------------+-----------+--------------+ | restart cluster | executing | <no message> | +-----------------+-----------+--------------+ 1 row in set (1.60 sec) Вывод содержит 3 колонки: 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. 4.4.7. Команда start cluster start cluster [--initial|-i] [--skip-init=process_id_list] cluster_name process_id_list: process_id[, process_id[, ...]] Эта команда запускает кластер cluster_name: mcm> start cluster mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster started successfully | +------------------------------+ 1 row in set (45.37 sec) Чтобы команда сработала, должен уже существовать кластер, названный в команде, иначе команда терпит неудачу с ошибкой Cluster cluster_name not defined: mcm> list sites; +--------+------+-------+------------------------------+ | Site | Port | Local | Hosts | +--------+------+-------+------------------------------+ | mysite | 1862 | Local | tonfisk,flundra,grindval,haj | +--------+------+-------+------------------------------+ 1 row in set (1.72 sec) mcm> list clusters mysite; +-----------+-----------+ | Cluster | Package | +-----------+-----------+ | mycluster | mypackage | +-----------+-----------+ 1 row in set (1.70 sec) mcm> start cluster yourcluster; ERROR 5001 (00MGR): Cluster yourcluster not defined Кроме того, кластер еще не должен работать: mcm> show status --cluster mycluster; +-----------+-------------------+---------+ | Cluster | Status | Comment | +-----------+-------------------+---------+ | mycluster | fully operational | | +-----------+-------------------+---------+ 1 row in set (0.01 sec) mcm> start cluster mycluster; ERROR 5005 (00MGR): Cluster mycluster is running Кластер, созданный для импорта, не может быть начат, пока импорт не был закончен. Посмотрите раздел 4.4.1 и раздел 3.5. Опция --initial Опция --initial (краткая форма: -i ) вызывает следующее: Все узлы данных кластера начаты, как будто 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. 4.4.8. Команда stop cluster stop cluster cluster_name Эта команда останавливает кластер cluster_name, если это работает: mcm> stop cluster mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster stopped successfully | +------------------------------+ 1 row in set (21.31 sec) stop cluster терпит неудачу, если кластер не находится в рабочем состоянии (см. раздел 4.4.6): mcm> show status --cluster mycluster; +-----------+---------+---------+ | Cluster | Status | Comment | +-----------+---------+---------+ | mycluster | stopped | | +-----------+---------+---------+ 1 row in set (0.01 sec) mcm> stop cluster mycluster; ERROR 5006 (00MGR): Cluster mycluster is stopped stop cluster не может использоваться на кластере, созданном для импорта, пока импорт не был закончен. Посмотрите разделы 4.4.1 и 3.5. 4.4.9. Команда autotune autotune [--dryrun] [--sequential-restart] [--writeload=writeload] template cluster_name writeload: {low|medium|high} template: {web|realtime|test} Команда настраивает много параметров для кластера, согласно указанным значениям для аргумента template и возможно опции writeload, чтобы оптимизировать работу кластера. Допустимые значения template: 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 и позже. 4.4.10. Команда upgrade cluster upgrade cluster {--package=|-P }package_name [{--nodeid|-n }node_id_list] [--force|-f] [--retry|-L] [--set=attribute_assignment_list] cluster_name node_id_list: node_id[, node_id[, ...]] attribute_assignment_list: attribute_assignment[, attribute_assignment][,...] attribute_assignment: attribute_name: process_name[= value] Эта команда модернизирует кластер cluster_name к пакету программного обеспечения package_name, определенному --package. Это заканчивает модернизацию, выполняя перезапуск для кластера, в котором узлы данных перезапущены с опцией --initial, чтобы пересоздать данные их файловых систем. Новый пакет должен быть зарегистрирован, используя add package прежде, чем можно будет использовать его для модернизации, иначе upgrade cluster терпит неудачу с ошибкой. Используя команду, чтобы выполнить модернизацию на кластере, если некоторые специальные варианты не используются (см. объяснения на опции --force, --retry и --nodeid), кластер должен быть в статусе fully operational (можно проверить это, используя команду show status --cluster cluster_name ). Кластер, созданный для импорта, не может быть модернизирован, пока импорт не был закончен. Посмотрите разделы 4.4.1 и раздел 3.5. Предположим, что mycluster использует MySQL NDB Cluster 7.4.8, двоичные модули зарегистрированы в пакете 7.4.8, как показано этой командой list clusters: mcm> list clusters mysite; +-----------+---------+ | Cluster | Package | +-----------+---------+ | mycluster | 7.4.8 | +-----------+---------+ 1 row in set (1.80 sec) Теперь вы хотите модернизировать mycluster до MySQL NDB Cluster. Предположим, что вы поместили NDB 7.6.13 в тот же самый каталог на каждом хосте, команда add package , чтобы создать новый пакет 7.6.13, который содержит эти модули, будет выглядеть примерно так: mcm> add package --basedir=/usr/local/ndb-7.6.13 7.6.13; +----------------------------+ | Command result | +----------------------------+ | Package added successfully | +----------------------------+ 1 row in set (0.88 sec) В Windows необходимо заменить любую наклонную черту влево (\) в пути, используемом для опции --basedir, наклонными чертами вправо (/). См. раздел 4.3.1. Оба пакета должны теперь быть перечислены в выводе команды list packages mysite. Чтобы выполнить модернизацию пакета 7.6.13, используйте команду upgrade cluster: mcm> upgrade cluster --package=7.6.13 mycluster; +-------------------------------+ | Command result | +-------------------------------+ | Cluster upgraded successfully | +-------------------------------+ 1 row in set (3 min 17.00 sec) Когда команда upgrade cluster была успешно выполнена, можно проверить что mycluster теперь использует пакет 7.6.13 в выводе соответствующей команды list clusters: mcm> list clusters mysite; +-----------+---------+ | Cluster | Package | +-----------+---------+ | mycluster | 7.6.13 | +-----------+---------+ 1 row in set (1.80 sec) Команда может выполнить основные, а также незначительные последовательные модернизации. Несмотря на название этой команды, upgrade cluster может также использоваться, чтобы выполнить даунгрейд MySQL NDB Cluster. Не все модернизации между различными версиями MySQL NDB Cluster поддерживаются командой. Нужно соответствовать трем критериям: Модернизация должна быть поддержана включенными версиями 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, так как команда может привести к частичной модернизации. Используйте это только когда предыдущая попытка модернизировать кластер провалилась и только с руководством от надлежащего персонала поддержки. 4.5. Команды настройки MySQL Cluster Manager Эта секция покрывает команды, используемые в 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) 4.5.1. Команда get get [--include-defaults|-d] [filter_specification_list] cluster_name filter_specification_list: filter_specification[, filter_specification][,...] filter_specification: [attribute_name] [:process_specification] [+process_specification]] process_specification: [process_name] [:process_id] process_name: {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi} Эта команда используется в клиенте MySQL Cluster Manager, чтобы получить значения атрибута конфигурации из MySQL NDB Cluster. Вывод включает следующие колонки: 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) Также возможно получить список признаков и их значений для данного типа процесса или экземпляра процесса. Для данного типа процесса используйте фильтр, имеющий форму :process_name . Например, чтобы получить все атрибуты не по умолчанию, относящиеся к процессам ndbd в кластере mycluster, можно использовать фильтр :ndbd: mcm> get :ndbd mycluster; +----------+-------------+----------+-----+----------+-----+-------+-----------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +----------+-------------+----------+-----+----------+-----+-------+-----------+ | DataDir | /opt/c2data | ndbd | 1 | | | | | | HostName | tonfisk | ndbd | 1 | | | | Read only | | NodeId | 1 | ndbd | 1 | | | | Read only | | DataDir | /opt/c3data | ndbd | 2 | | | | | | HostName | flundra | ndbd | 2 | | | | Read only | | NodeId | 2 | ndbd | 2 | | | | Read only | +----------+-------------+----------+-----+----------+-----+-------+-----------+ 6 rows in set (0.77 sec) Пример предполагает, что никакие атрибуты не установлены в значения не по умолчанию. Чтобы получить список всех признаков не по умолчанию для единственного экземпляра процесса, используйте фильтр, имеющий форму :process_name :process_id, как показано в этом примере, который получает все атрибуты не по умолчанию для процесса ndbd, где ID процесса 2: mcm> get :ndbd:2 mycluster; +----------+-------------+----------+-----+----------+-----+-------+-----------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +----------+-------------+----------+-----+----------+-----+-------+-----------+ | DataDir | /opt/c2data | ndbd | 2 | | | | | | HostName | flundra | ndbd | 2 | | | | Read only | | NodeId | 2 | ndbd | 2 | | | | Read only | +----------+-------------+----------+-----+----------+-----+-------+-----------+ 4 rows in set (0.32 sec) Если при попытке получить значения для признака, который поддерживается вашей версией MySQL NDB Cluster, вы получили пустой результат, это почти наверняка означает, что это атрибут по умолчанию, который не был изменен после того, как кластер был создан или перезагружен. Чтобы смотреть атрибуты по умолчанию, используйте get, необходимо выполнить команду, используя опцию --include-defaults (краткая форма: -d). Предположим, что вы хотите видеть, сколько DataMemory формируется для процессов ndbd в кластере mycluster и вы выполняете то, что кажется правильной командой get, но пустой результат возвращен, как показано здесь: mcm> get DataMemory:ndbd mycluster; Empty set (1.19 sec) Это означает, что атрибут DataMemory имеет свое значение по умолчанию для всех узлов данных в кластере. Если вы не помните, каково это значение, можно определить его легко, повторив ту же самую команду с добавлением опции --include-defaults ( -d): mcm> get --include-defaults DataMemory:ndbd mycluster; +------------+----------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------+----------+----------+-----+----------+-----+---------+---------+ | DataMemory | 83886080 | ndbd | 1 | | | Default | | | DataMemory | 83886080 | ndbd | 2 | | | Default | | +------------+----------+----------+-----+----------+-----+---------+---------+ 2 rows in set (0.62 sec) Теперь предположите, что вы увеличиваете DataMemory до 500 мегабайт на узел данных, затем повторите get, чтобы проверить новое значение: mcm> set DataMemory:ndbd=500M mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.77 sec) mcm> get --include-defaults DataMemory:ndbd mycluster; +------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------+-------+----------+-----+----------+-----+---------+---------+ | DataMemory | 500M | ndbd | 1 | | | Process | | | DataMemory | 500M | ndbd | 2 | | | Process | | +------------+-------+----------+-----+----------+-----+---------+---------+ 2 rows in set (1.46 sec) Вы видите, что есть не только колонка Value в выводе get показывает обновленное значение, но и Level также обновлена от Default до Process. Это означает, что вам больше не нужно указывать опцию --include-defaults, чтобы смотреть этот признак, как показано здесь: mcm> get DataMemory:ndbd mycluster; +------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------+-------+----------+-----+----------+-----+---------+---------+ | DataMemory | 500M | ndbd | 1 | | | Process | | | DataMemory | 500M | ndbd | 2 | | | Process | | +------------+-------+----------+-----+----------+-----+---------+---------+ 2 rows in set (0.63 sec) Однако, если вы перезагружаете DataMemory (также на уровне процесса), это больше не имеет место. Затем DataMemory еще раз принимает значение по умолчанию, после чего необходимо использовать опцию --include-defaults, как показано в этом примере: mcm> reset DataMemory:ndbd mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.65 sec) mcm> get DataMemory:ndbd mycluster; Empty set (1.76 sec) mcm> get --include-defaults DataMemory:ndbd mycluster; +------------+----------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------+----------+----------+-----+----------+-----+---------+---------+ | DataMemory | 83886080 | ndbd | 1 | | | Default | | | DataMemory | 83886080 | ndbd | 2 | | | Default | | +------------+----------+----------+-----+----------+-----+---------+---------+ 2 rows in set (1.01 sec) Команда get также помечает многократные атрибуты репликации в поле Comment: mcm> get replicate_ignore_table:mysqld mycluster; +------------------------+--------------+----------+---------+----------+---------+---------+-------------+ | Name | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment | +------------------------+--------------+----------+---------+----------+---------+---------+-------------+ | replicate_ignore_table | mydb.t1 | mysqld | 50 | | | | Multi-entry | | replicate_ignore_table | mydb.t50 | mysqld | 50 | | | | Multi-entry | | replicate_ignore_table | mydb.mytable | mysqld | 50 | | | Process | Multi-entry | | replicate_ignore_table | mydb.t51 | mysqld | 51 | | | | Multi-entry | | replicate_ignore_table | mydb.mytable | mysqld | 51 | | | Process | Multi-entry | +------------------------+--------------+----------+---------+----------+---------+---------+-------------+ 5 rows in set (0.05 sec) О том, как перезагрузить многократные атрибуты посмотрите раздел 4.5.2. Команда get обычно не показывает атрибуты конфигурации, относящиеся к TCP или связям SHM. Однако, такие атрибуты могут быть установлены в клиенте MySQL Cluster Manager (командой set), как только они были установлены, они будут показаны командой get. 4.5.2. Команда reset reset [--sequential-restart] filter_specification_list cluster_name filter_specification_list: filter_specification[, filter_specification][,...] filter_specification: attribute_name[: process_specification] [+process_specification]] process_specification: [process_name] [:process_id] process_name: {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi} Эта команда перезагружает признак к его значению по умолчанию. Атрибуты могут быть установлены на уровне процесса или на уровне экземпляра. Чтобы перезагрузить признак на уровне процесса, используйте спецификацию фильтра, имеющую форму attribute_name :process_name, где attribute_name это имя признака, который будет перезагружен, а process_name это имя процесса MySQL NDB Cluster. Чтобы перезагрузить признак конфигурации на уровне экземпляра, используйте спецификацию фильтра формы attribute_name :process_name: process_id, где process_id это ID процесса. Вы не можете использовать команду reset, чтобы перезагрузить все значения для данного признака конфигурации независимо от типа процесса, каждая команда reset должна определить тип процесса или экземпляр процесса. Иначе команда терпит неудачу, как показано здесь: mcm> reset DataMemory mycluster; ERROR 3 (00MGR): Illegal syntax Вы также не можете инвертировать все атрибуты конфигурации для данного типа процесса или экземпляра процесса, используя единственную спецификацию фильтра, необходимо всегда включать название признака, который будет перезагружен. Иначе команда reset терпит неудачу, как показано здесь: mcm> reset :ndbd mycluster; ERROR 3 (00MGR): Illegal syntax mcm> reset :ndbd:3 mycluster; ERROR 3 (00MGR): Illegal syntax Предположим, что память данных для всех процессов ndbd в кластере mycluster была установлена в 500 МБ, как показано в выводе этой команды get: mcm> get DataMemory mycluster; +------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------+-------+----------+-----+----------+-----+---------+---------+ | DataMemory | 500M | ndbd | 2 | | | Process | | | DataMemory | 500M | ndbd | 3 | | | Process | | +------------+-------+----------+-----+----------+-----+---------+---------+ 2 rows in set (1.91 sec) Мы видим из записей в столбце Level, что DataMemory задан для обоих процессов ndbd на уровне процесса. Значение уровня процесса не может быть перезагружено на уровне экземпляра, как показано здесь: mcm> reset DataMemory:ndbd:2 mycluster; ERROR 6010 (00MGR): No matching user defined setting was found for config attribute DataMemory mcm> reset DataMemory:ndbd:3 mycluster; ERROR 6010 (00MGR): No matching user defined setting was found for config attribute DataMemory Следующая команда reset также не сработает, хотя вы могли бы думать, что она попытается перезагрузить значение признака для обоих процессов ndbd: mcm> reset DataMemory:ndbd:2,DataMemory:ndbd:3 mycluster; ERROR 6010 (00MGR): No matching user defined setting was found for config attribute DataMemory Предыдущая команда терпит неудачу, потому что MySQL Cluster Manager рассматривает это как попытку применить два изменения конфигурации уровня экземпляра. Поскольку настройка DataMemory является параметром уровня процесса, необходимо вместо этого перезагрузить DataMemory к его значению по умолчанию на уровне процесса, можно сделать это при помощи спецификации фильтра DataMemory:ndbd в команде reset: mcm> reset DataMemory:ndbd mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (6.16 sec) Если вы выполняете команду get как показано ранее, результат теперь будет пуст: mcm> get DataMemory mycluster; Empty set (0.74 sec) Это потому что команда get по умолчанию не сообщает о значениях по умолчанию. Чтобы получить DataMemory после сброса, необходимо вызвать get с опцией --include-defaults (краткая форма: -d): mcm> get --include-defaults DataMemory mycluster; +------------+----------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------+----------+----------+-----+----------+-----+---------+---------+ | DataMemory | 83886080 | ndbd | 2 | | | Default | | | DataMemory | 83886080 | ndbd | 3 | | | Default | | +------------+----------+----------+-----+----------+-----+---------+---------+ 2 rows in set (1.21 sec) Значения DataMemory теперь включены в вывод и отмечены словом Default в столбце Comments. Теперь предположите, что атрибут конфигурации mysqld wait_timeout для процесса mysqld с ID 4 кластера mycluster был ранее установлен в значение value 200 и что никакие другие изменения не были применены к этому признаку: mcm> set wait_timeout:mysqld:4=200 mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.78 sec) mcm> get -d wait_timeout:mysqld:4 mycluster; +--------------+-------+----------+-----+----------+-----+-------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +--------------+-------+----------+-----+----------+-----+-------+---------+ | wait_timeout | 200 | mysqld | 4 | | | | | +--------------+-------+----------+-----+----------+-----+-------+---------+ 1 row in set (0.98 sec) Поскольку колонка Level пуста, мы знаем, что это применяется на уровне экземпляра. При попытке перезагрузить атрибут на уровне процесса, попытка терпит неудачу, как показано здесь: mcm> reset wait_timeout:mysqld mycluster2; ERROR 6010 (00MGR): No matching user defined setting was found for config attribute wait_timeout Если вы хотите перезагрузить этот признак к его значению по умолчанию, необходимо использовать команду reset с уровнем экземпляра wait_timeout:mysqld:4: mcm> reset wait_timeout:mysqld:4 mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.6 sec) Как только вы перезагрузили wait_timeout, это больше не появляется в выводе get: mcm> get wait_timeout:mysqld mycluster; Empty set (1.42 sec) Это потому, что поведение по умолчанию get должно показать только те значения, которые были установлены MySQL Cluster Manager или пользователем. С тех пор, как wait_timeout был возвращен к его значению по умолчанию, необходимо использовать опцию --include-defaults (краткая форма: -d), чтобы получить его, как показано здесь: mcm> get -d wait_timeout:mysqld mycluster; +--------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +--------------+-------+----------+-----+----------+-----+---------+---------+ | wait_timeout | 28800 | mysqld | 4 | | | Default | | +--------------+-------+----------+-----+----------+-----+---------+---------+ 1 row in set (1.66 sec) Теперь рассмотрите ситуацию, в которой уровень процесса и параметры настройки уровня экземпляра были сделаны к признаку конфигурации, в этом примере мы используем IndexMemory. Сначала проверьте, что IndexMemory установлен в его значение по умолчанию для всех процессов узла данных (в этом случае есть два из них): mcm> get -d IndexMemory mycluster; +-------------+----------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +-------------+----------+----------+-----+----------+-----+---------+---------+ | IndexMemory | 18874368 | ndbd | 2 | | | Default | | | IndexMemory | 18874368 | ndbd | 3 | | | Default | | +-------------+----------+----------+-----+----------+-----+---------+---------+ 2 rows in set (1.24 sec) Теперь примените изменение уровня процесса и изменение уровня экземпляра этого признака. Можно сделать это одной командой set: mcm> set IndexMemory:ndbd=500M,IndexMemory:ndbd:3=750M mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.29 sec) Поскольку изменение уровня процесса было определено сначала, оно отвергнуто для процесса ndbd изменением уровня экземпляра, определенным позже. Вывод от следующей команды get подтверждает, что дело обстоит так: mcm> get IndexMemory mycluster; +-------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +-------------+-------+----------+-----+----------+-----+---------+---------+ | IndexMemory | 500M | ndbd | 2 | | | Process | | | IndexMemory | 750M | ndbd | 3 | | | | | +-------------+-------+----------+-----+----------+-----+---------+---------+ 2 rows in set (0.85 sec) Если уровень экземпляра IndexMemory для процесса ndbd с ID процесса 3 перезагружается, уровень процесса все еще, применяется, как показано здесь: mcm> reset IndexMemory:ndbd:3 mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (6.4 sec) mcm> get IndexMemory mycluster; +-------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +-------------+-------+----------+-----+----------+-----+---------+---------+ | IndexMemory | 500M | ndbd | 2 | | | Process | | | IndexMemory | 500M | ndbd | 3 | | | Process | | +-------------+-------+----------+-----+----------+-----+---------+---------+ 2 rows in set (1.09 sec) Теперь повторно используйте уровень экземпляра IndexMemory и используйте get, чтобы проверить, что это вступило в силу: mcm> set IndexMemory:ndbd:3=750M mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (6.79 sec) mcm> get IndexMemory mycluster; +-------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +-------------+-------+----------+-----+----------+-----+---------+---------+ | IndexMemory | 500M | ndbd | 2 | | | Process | | | IndexMemory | 750M | ndbd | 3 | | | | | +-------------+-------+----------+-----+----------+-----+---------+---------+ 2 rows in set (1.76 sec) Если вы перезагружаете настройку уровня процесса, настройка уровня экземпляра остается, и только процесс ndbd с ID процесса 2 имеет IndexMemory сброшенный к значению по умолчанию, настройка уровня экземпляра остается в силе, как вы видите из следующей последовательности команд: mcm> reset IndexMemory:ndbd mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.36 sec) mcm> get -d IndexMemory mycluster; +-------------+----------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +-------------+----------+----------+-----+----------+-----+---------+---------+ | IndexMemory | 18874368 | ndbd | 2 | | | Default | | | IndexMemory | 750M | ndbd | 3 | | | | | +-------------+----------+----------+-----+----------+-----+---------+---------+ 2 rows in set (0.10 sec) Если порядок спецификаторов в оригинальной команде, которые устанавливают IndexMemory был полностью изменен, как IndexMemory:ndbd:3=750M,IndexMemory:ndbd=500M, изменение уровня экземпляра было бы отвергнуто изменением уровня процесса и IndexMemory для обоих процессов ndbd был 500M. Команды get и reset полностью поддерживают многократные атрибуты репликации, например, если у признака replicate_ignore_table есть много входов: mcm> get replicate_ignore_table:mysqld mycluster; +------------------------+--------------+----------+---------+----------+---------+---------+-------------+ | Name | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment | +------------------------+--------------+----------+---------+----------+---------+---------+-------------+ | replicate_ignore_table | mydb.t1 | mysqld | 50 | | | | Multi-entry | | replicate_ignore_table | mydb.t50 | mysqld | 50 | | | | Multi-entry | | replicate_ignore_table | mydb.mytable | mysqld | 50 | | | Process | Multi-entry | | replicate_ignore_table | mydb.t51 | mysqld | 51 | | | | Multi-entry | | replicate_ignore_table | mydb.mytable | mysqld | 51 | | | Process | Multi-entry | +------------------------+--------------+----------+---------+----------+---------+---------+-------------+ 5 rows in set (0.05 sec) Не определяя ID узла, все записи признака, связанные с указанным типом процесса, перезагружаются со следующей командой: mcm> reset replicate_ignore_table:mysqld mycluster; # removes all process level entries +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (0.47 sec) mcm> get replicate_ignore_table:mysqld mycluster; +------------------------+----------+----------+---------+----------+---------+-------+-------------+ | Name | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment | +------------------------+----------+----------+---------+----------+---------+-------+-------------+ | replicate_ignore_table | mydb.t1 | mysqld | 50 | | | | Multi-entry | | replicate_ignore_table | mydb.t50 | mysqld | 50 | | | | Multi-entry | | replicate_ignore_table | mydb.t51 | mysqld | 51 | | | | Multi-entry | +------------------------+----------+----------+---------+----------+---------+-------+-------------+ 3 rows in set (0.08 sec) С определенным ID узла только записи экземпляра, связанные с узлом с этим ID, перезагружаются следующей командой: mcm> reset replicate_ignore_table:mysqld:51 mycluster; # removes all instance level entries for nodeid 51 +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (0.57 sec) mcm> get replicate_ignore_table:mysqld mycluster; +------------------------+----------+----------+---------+----------+---------+-------+-------------+ | Name | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment | +------------------------+----------+----------+---------+----------+---------+-------+-------------+ | replicate_ignore_table | mydb.t1 | mysqld | 50 | | | | Multi-entry | | replicate_ignore_table | mydb.t50 | mysqld | 50 | | | | Multi-entry | +------------------------+----------+----------+---------+----------+---------+-------+-------------+ 2 rows in set (0.09 sec) Команды reset выполняются, был ли кластер запущен или нет. В кластере, который не работает, MySQL Cluster Manager просто обновляет конфигурационные файлы. Однако, в работающем кластере MySQL Cluster Manager кроме того автоматически выполняет любые перезапуски узла или всего кластера, которые требуются, чтобы заставлять изменения признака вступать в силу. Для MySQL Cluster Manager 1.4.8 и позже: используйте опцию --sequential-restart, чтобы сделать перезапуск кластера последовательным). Однако, так как операции по перезапуску могут занять много времени, предпочтительно сделать изменения конфигурации прежде, чем запустить кластер. Сброс признаков соединения по протоколу TCP. Определенные атрибуты конфигурации, такие как те, которые касаются соединений по протоколу TCP, относятся к связям между процессами, а не к отдельным процессам или отдельным типам процесса. Как показано в другом месте (см. здесь), когда вы устанавливаете такой признак уровня процесса с использованием MySQL Cluster Manager, это означает, что признак относится ко всем связям между двумя типами процессов, определенных командой set. Также возможно установить такой признак на уровне экземпляра, в этом случае это применяется только к единственной связи между двумя экземплярами процесса. Точно так же возможно перезагрузить такой признак на уровне процесса или экземпляра, в зависимости от уровня или уровней, на которых это было установлено. В любом случае требуется расширенная форма спецификатора процесса, устанавливая признак, который относится к связи между процессами. Предположите, что параметр SendBufferMemory был ранее установлен для всех связей между двумя процессами ndbd и двумя процессами mysqld, которые работают в MySQL NDB Cluster с именем mycluster2: mcm> get SendBufferMemory mycluster2; +------------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------------+-------+----------+-----+----------+-----+---------+---------+ | SendBufferMemory | 4M | ndbd | 2 | mysqld | 4 | Process | | | SendBufferMemory | 4M | ndbd | 2 | mysqld | 5 | Process | | | SendBufferMemory | 4M | ndbd | 3 | mysqld | 4 | Process | | | SendBufferMemory | 8M | ndbd | 3 | mysqld | 5 | | | +------------------+-------+----------+-----+----------+-----+---------+---------+ 4 rows in set (0.59 sec) Предположим, что вы хотите перезагрузить SendBufferMemory только для связи между процессом ndbd с ID 3 и процессом mysqld с ID 5. Значение SendBufferMemory, которое относится к этой связи, определяется на уровне экземпляра, потому что значение столбца Level, соответствующее этой связи, пусто, это означает, что возможно перезагрузить это значение на уровне экземпляра. Можно сделать это использованием reset: mcm> reset SendBufferMemory:ndbd:3+mysqld:5 mycluster2; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.03 sec) Можно проверить, что признак был перезагружен, используя команду get. Однако, как отмечено ранее, как только настройка уровня экземпляра была удалена, настройка уровня процесса для этого признака снова вступает в силу, чтобы то же самое значение относилось ко всем связям между процессами ndbd и mysqld: mcm> get SendBufferMemory mycluster2; +------------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------------+-------+----------+-----+----------+-----+---------+---------+ | SendBufferMemory | 4M | ndbd | 2 | mysqld | 4 | Process | | | SendBufferMemory | 4M | ndbd | 2 | mysqld | 5 | Process | | | SendBufferMemory | 4M | ndbd | 3 | mysqld | 4 | Process | | | SendBufferMemory | 4M | ndbd | 3 | mysqld | 5 | Process | | +------------------+-------+----------+-----+----------+-----+---------+---------+ 4 rows in set (0.87 sec) Чтобы перезагрузить этот признак на уровне процесса, можно использовать следующую команду reset: mcm> reset SendBufferMemory:ndbd+mysqld mycluster2; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (8.01 sec) Можно проверить, что признак был перезагружен для всех связей между процессами ndbd и mysqld, используя команду get: mcm> get -d SendBufferMemory mycluster2; Empty set (1.39 sec) Как отмечено в другом месте в этом руководстве (см. раздел 4.5.1), пустой набор результатов должен ожидаться в этом случае, даже когда get вызвана, используя опцию --include-defaults (или -d), так как клиент MySQL Cluster Manager не показывает атрибутов, которые появляются в разделах [tcp] или [shm] файла config.ini, если они не были явно установлены пользователем. 4.5.3. Команда set set [--sequential-restart] attribute_assignment_list cluster_name attribute_assignment_list: attribute_assignment[, attribute_assignment][,...] attribute_assignment: attribute_name: process_specification [+process_specification][=value] process_specification: [process_name][: process_id] process_name: {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi} Эта команда используется, чтобы установить значения для одного или более признаков конфигурации. Атрибуты могут быть установлены на уровне процесса или на уровне экземпляра. Команды set выполняются безотносительно запуска кластера. В кластере, который не работает, MySQL Cluster Manager просто обновляет конфигурационные файлы. Однако, в работающем кластере MySQL Cluster Manager кроме того автоматически выполняет любые перезапуски узла или всего кластера (см. здесь), которые требуются, чтобы заставлять изменения признака вступать в силу (в MySQL Cluster Manager 1.4.8 и позже используйте опцию --sequential-restart, чтобы сделать перезапуск последовательным. Однако, так как операции по перезапуску, особенно для всего кластера, могут занять много времени, предпочтительно сделать изменения конфигурации прежде, чем запустить кластер и поместить его в рабочую среду. Чтобы установить признак на уровне процесса, используйте set, которая содержит назначение признака, имеющее форму attribute_name: process_name= value. Например, чтобы установить DataMemory в 500 MB на уровне процесса ndbd, чтобы новое значение относилось ко всем процессам ndbd кластера, вы можете использовать команду set, содержащую назначение признака DataMemory:ndbd=500M: mcm> set DataMemory:ndbd=500M mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (5.68 sec) Чтобы проверить, что новое значение используется, можно применить команду get: mcm> get DataMemory mycluster; +------------+-------+----------+------+----------+------+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------+-------+----------+------+----------+------+---------+---------+ | DataMemory | 500M | ndbd | 1 | | | Process | | | DataMemory | 500M | ndbd | 2 | | | Process | | +------------+-------+----------+------+----------+------+---------+---------+ 2 rows in set (0.79 sec) См. раздел 4.5.1. Чтобы установить признак для определенного экземпляра процесса, включайте ID процесса в назначение признака, форма такого назначения признака attribute_name: process_name: process_id= value. Например, чтобы установить признак wait_timeout для процесса mysqld с ID 50 в 200, надо указать назначение признака wait_timeout:mysqld:51=200: mcm> set wait_timeout:mysqld:50=200 mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (6.18 sec) Можно проверить, что назначение вступило в силу, используя применимую команду get: mcm> get wait_timeout mycluster; +--------------+-------+----------+------+----------+------+-------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +--------------+-------+----------+------+----------+------+-------+---------+ | wait_timeout | 200 | mysqld | 50 | | | | | +--------------+-------+----------+------+----------+------+-------+---------+ 1 row in set (0.50 sec) Атрибуты, которые отмечены Read only нельзя менять. Попытка это сделать терпит неудачу с ошибкой, как показано здесь: mcm> get :ndbd mycluster; +----------+-------------+----------+-----+----------+-----+-------+-----------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +----------+-------------+----------+-----+----------+-----+-------+-----------+ | DataDir | /opt/c2data | ndbd | 1 | | | | | | HostName | tonfisk | ndbd | 1 | | | | Read only | | NodeId | 2 | ndbd | 1 | | | | Read only | | DataDir | /opt/c3data | ndbd | 2 | | | | | | HostName | grindval | ndbd | 2 | | | | Read only | | NodeId | 3 | ndbd | 2 | | | | Read only | +----------+-------------+----------+-----+----------+-----+-------+-----------+ 6 rows in set (1.42 sec) mcm> set HostName:ndbd:1=lax mycluster; ERROR 6008 (00MGR): Config attribute HostName is read only and cannot be changed Однако, можно установить обязательные атрибуты, как в примере, показанном ранее в этой секции, где признак конфигурации DataDir был установлен в определенное пользователями значение. Обязательный атрибут NoOfReplicas должен быть установлен только на уровне процесса. Попытка установить его на уровне экземпляра может оставить кластер, MySQL Cluster Manager или обоих в непригодной конфигурации. В отличие от экземпляра с командой get, вы не можете использовать command, you cannot issue a set, действуя на глобальную область видимости то есть, вы не можете в единственном назначении признака устанавливать единственное значение для признака, таким образом, что новое значение атрибута относится ко всем процессам, независимо от типа процесса, даже если признак, имеющий это имя, может быть применен ко всем типам процесса. При этом вы не можете определить много типов процесса в единственном назначении признака. Пытаясь сделать любую из этих вещей, вы получите ошибку, как показано здесь: mcm> set DataDir=/var/cluster-data mycluster; ERROR 3 (00MGR): Illegal syntax mcm> set DataDir:ndb_mgmd,ndbd,mysqld=/var/cluster-data mycluster; ERROR 3 (00MGR): Illegal syntax Вместо этого необходимо использовать назначение признака уровня процесса на каждый тип процесса. Однако, вы не обязательно обязаны давать отдельную команду для каждого типа процесса. Вместо этого можно также сделать мног назначений признака в одной команде set, поставляя назначения как список разделенных запятой значений. Эта команда set назначает /var/cdata как каталог данных (DataDir) для всех процессов MySQL NDB Cluster в mycluster: mcm> set DataDir:ndb_mgmd=/var/cdata, \ DataDir:ndbd=/var/cdata, \ DataDir:mysqld=/var/cdata mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.66 sec) mcm> get DataDir mycluster; +---------+------------+----------+---------+----------+---------+-------+---------+ | Name | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment | +---------+------------+----------+---------+----------+---------+-------+---------+ | DataDir | /var/cdata | ndbmtd | 1 | | | | | | DataDir | /var/cdata | ndbmtd | 2 | | | | | | DataDir | /var/cdata | ndb_mgmd | 49 | | | | | | datadir | /var/cdata | mysqld | 50 | | | | | | datadir | /var/cdata | mysqld | 51 | | | | | +---------+------------+----------+---------+----------+---------+-------+---------+ 5 rows in set (0.08 sec) Как вы видите из команды get, назначения признака были успешны и вступили в силу на уровне процесса. В MySQL Cluster Manager названия атрибута конфигурации нечувствительны к регистру. Посмотрите здесь подробности. Точно так же вы не можете сослаться на много ID процессов в единственном назначении признака, даже если это процессы того же самого типа, следующая команда не работает: mcm> set DataMemory:ndbd:1,2=750M mycluster; ERROR 3 (00MGR): Illegal syntax Вместо этого необходимо было бы использовать следующую команду: mcm> set DataMemory:ndbd:1=750M,DataMemory:ndbd:2=750M mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.70 sec) Конечно, если это только два узла данных в mycluster, команда set DataMemory:ndbd=750M mycluster также выполняет ту же самую задачу. Несколько признаков конфигурации относятся к связям между процессами и требуют, чтобы вы обратились к обоим процессам в ходе их урегулирования. В таких экземплярах необходимо использовать специальный синтаксис спецификации процесса, посмотрите здесь. Вы также не можете установить значения для многих признаков в единственном назначении признака, это означает, что следующие команды не сработают: mcm> set UndoDataBuffer=32M,UndoIndexBuffer=8M:ndbd mycluster; ERROR 3 (00MGR): Illegal syntax mcm> set DataMemory,IndexMemory:ndbd=1G mycluster; ERROR 3 (00MGR): Illegal syntax Однако, если вы пишете полное и действительное назначение признака на каждый признак, значение которого вы хотите обновить, можно переписать эти две команды так, чтобы они выполнились успешно, как показано здесь: mcm> set UndoDataBuffer:ndbd=32M,UndoIndexBuffer:ndbd=8M mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (6.62 sec) mcm> set DataMemory:ndbd=1G,IndexMemory:ndbd=1G mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.04 sec) На самом деле нет никакой причины, что вы не можете выполнить все четыре назначения одной командой set, используя список из четырех назначений признака: mcm> set UndoDataBuffer:ndbd=32M,UndoIndexBuffer:ndbd=8M, \ DataMemory:ndbd=1G, IndexMemory:ndbd=1G mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (6.24 sec) Однако, хорошая идея не выполнить слишком много назначений признака одной командой set, так как это делает более трудным определить ошибки. В Windows, устанавливая атрибуты, значения которых содержат пути (например, DataDir), необходимо заменить любые знаки наклонной черты влево в пути наклонными чертами вправо. Предположим, что вы хотите использовать C:\temp\node50 для атрибута tmpdir в процессе mysqld с ID 50 в MySQL NDB Cluster mycluster, который работает под Windows. Исходное значение для этого признака может быть найдено через get : mcm> get tmpdir mycluster; +--------+----------------+----------+-----+----------+-----+-------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +--------+----------------+----------+-----+----------+-----+-------+---------+ | tmpdir | c:\c50data\tmp | mysqld | 50 | | | | | +--------+----------------+----------+-----+----------+-----+-------+---------+ 1 row in set (0.22 sec) Правильная команда set, чтобы сделать желаемое изменение конфигурации: mcm> set tmpdir:mysqld:50=c:/temp/node50 mycluster; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (2.62 sec) Когда вы проверяете использование значения get даже при том, что это первоначально указали, используя наклонные черты влево, наклонные черты вправо используются, показывая новое значение: mcm> get tmpdir mycluster; +--------+----------------+----------+-----+----------+-----+-------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +--------+----------------+----------+-----+----------+-----+-------+---------+ | tmpdir | c:/temp/node50 | mysqld | 50 | | | | | +--------+----------------+----------+-----+----------+-----+-------+---------+ 1 row in set (0.22 sec) Однако, при попытке использовать наклонные черты влево в пути в команде set команда терпит неудачу: mcm> set tmpdir:mysqld:4=c:\temp\4 mycluster; Outfile disabled. ERROR: Unknown command '\4'. ERROR 6014 (00MGR): Path name for parameter tmpdir must be absolute. The value 'c:mp4' is illegal. Урегулирование признаков соединения по протоколу TCP. Для нескольких признаков, которые применяются только используя соединения по протоколу TCP (например, SendBufferMemory и ReceiveBufferMemory) необходимо использовать измененный синтаксис для назначений значения атрибута. В этом случае назначение признака содержит два технических требований процесса, один для каждого типа процесса или экземпляра, к которому урегулирование применяется, объединяемых знаком плюс (+). Для следующего примера считайте кластер mycluster2 состоящим из процессов, показанных здесь: mcm> list processes mycluster2; +----+----------+----------+ | Id | Name | Host | +----+----------+----------+ | 49 | ndb_mgmd | grindval | | 1 | ndbd | tonfisk | | 2 | ndbd | flundra | | 50 | mysqld | haj | | 51 | mysqld | torsk | +----+----------+----------+ 5 rows in set (0.16 sec) См. раздел 4.6.3. Атрибуты соединения по протоколу TCP не показывают в выводе команды get, если они не были установлены. Это означает, что до указания SendBufferMemory впервые, вы получаете пустой результат при попытке получить его значение, как показано здесь: mcm> get SendBufferMemory mycluster2; Empty set (0.18 sec) mcm> get --include-defaults SendBufferMemory mycluster2; Empty set (0.93 sec) Чтобы установить параметр SendBufferMemory в 4 MB для всех соединений по протоколу TCP между узлами данных и узлами SQL, можно использовать команду, показанную здесь: mcm> set SendBufferMemory:ndbd+mysqld=4M mycluster2; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (6.44 sec) Если вы проверяете значение признака впоследствии, используя get, вы видите, что значение применяется ко всем возможным связям между каждым из двух процессов ndbd и каждым из двух процессов mysqld в mycluster2, таким образом в выводе есть четыре строки: mcm> get SendBufferMemory mycluster2; +------------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------------+-------+----------+-----+----------+-----+---------+---------+ | SendBufferMemory | 4M | ndbd | 2 | mysqld | 4 | Process | | | SendBufferMemory | 4M | ndbd | 2 | mysqld | 5 | Process | | | SendBufferMemory | 4M | ndbd | 3 | mysqld | 4 | Process | | | SendBufferMemory | 4M | ndbd | 3 | mysqld | 5 | Process | | +------------------+-------+----------+-----+----------+-----+---------+---------+ 4 rows in set (1.63 sec) Чтобы сменить эту настройку только для связи между узлом данных с ID процесса 2 и процессом mysqld (ID процесса 4), можно включать ID процесса в каждую из двух частей спецификации процесса, как показано здесь: mcm> set SendBufferMemory:ndbd:2+mysqld:4=8M mycluster2; +-----------------------------------+ | Command result | +-----------------------------------+ | Cluster reconfigured successfully | +-----------------------------------+ 1 row in set (7.95 sec) Когда вы проверяете результат, используя get, вы видите, что новое значение применяется на уровне экземпляра и только к связи между процессами, имеющими ID 2 и 4, настройка уровня процесса, сделанная ранее, все еще относится к оставшимся 3 связям: mcm> get SendBufferMemory mycluster2; +------------------+-------+----------+-----+----------+-----+---------+---------+ | Name | Value | Process1 | Id1 | Process2 | Id2 | Level | Comment | +------------------+-------+----------+-----+----------+-----+---------+---------+ | SendBufferMemory | 8M | ndbd | 2 | mysqld | 50 | | | | SendBufferMemory | 4M | ndbd | 2 | mysqld | 51 | Process | | | SendBufferMemory | 4M | ndbd | 3 | mysqld | 50 | Process | | | SendBufferMemory | 4M | ndbd | 3 | mysqld | 51 | Process | | +------------------+-------+----------+-----+----------+-----+---------+---------+ 4 rows in set (0.24 sec) Вы не можете установить признак связи на уровне процесса в одной части спецификации процесса (то есть, для одного конца связи) и на уровне экземпляра в другом. Попытка сделать так терпит неудачу с ошибкой, как показано здесь: mcm> set SendBufferMemory:ndbd+mysqld:4=2M mycluster2; ERROR 3 (00MGR): Illegal syntax mcm> set SendBufferMemory:ndbd:2+mysqld=2M mycluster2; ERROR 3 (00MGR): Illegal syntax Урегулирование признаков для узлов mysqld. Когда динамическая переменная установлена, mcmd отсылает запрос SET GLOBAL mysqld, чтобы применить значение, а также сохраняет значение в конфигурационный файл mysqld, таким образом, значение может быть применено снова при следующем перезапуске mysqld, однако, непосредственный перезапуск вызывается, когда нединамическая переменная установлена. Настройка пула соединений mysqld. Предоставление возможности объединения связи для mysqld может быть сделано, установив параметр ndb-cluster-connection-pool к желаемому количеству связей, но также требует дополнительного шага в создании кластера. Так как процесс mysqld пытается установить многократные связи с кластером, когда объединение связи позволено, кластер должна формироваться с запасными или пустыми соединениями. Можно сделать это, добавив (в других отношениях) не используемую запись ndbapi в список process_host, используемом в create cluster: mcm> create cluster -P mypackage \ > -R ndb_mgmd@10.100.10.97,ndbd@10.100.10.98,ndbd@10.100.10.99, \ mysqld@10.100.10.100,ndbapi@10.100.10.100, \ ndbapi@10.100.10.100,ndbapi@10.100.10.100 mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster created successfully | +------------------------------+ 1 row in set (6.58 sec) После этого можно использовать команду set, чтобы установить размер пула связи согласно количеству избыточных связей, доступных в файле config.ini: mcm> set ndb_cluster_connection_pool:mysqld=4; Атрибут user не поддержан для mysqld. Попытка установить параметр user для процесса mysqld в настоящее время не поддерживается и приводит к предупреждению, написанному в журнал MySQL Cluster Manager. 4.6. Команды процессов MySQL Cluster Manager Эта секция содержит информацию о командах клиента MySQL Cluster Manager, которые начинают и останавливают процессы MySQL NDB Cluster, а также определяют, какие процессы в настоящее время работают. MySQL Cluster Manager, ndb_mgm и старт или остановка процессов. Для управления MySQL NDB Cluster из MySQL Cluster Manager рекомендуется не применять клиент ndb_mgm, который идет в дистрибутиве MySQL NDB Cluster, чтобы выполнить операции, которые включают старт или остановку узлов. Они включают, но не ограничиваются следующими командами клиента: START STOP RESTART SHUTDOWN 4.6.1. Команда add process add process {--processhosts=|-R }process_host_list [--set=attribute_assignment_list] [--verbose | -v] [--sequential-restart] cluster_name process_host_list: process_name[: node_id]@host[, process_name@host[,...]] process_name: {ndb_mgmd|ndbd|ndbmtd|mysqld|ndbapi} attribute_assignment_list: attribute_assignment[, attribute_assignment][, ...] attribute_assignment: attribute_name: process_name[= value] Эта команда добавляет к существующему кластеру один или несколько процессов, которые определяются, используя process_host_list с опцией --processhosts, формат которой совпадает с используемым в create cluster . Любые хосты, на которые ссылаются в списке, должны быть зарегистрированными в месте, которому принадлежит кластер. Кроме того, все хосты должны быть разрешимыми. Например, следующая команда add process добавляет два процесса mysqld на хостах tonfisk и flundra в кластер mycluster: mcm> add process --processhosts=mysqld@tonfisk,mysqld@flundra mycluster; +------------------------------+ | Command result | +------------------------------+ | Processes added successfully | +------------------------------+ 1 row in set (2 min 10.39 sec) С опцией --verbose команда показывает обновленный список процессов, после того, как новые процессы были добавлены: mcm> add process --processhosts=ndbmtd@tonfisk,ndbmtd@flundra --verbose mycluster; +--------+----------+---------+ | NodeId | Name | Host | +--------+----------+---------+ | 49 | ndb_mgmd | tonfisk | | 53 | ndb_mgmd | flundra | | 1 | ndbmtd | tonfisk | | 2 | ndbmtd | flundra | | 3 | ndbmtd | tonfisk | | 4 | ndbmtd | flundra | | 50 | mysqld | tonfisk | | 51 | mysqld | flundra | | 52 | ndbapi | * | +--------+----------+---------+ 9 rows in set (2 min 7.57 sec) Можно также вручную назначить узлу ID на новый процесс, который вы добавляете к кластеру, добавляя : node_ID после process_name. MySQL Cluster Manager 1.3.3 и ранее, пытаясь вручную назначить узлу ID меньше, чем 49 для 49 for ndb_mgmd, mysqld, или ndbapi, вылетает с ошибкой, ограничение, однако, было снято начиная с MySQL Cluster Manager 1.3.4. Тем не менее, вам все еще рекомендуют применить наиболее успешную практику сохранения ID узла от 1 до 48 для узлов данных. Следующая команда добавляет два процесса ndbd с ID узлов 10 и 11 на хостах tonfisk и flundra, соответственно, к mycluster: mcm> add process --processhosts=ndbd:10@tonfisk,ndbd:11@flundra mycluster; +------------------------------+ | Command result | +------------------------------+ | Processes added successfully | +------------------------------+ 1 row in set (2 min 13.40 sec) NDB 8.0 поддерживает до 144 узлов данных (для выпуска 8.0.18 и позже). Управляя кластером NDB 8.0, вам рекомендуют применить наиболее успешную практику сохранения ID узла от 1 до 144 для узлов данных. Если кластер не работает, когда вы выполняете add process , рекомендуется, чтобы вы запустили все новые процессы, добавленные этой командой, вместе, используя start process --added или запустили их вместе с кластером, используя команду start cluster . Помимо старта узлов, любая из двух команд также инициализирует добавленные узлы и заставляет новую группу узлов кластера быть сформированной через команду CREATE NODEGROUP. Если добавленные узлы начаты с помощью start process --initial, вы тогда обязаны выполнить CREATE NODEGROUP вручную через клиент ndb_mgm. Если кластер работает, когда вы выполняете add process , перезапуск для кластера выполняется в конце add process . MySQL Cluster Manager 1.4.8 и позже : используйте опцию --sequential-restart, чтобы сделать перезапуск последовательным. Добавление свободных процессов Используя add process, можно добавить неуправляемые процессы mysqld или слоты ndbapi для приложений ndbapi, таких как ndb_restore. Чтобы добавить неуправляемый процесс mysqld, укажите имя хоста с подстановочным знаком * (символ звездочки): mcm> add process --processhosts=mysqld@*tonfisk,mysqld@*flundra mycluster; +------------------------------+ | Command result | +------------------------------+ | Processes added successfully | +------------------------------+ 1 row in set (2 min 3.14 sec) Чтобы позволить неуправляемым узлам mysqld соединяться от любого хоста, используйте подстановочный знак * (символ звездочки) вместо имени хоста или IP-адреса: mcm> add process --processhosts=mysqld@*,mysqld@* mycluster; +------------------------------+ | Command result | +------------------------------+ | Processes added successfully | +------------------------------+ 1 row in set (2 min 3.14 sec) То же самое относится к слотам ndbapi для приложений ndbapi: укажите имя хоста с подстановочным символом, чтобы ограничить возможность соединения определенным хостом или используйте только подстановочный знак без имени хоста, чтобы позволить приложение ndbapi от любого хоста: mcm> add process --processhosts=ndbapi@*tonfisk,ndbapi@* mycluster; +------------------------------+ | Command result | +------------------------------+ | Processes added successfully | +------------------------------+ 1 row in set (2 min 8.13 sec) Поскольку свободные процессы не организованы MySQL Cluster Manager, нет никакой потребности выполнять команду start process --added после того, как они были успешно добавлены к кластеру. Применение add process для упрощения create cluster Процессы, добавленные перед первым запуском кластера, начаты вместе с кластером. Это позволяет использовать эту команду, чтобы упростить очень длинную команду create cluster . Рассмотрите следующий набор команд, который создает и затем запускает кластер mycluster: create cluster --processhosts=ndb_mgmd@host1,ndbd@host1,ndbd@host2, \ mysqld@host3,mysqld@host4 mycluster; start cluster mycluster; Длинная create cluster может быть разделена на более короткое (и более понятные) команды. Этот набор команд выполняет ту же самую задачу, как предыдущий набор, создавая mycluster с точно теми же самыми процессами и хостами как прежде: create cluster --processhosts=ndb_mgmd@host1 mycluster; add process --processhosts=ndbd@host1,ndbd@host2 mycluster; add process --processhosts=mysqld@host3,mysqld@host4 mycluster; start cluster mycluster; Заметьте, что процесс, который добавляется к кластеру, который был создан, используя create cluster --import перед импортом, добавляется со статусом import, что означает, что этот кластер не может быть запущен или остановлен через start process или stop process до выполнения импорта. Формирование нового процесса, добавляя его Недавно добавленный процесс наследует свои параметры настройки для каждого признака конфигурации от актуальных сейчас значений для его типа процесса на родительском кластере или принимает настройки по умолчанию для этого типа процесса, если ни одно значение не применяется. У существующих параметров настройки признака в кластере должна быть область видимости уровня процесса, который будет унаследован новыми процессами, добавленными позже, настройка параметров уровня экземпляра для существующих экземпляров процесса до добавления любых новых процессов не относится ни к одному из добавленных процессов. Унаследованные параметры настройки признака могут быть отвергнуты, добавляя процессы, чтобы сделать это, используйте в команде add process опцию --set . Эта опция берет в качестве аргумента список значений признаков в формате, используемом с командами get и set. Предположим, что сейчас для процесса ndbd кластера mycluster параметр уровня процесса DataDir = /home/users/ndb/cluster-data, но вы хотите добавить два новых процесса ndbd, которые используют /tmp/cluster/data вместо этого. Можно сделать это с использованием следующей команды: mcm> add process --set=ndbd:DataDir=/tmp/cluster/data \ > --processhosts=mysqld@tonfisk,mysqld@flundra mycluster; В отличие от пути, которым вы используете команду set, знак равенства (=) немедленно после опции --set обязателен. Устанавливая таким образом атрибуты, которые содержат пути для процессов, работающих в Windows, необходимо заменить любые наклонные черты влево (\) наклонными чертами вправо (/) так же, как с командой set. После того, как процесс был добавлен, используя add process, можно также использовать команду set, чтобы изменить параметры настройки (или определить дополнительные), как с любым другим процессом кластера, организуемым MySQL Cluster Manager. Когда IPv6-системы Windows используются в качестве хостов MySQL NDB Cluster под MySQL Cluster Manager, необходимо сослаться на эти хосты, используя адреса IPv4. Иначе MySQL Cluster Manager не способен соединиться с процессами агента на тех хостах. Посмотрите раздел 5.1. 4.6.2. Команда change process change process [--sequential-restart] old_proc_type [:proc-id]= new_proc_type cluster_name old_proc_type | new_proc_type: {ndbd|ndbmtd} Эта команда используется (MySQL NDB Cluster 7.0 и позже), чтобы изменить тип процесса для данного процесса MySQL NDB Cluster или группы процессов MySQL NDB Cluster с одного типа процесса (old-process-type) к другому типу процесса (new-process-type). В настоящее время только два типа процесса доступны для использования с этой командой: ndbd и ndbmtd. Это означает, что change process может использоваться, чтобы изменить процесс узла данных на одном или более узлах данных от однопоточного демона узла данных (ndbd) на многопоточный демон узла данных (ndbmtd) или наоборот. По умолчанию change process влияет на все узлы данных, работающие с old-process-type. Определяя дополнительно process_id, действие может быть ограничено узлом данных, имеющим этот ID процесса. Предположим, что у вас есть кластер mycluster , у которого есть два узла данных ndbd, как отражено в выводе следующей команды show status: mcm> show status --process mycluster; +--------+----------+----------+---------+-----------+ | NodeId | Process | Host | Status | Nodegroup | +--------+----------+----------+---------+-----------+ | 49 | ndb_mgmd | flundra | running | | | 1 | ndbd | tonfisk | running | n/a | | 2 | ndbd | grindval | running | n/a | | 50 | mysqld | haj | running | | | 51 | mysqld | torsk | running | | | 52 | ndbapi | * | running | | +--------+----------+----------+---------+-----------+ 6 rows in set (0.06 sec) Чтобы изменить оба узла данных, чтобы они использовали многопоточный ndbmtd, дайте команду, показанную здесь, без указания process_id: mcm> change process ndbd=ndbmtd mycluster; +------------------------------+ | Command result | +------------------------------+ | Process changed successfully | +------------------------------+ 1 row in set (2 min 17.51 sec) После того, как команда выполнится, можно проверить, что оба узла данных теперь используют именно ndbmtd: mcm> show status --process mycluster; +--------+----------+----------+---------+-----------+ | NodeId | Process | Host | Status | Nodegroup | +--------+----------+----------+---------+-----------+ | 49 | ndb_mgmd | flundra | running | | | 1 | ndbmtd | tonfisk | running | n/a | | 2 | ndbmtd | grindval | running | n/a | | 50 | mysqld | haj | running | | | 51 | mysqld | torsk | running | | | 52 | ndbapi | * | running | | +--------+----------+----------+---------+-----------+ 6 rows in set (0.09 sec) Перезапуск для кластера выполняется в конце команды change process. MySQL Cluster Manager 1.4.8 и позже: используйте опцию --sequential-restart, чтобы сделать его последовательным. change process может использоваться безотносительно того, работает ли кластер или узлы данных, которые будут изменены. Однако, команда выполняется намного более быстро, если узел данных, который будут изменен, не работает. Следующий набор примеров иллюстрирует это. Возможно (и иногда желательно) использовать процессы узла данных ndbd и ndbmtd одновременно, таким образом также возможно использование change process, чтобы изменить единственный процесс узла данных. Чтобы сделать это, необходимо определить процесс узла данных, используя его ID процесса. Сначала мы останавливаем кластер и проверяем, что все процессы больше не работают, как показано здесь: mcm> stop cluster mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster stopped successfully | +------------------------------+ 1 row in set (22.93 sec) mcm> show status --process mycluster; +--------+----------+----------+---------+-----------+ | NodeId | Process | Host | Status | Nodegroup | +--------+----------+----------+---------+-----------+ | 49 | ndb_mgmd | flundra | stopped | | | 1 | ndbmtd | tonfisk | stopped | n/a | | 2 | ndbmtd | grindval | stopped | n/a | | 50 | mysqld | haj | stopped | | | 51 | mysqld | torsk | stopped | | | 52 | ndbapi | * | stopped | | +--------+----------+----------+---------+-----------+ 6 rows in set (0.05 sec) Следующая команда изменяет только узел, имеющий ID процесса ID 2: mcm> change process ndbmtd:2=ndbd mycluster; +------------------------------+ | Command result | +------------------------------+ | Process changed successfully | +------------------------------+ 1 row in set (6.52 sec) Как вы видите, change process работает намного более быстро, когда процесс, который будет изменен, не работает. Как прежде, можно проверить, что команда выполнена, через show status : mcm> show status --process mycluster; +--------+----------+----------+----------+-----------+ | NodeId | Process | Host | Status | Nodegroup | +--------+----------+----------+----------+-----------+ | 49 | ndb_mgmd | flundra | stopped | | | 1 | ndbmtd | tonfisk | stopped | n/a | | 2 | ndbd | grindval | stopped | n/a | | 50 | mysqld | haj | stopped | | | 51 | mysqld | torsk | stopped | | | 52 | ndbapi | * | stopped | | +--------+----------+----------+----------+-----------+ 6 rows in set (0.07 sec) Чтобы закончить пример, мы запускаем кластер снова, используя start cluster, затем снова меняем узел 2 с ndbd на ndbmtd через change process и проверяем результат через show status : mcm> start cluster mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster started successfully | +------------------------------+ 1 row in set (36.43 sec) mcm> change process ndbd:2=ndbmtd mycluster; +------------------------------+ | Command result | +------------------------------+ | Process changed successfully | +------------------------------+ 1 row in set (2 min 10.41 sec) mcm> show status --process mycluster; +--------+----------+----------+---------+-----------+ | NodeId | Process | Host | Status | Nodegroup | +--------+----------+----------+---------+-----------+ | 49 | ndb_mgmd | flundra | running | | | 1 | ndbmtd | tonfisk | running | n/a | | 2 | ndbmtd | grindval | running | n/a | | 50 | mysqld | haj | running | | | 51 | mysqld | torsk | running | | | 52 | ndbapi | * | running | | +--------+----------+----------+---------+-----------+ 6 rows in set (0.11 sec) Вы видите, что это может потребовать намного меньше времени, если остановить кластер, изменить процесс узла данных, а затем запустить кластер снова, чем изменить процесс в то время, как кластер работает. Однако, если вы делаете это, кластер не доступен в то время, как он остановлен. Как отмечено ранее, change process работает только с процессами ndbd и ndbmtd, попытка использовать любой другой тип процесса заставляет команду терпеть неудачу с ошибкой, как показано здесь: mcm> change process ndb_mgmd=mysqld mycluster; ERROR 7009 (00MGR): Processes ndb_mgmd and mysqld are not interchangeable in this package mcm> change process ndbd=mysqld mycluster; ERROR 7009 (00MGR): Processes ndbd and mysqld are not interchangeable in this package 4.6.3. Команда list processes list processes cluster_name Эта команда показывает все процессы, составляющие данный кластер. Следующий пример демонстрирует, как перечислить все процессы, которые являются частью кластера mycluster: mcm> list processes mycluster; +--------+----------+----------+ | NodeId | Name | Host | +--------+----------+----------+ | 49 | ndb_mgmd | flundra | | 1 | ndbd | tonfisk | | 2 | ndbd | grindval | | 50 | mysqld | haj | | 51 | mysqld | torsk | | 52 | ndbapi | * | +--------+----------+----------+ 6 rows in set (0.03 sec) Параметр cluster_name обязателен. Если этот аргумент опущен, команда терпит неудачу с ошибкой, как показано здесь: mcm> list processes; ERROR 6 (00MGR): Illegal number of operands 4.6.4. Команда start process start process {[--initial|-i] process_id | --added} cluster_name Эта команда начинает процесс MySQL NDB Cluster, имеющий ID процесса process_id в кластере cluster_name. Статус процесса, который будет начат, как показано show status --process, должен быть added, stopped или failed (только если сбойный процесс завершился правильно, он может быть перезапущен этой командой). Этот пример демонстрирует, как начать процесс, имеющий ID 1 в кластере mycluster: mcm> start process 1 mycluster; +------------------------------+ | Command result | +------------------------------+ | Process started successfully | +------------------------------+ 1 row in set (13.93 sec) Можно получить ID для всех процессов в кластере через show status --process или list processes. Они совпадают с ID узла для этих процессов, как показано в выводе других клиентских команд mcm, например, get, или выводе ndb_mgm -e "show" . При использовании опции --initial (краткая форма: -i) происходит следующее: Для процесса узла данных 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). 4.6.5. Команда stop process stop process process_id cluster_name Эта команда останавливает процесс MySQL NDB Cluster с ID процесса process_id в кластере cluster_name. Статус процесса в show status --process должен быть running. Предположим что ID процесса узла данных в кластере mycluster = 3. Тогда этот узел данных может быть остановлен как показано здесь: mcm> stop process 3 mycluster; +------------------------------+ | Command result | +------------------------------+ | Process stopped successfully | +------------------------------+ 1 row in set (33.07 sec) Можно использовать show status --process или list processes, чтобы получить ID для всех процессов в данном кластере. В случае отказа диска, где MySQL Cluster Manager теряет каталог менеджера (включая хранилище), агент в состоянии возвратить информацию от других агентов, но он на самом деле не управляет процессами больше, хотя он может обнаружить их. Это потому, что агент MySQL Cluster Manager не может получить доступ к файлам PID. В этом случае stop process больше не работает, а вы должны завершать такие процессы вручную. Следует иметь в виду это, если StopOnError установлен в 0, агент MySQL Cluster Manager перезапускает процесс узла данных автоматически, если StopOnError = 1 (по умолчанию), необходимо выполнить start process вручную. Эта команда не работает с процессами в кластере, созданном для импорта, где импорт еще не был на самом деле закончен. Посмотрите разделы 4.4.1 и 3.5. 4.6.6. Команда update process update process [--remove-angel] --pid=os_pid process_id cluster_name MySQL Cluster Manager 1.4.2 и позже: Эта команда обновляет статус процесса MySQL NDB Cluster с ID process_id в кластере cluster_name, когда статус процесса больше не отражается правильно в выводе show status --process. Это, как правило, происходит в следующих ситуациях: Процесс это узел данных, формируемый с 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 до фактического обновления, эти шаги необходимы для процесса обновления. 4.6.7. Команда remove process remove process [--removedirs] process_id_list cluster_name process_id_list: process_id[, process_id[, ...]] Эта команда удаляет процессы в process_id_list из кластера cluster_name. Это обеспечивает средство сократить кластер офлайн. При применении опции --removedirs все данные для указанных процессов будут удалены. Следующие ограничения применяются, используя эту команду: Кластер должен быть в статусе 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) 4.7. Команды резервирования и восстановления в MySQL Cluster Manager Эта секция содержит информацию о командах клиента MySQL Cluster Manager, касающихся поддержки MySQL NDB Cluster. 4.7.1. Команда abort backup abort backup --backupid=backup_id cluster_name Эта команда прерывает резервную копию кластера cluster_name с ID backup_id, определенным опцией --backupid. Можно получить список резервных копий и их ID, известных этому экземпляру MySQL Cluster Manager, через list backups. Если резервная копия не происходит на самом деле, команда не имеет никакого эффекта. 4.7.2. Команда backup cluster backup cluster [--backupid=backup_id] [--snapshotstart | --snapshotend] [--waitstarted | --waitcompleted] cluster_name Эта команда создает резервную копию MySQL NDB Cluster cluster_name. backup cluster делает только резервную копию таблиц NDB, таблицы, использующие другие механизмы хранения MySQL (например, InnoDB или MyISAM), игнорируются. По умолчанию эта команда использует резервный ID, назначенный и возвращенный ndb_mgmd (см. здесь), можно отвергнуть это поведение, определив резервный ID, используя опцию --backupid. Опция --snapshotstart заставляет резервную копию соответствовать статусу кластера, когда резервная копия началась. Опция --snapshotend заставляет резервную копию отражать состояние кластера, когда резервная копия была закончена. Если никакой опция не определяется, клиент MySQL Cluster Manager действует как будто определена --snapshotend. При использовании опции --waitstarted клиент MySQL Cluster Manager ждет, пока резервная копия не началась перед возвращением контроля пользователю, после чего пользователь может проверить статус процесса резервного копирования через команду show status и опцию --backup. При использовании опции --waitcompleted клиент MySQL Cluster Manager ждет, пока процесс резервного копирования не будет завершен перед возвращением контроля пользователю. Если ни одна из опций --waitstarted или --waitcompleted не задана, клиент ведет себя как будто задана --waitcompleted. mcm> backup cluster mycluster; +-------------------------------+ | Command result | +-------------------------------+ | Backup completed successfully | +-------------------------------+ 1 row in set (33.50 sec) Можно проверить, что резервная копия была выполнена, проверив вывод list backups: mcm> list backups mycluster; +----------+--------+---------+----------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+----------------------+---------+ | 1 | 1 | tonfisk | 2016-10-24 22:24:54Z | | | 1 | 2 | tonfisk | 2016-10-24 22:24:54Z | | | 2 | 1 | tonfisk | 2016-10-24 22:24:54Z | | | 2 | 2 | tonfisk | 2016-10-24 22:24:54Z | | +----------+--------+---------+----------------------+---------+ 4 rows in set (0.02 sec) Каждый строка в выводе представляет образ то есть, ряд резервных файлов, определенных для данной резервной копии кластера на заданном узле данных. Значение Timestamp в UTC. Образ резервной копии сохраняется в каталоге BackupDataDir /BACKUP/BACKUP-Id, где BackupDataDir параметр кластера. Если не указано BackupDataDir, это принимает значение DataDir, чтобы образ был сохранен в каталоге Datadir /BACKUP/BACKUP-backup_id. Возможно удалить нежелательную резервную копию из данного узла, удаляя этот каталог образов и его содержание. Чтобы удалить данную резервную копию полностью, необходимо удалить соответствующий образ из каталога BACKUP каждого узла данных. Можно сделать это пока не происходит операция резервирования или восстановления. Не требуется останавливать кластер или агент MySQL Cluster Manager до удаления образов. BackupId используется с abort backup и restore cluster. Логическая резервная копия для метаданных таблицы NDB Чтобы позволить больше гибкости для реконфигурации кластера во время восстановления, начиная с версии 1.4.1, команда backup cluster также создает логическую резервную копию для метаданных таблиц NDB в кластере. Используйте опцию --all с командой list backups, чтобы перечислить все резервные копии, включая логические резервные копии для метаданных таблиц NDB, которые отмечены комментарием Schema: mcm> list backups --all newcluster; +----------+--------+---------+----------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+----------------------+---------+ | 1 | 1 | tonfisk | 2016-08-12 16:55:52Z | | | 1 | 2 | tonfisk | 2016-08-12 16:55:52Z | | | 1 | 3 | tonfisk | 2016-08-12 16:55:52Z | | | 1 | 4 | tonfisk | 2016-08-12 16:55:52Z | | | 1 | 50 | tonfisk | 2016-08-12 16:55:55Z | Schema | +----------+--------+---------+----------------------+---------+ 5 rows in set (0.02 sec) Логическая резервная копия была создана, используя утилиту mysqldump. Резервная копия сохраняется с именем файла BACKUP-BackupID .mysql_nodeid.schema.sql в каталоге backupdatadir/BACKUP/BACKUP-id , где backupdatadir (заметьте, что имя в строчных буквах) это параметр mysqld, используемый только для определения местоположения логической резервной копии, созданной MySQL Cluster Manager. Если backupdatadir не определяется, используя команду set в клиенте mcm , значение по умолчанию /mcm_data_repository /clusters/clustername /mysqld_nodeid/, чтобы логическая резервная копия была сохранена в каталоге /mcm_data_repository /clusters/clustername /mysqld_nodeid /BACKUP/BACKUP-Id. Следующие ограничения применяются к созданию логических резервных копий для метаданных таблицы NDB: По крайней мере один узел mysqld должен работать в кластере для логической резервной копии. Никакая резервная копия не была создана ни для какого узла mysqld, который не работает. Метаданные для не-NDB таблиц не поддерживаются. Логическая резервная копия это НЕ резервная копия момента времени, никакие операции DDL не должны быть выполнены на кластере, когда процесс резервного копирования будет работать, или поддержанные метаданные станут несовместимыми с поддержанными данными. Резервная копия для метаданных таблицы NDB полезна для восстановления данных с одного кластера на другой с различной конфигурацией (например, когда целевой кластер для восстановления имеет различное количество узлов данных), посмотрите разделы 3.6.2.4 и 3.6.2.5 для некоторых вариантов использования. 4.7.3. Команда list backups list backups [{--backupid=|-I }backup_id] [-all|-a] cluster_name list backups [{--backupid=|-I }backup_id] [--agent|-A] site_name Без опции --agent команда перечислит все резервные копии MySQL NDB Cluster кластера cluster_name, которые известны этому экземпляру MySQL Cluster Manager. Вывод включает резервную копию и ID узла, а также метку времени UTC для каждой резервной копии, как показано здесь: mcm> list backups mycluster; +----------+--------+---------+----------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+----------------------+---------+ | 1 | 1 | tonfisk | 2016-10-24 22:24:54Z | | | 1 | 2 | tonfisk | 2016-10-24 22:24:54Z | | | 2 | 1 | tonfisk | 2016-10-24 22:24:54Z | | | 2 | 2 | tonfisk | 2016-10-24 22:24:54Z | | +----------+--------+---------+----------------------+---------+ 4 rows in set (0.02 sec) Столбец Timestamp показывает метку времени (в UTC) первого файла в любом резервном каталоге экземпляра. Есть 3 файла в каждой резервной копии: *.ctl, *.data и *.log. Если резервный каталог экземпляра пуст, показывают метку времени самого каталога. С опцией --backupid команды перечисляют резервные копии только с указанным ID: mcm> list backups --backupid=2 mycluster; +----------+--------+---------+----------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+----------------------+---------+ | 2 | 1 | tonfisk | 2016-10-24 22:24:54Z | | | 2 | 2 | tonfisk | 2016-10-24 22:24:54Z | | +----------+--------+---------+----------------------+---------+ 2 rows in set (0.02 sec) MySQL Cluster Manager 1.4.1 и позже: backup cluster также создает резервную копию метаданных для NDB-таблиц кластера, которые перечисляются list backups при использовании опции --all . Резервные копии метаданных отмечены комментарием Schema: mcm> list backups --all newcluster; +----------+--------+---------+----------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+----------------------+---------+ | 1 | 1 | tonfisk | 2016-08-12 16:55:52Z | | | 1 | 2 | tonfisk | 2016-08-12 16:55:52Z | | | 1 | 3 | tonfisk | 2016-08-12 16:55:52Z | | | 1 | 4 | tonfisk | 2016-08-12 16:55:52Z | | | 1 | 50 | tonfisk | 2016-08-12 16:55:55Z | Schema | +----------+--------+---------+----------------------+---------+ 5 rows in set (0.02 sec) MySQL Cluster Manager 1.4.6 и позже: при использовании опции --agent и указании параметра site_name команда перечислит резервные копии агента, созданные для определенного места: mcm> list backups --agent mysite; +------------+-------+---------+----------------------+---------+ | BackupId | Agent | Host | Timestamp | Comment | +------------+-------+---------+----------------------+---------+ | 1522914101 | 0 | tonfisk | 2018-04-05 07:41:41Z | | | 1522914105 | 0 | tonfisk | 2018-04-05 07:41:45Z | | | 1522914121 | 0 | tonfisk | 2018-04-05 07:42:01Z | | +------------+-------+---------+----------------------+---------+ 3 rows in set (0.00 sec) Резервные ID отражают времена Эпохи Unix, в которые были сделаны резервные копии. Вывод может быть отфильтрован с опцией --backupid: mcm> list backups --agent --backupid=1522914121 mysite; +------------+-------+---------+----------------------+---------+ | BackupId | Agent | Host | Timestamp | Comment | +------------+-------+---------+----------------------+---------+ | 1522914121 | 0 | tonfisk | 2018-04-05 07:42:01Z | | +------------+-------+---------+----------------------+---------+ 1 row in set (0.07 sec) 4.7.4. Команда restore cluster restore cluster {--backupid=|-I }backup_id [--disable-indexes|-x] [--disable-metadata|-M] [--epoch|-e] [--exclude-databases=db_name] [--exclude-intermediate-sql-tables] [--exclude-missing-columns] [--exclude-missing-tables] [--exclude-tables=db_name.tbl_name[,db_name.tbl_name][,...]] [--include-databases=db_name [--include-stored-grants] [--include-tables=db_name.tbl_name[,db_name.tbl_name][,...]] [--lossy-conversions] [--no-binlog|-l] [--no-restore-disk-objects] [{--parallelism=|-p }#] [--privilege-tables|-P] [--progress-frequency] [--promote-attributes] [--rewrite-database] [--skip-broken-objects] [{--skip-nodeid=|-s }id_list] [--skip-table-check] [--skip-unknown-objects] cluster_name Эта команда восстанавливает кластер из резервной копии, имеющей указанный резервный ID (опция --backupid, краткая форма: -I) в MySQL NDB Cluster cluster_name. В его самой простой форме это может использоваться как показано здесь, чтобы восстановить кластер mycluster к состоянию в резервной копии, имеющей резервный ID 3: mcm> restore cluster --backupid=3 mycluster; +--------------------------------+ | Command result | +--------------------------------+ | Restore completed successfully | +--------------------------------+ 1 row in set (18.60 sec) Если вы вернули существующий кластер известному хорошему состоянию, необходимо сначала стереть любые существующие данные. Остановите использование кластера: stop cluster, перезапустите его: start cluster с опцией --initial, которая заставляет очистить файловые системы узлов данных. Обратите внимание на то, что для MySQL NDB Cluster 7.5 и ранее дисковые файлы данных должны быть удалены вручную. После этого можно восстановить кластер от желаемой резервной копии через restore cluster. Чтобы восстановить резервную копию с использованием restore cluster, у кластера должен быть неиспользуемый слот для процесса ndbapi. Иначе команда терпит неудачу с ошибкой Unable to perform restore - no vacant ndbapi slots in config for cluster cluster_name. См. здесь. Дополнительные опции, которые могут использоваться с этой командой, включают: --disable-indexes и --disable-metadata. Чтобы заставить индексы быть проигнорированными, восстанавливая данные таблиц, используйте опцию --disable-indexes (краткая форма: -x, только MySQL Cluster Manager 1.4.7 и ранее ). Выполнение этого может уменьшить время, требуемое, чтобы восстановить большой набор данных, особенно там, где много индексов использовалось. Точно так же можно заставить метаданные быть проигнорированными во время процесса восстановления при помощи опции --disable-metadata (краткая форма: -M). --epoch. При использовании опции --epoch (краткая форма: -e) информация об эпохе восстанавливается в таблице состояния репликации кластера (mysql.ndb_apply_status), что может быть полезно для точных копий в репликации MySQL NDB Cluster. --exclude-databases и --exclude-tables. Препятствует тому, чтобы одна или более баз данных или таблиц были восстановлены, используя параметры --exclude-databases и --exclude-tables. --exclude-databases принимает разграниченный запятой список из одной или более баз данных, которые не должны быть восстановлены. --exclude-tables принимает разграниченный запятой список из одной или более таблиц (в формате database. table), которые не должны быть восстановлены. При использовании --exclude-databases или --exclude-tables только базы данных или таблицы, названные опцией, исключены, все другие базы данных и таблицы восстановлены. --exclude-missing-columns. При использовании этой опции restore cluster игнорирует любые колонки, отсутствующие в восстанавливаемых таблицах, по сравнению с версиями тех таблиц, найденных в резервной копии. --exclude-missing-tables. При использовании этой опции restore cluster игнорирует любые таблицы из резервной копии, которые не найдены в целевой базе данных. --exclude-intermediate-sql-tables[=TRUE|FALSE] . При выполнении ALTER TABLE mysqld составляет промежуточные таблицы (чьи имена имеют префикс #sql-). Когда TRUE, опция --exclude-intermediate-sql-tables не дает restore cluster восстановить такие таблиц, которые, возможно, были перенесены от таких операций. Эта опция по умолчанию TRUE. --include-databases и --include-tables. Применение опции --include-databases или --include-tables нужно для восстановления только определенных баз данных или таблиц, соответственно. --include-databases берет разграниченный запятой список баз данных, которые будут восстановлены. --include-tables берет разграниченный запятой список таблиц (в формате database.table для восстановления. При использовании --include-databases или --include-tables восстановлены только базы данных или таблицы, названные опцией, все другие базы данных и таблицы исключены из restore cluster и не восстановлены. --include-stored-grants. При работе с NDB Cluster 8.0.19 и позже restore cluster по умолчанию не восстанавливает разделенных пользователей и права доступа в таблице mysql.ndb_sql_metadata, используйте опцию --include-stored-grants (доступную только в MySQL Cluster Manager 1.4.8 и позже), чтобы отвергнуть это поведение и позволить восстановить эти данных. --lossy-conversions. Использование --lossy-conversions позволяет преобразования с потерями значений столбцов, восстанавливая данные из резервной копии. За некоторыми исключениями правила совпадают с правилами для репликации MySQL, см. здесь. restore cluster сообщает о любом усечении данных, которые это выполняет во время преобразований с потерями один раз на признак и колонку. --no-binlog. Опция --no-binlog (краткая форма: -l) защищает любые узлы SQL (процессы mysqld) в кластере от написания данных из резервной копии в их двоичные журналы. --no-restore-disk-objects. Опция не дает restore cluster восстановить любые объекты MySQL NDB Cluster Disk Data, например, табличные пространства и группы файлов журнала, см. здесь. --parallelism= #. Опция --parallelism (краткая форма: -p) определяет максимальное число параллельных транзакций, используемых restore cluster. По умолчанию 128, максимум 1024, минимум 1. --privilege-tables. Опция --privilege-tables (краткая форма: -P) восстанавливает таблицы для распределенных прав доступа (см. здесь). --progress-frequency=N. Напечатать отчет о состоянии каждые N секунд во временный файл stdout mcm, созданный как mcm_data/clusters/ cluster_name/nodeid /tmp, в то время, как резервная копия происходит. 0 (по умолчанию) = не печатать. Максимум 65535. --promote-attributes. Позволить раскрутку признаков, когда MySQL Cluster Manager восстановит данные из резервной копии. Посмотрите подробности здесь for. --rewrite-database= old_dbname,new_dbname . Эта опция предписывает восстановить базу данных с именем old_dbname в резервной копии под новым именем new_dbname. --skip-nodeid. Опция --skip-nodeid (краткая форма: -s) берет список разделенных запятой значений ID узла. Узлы, ID которых перечисляются, могут включать узлы данных, SQL или обоих типов. Узлы, имеющие эти ID, пропускаются процессом восстановления. --skip-broken-objects. Проигнорировать поврежденные таблицы, читая резервную копию, и продолжить восстанавливать любые остающиеся таблицы (которые не испорчены). В настоящее время --skip-broken-objects работает только в случае недостающих частей blob таблицы. --skip-table-check. Возможно восстановить данные, не восстанавливая метаданные таблицы. Поведение по умолчанию restore cluster: потерпеть неудачу с ошибкой, если данные о таблице не соответствуют схеме таблицы, это может быть отвергнуто, используя опцию --skip-table-check. --skip-unknown-objects. Проигнорировать любые непонятные объекты схемы, читая резервную копию. Это может использоваться для восстановления, например, резервной копии, сделанная из более новой версии MySQL NDB Cluster. 4.7.5. Команда backup agents backup agents [--hosts=host_list] [site_name] host_list: host[, host[, ...]] Эта команда сохраняет данные конфигурации для агентов mcmd на хостах, определенных в host_list опцией --hosts (краткая форма: -h) для места site_name. Если никакие имена хоста не определяются, все агенты места сохраняются. Если нет site_name, резервируется только агент, с которым связан mcm. Резервная копия для каждого агента создается в подкаталоге rep_backup/timestamp под хранилищем агента (mcm_data ), где timestamp отражая время, когда резервная копия началась. Если вы хотите, чтобы резервная копия была в другом месте, создайте мягкую ссылку из mcm_data/rep_backup. MySQL Cluster Manager 1.4.2 и позже : Пустой файл с именем INCOMPLETE создается в каталоге, в котором создается резервная копия, когда резервная копия начинается, и удален после того, как резервная копия закончена. Непрерывное существование файла после окончания процесса резервного копирования указывает, что резервная копия неполная. Заметьте, что backup agents работает по-другому по сравнению с backup cluster, которая поддерживает данные кластера, backup agents поддерживает данные конфигурации агента. Используя вместе резервные копии, созданные обеими командами, можно восстановить не только кластер, но и полную установку кластера плюс менеджер. Дополнительную информацию см. в разделе 3.7. 4.8. Команды импорта MySQL Cluster Manager Cluster Эта секция содержит описания команд MySQL Cluster Manager, связанные с импортированием в MySQL Cluster Manager. Эти операции включают миграцию процессов кластера и копированик данных конфигурации. 4.8.1. Команда import cluster import cluster [--dryrun|-y] [--remove-angel] cluster_name Эта команда импортирует кластер MySQL NDB, созданный вне MySQL Cluster Manager, в кластер cluster_name , созданный в MySQL Cluster Manager. Вам настоятельно рекомендуют создать cluster_name с помощью create cluster с опцией --import. import cluster требует отдельного аргумента, названия кластера, созданного, используя MySQL Cluster Manager (cluster_name), в который вы хотите импортировать кластер MySQL NDB, созданный вне MySQL Cluster Manager. Кластер, названный в команде, должен уже существовать в MySQL Cluster Manager. import cluster понимает опцию --dryrun. Когда эта опция используется, только проверки, требуемые для импорта, выполнены. Это позволяет проверить данную конфигурацию, на самом деле не помещая процессов кластера под контроль MCM. -y это краткая форма опции. MySQL Cluster Manager 1.4.7 и позже, import cluster понимает опцию --remove-angel. Когда эта опция используется, любые работающие процессы ангела для узлов данных импортируемого кластера будут остановлены mcmd до фактического импорта, что является необходимым шагом для импорта, если процессы ангела не были уже остановлены вручную. Когда эта опция используется вместе с --dryrun, никакие удаления процессов ангела не будут на самом деле выполнены, но проверки на процессы ангела (которые происходят, когда используется опция --dryrun) будет пропущены. Рекомендуется, чтобы вы использовали эти две опции отдельно: выполните проверки с --dryrun, определите наблюдаемые ошибки с процессами ангела, выполните import cluster снова только с опцией --remove-angel и посмотрите, что получится. 4.8.2. Команда import config import config [--dryrun|-y] cluster_name Эта команда импортирует конфигурацию автономного кластера в кластер cluster_name. import config требует отдельного аргумента, cluster_name, который является названием кластера, созданного, используя MySQL Cluster Manager, в который вы хотите импортировать конфигурацию MySQL NDB Cluster. Кластер, названный в команде, должен уже существовать в MySQL Cluster Manager, вам также настоятельно рекомендуют использовать create cluster --import для создания cluster_name . import config также понимает опцию --dryrun (краткая форма: -y). Когда эта опция используется, проверки, требуемые для импортирования данных конфигурации, выполнены, и команды set для выполнения фактического импорта написаны в файл / path-to-mcm-data-repository/clusters/ clustername /tmp/import_config.message_id .mcm для вашей экспертизы. Это позволяет проверить импорт конфигурации, на самом деле не копируя ни один из параметров настройки в кластер, которым управляет MySQL Cluster Manager. Можно тогда импортировать все параметры настройки, используя import config (без опции --dryrun), или отрегулировать некоторые параметры настройки в файле / path-to-mcm-data-repository/clusters/ clustername /tmp/import_config.message_id .mcm, а затем импортировать параметры настройки, выполняя файл с помощью агента mcm, см. раздел 3.5.2.3. Когда импортируются параметры конфигурации для узла mysqld, если относительный путь используется для socket или для любого директивного значения (например, plugin_dir), импорт будет отклонен клиентом mcm. Удостоверьтесь, что абсолютный путь используется и при необходимости внесите изменения в атрибуты в файле .mcm, созданном командой import config --dryrun, затем импортируйте параметры настройки, выполнив файл с помощью клиента mcm.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.