17.4.4. ndb_mgmd — MySQL Cluster Management Server Daemon

--bind-address=host[:port]

Когда определено, эта опция ограничивает соединения сервера управления клиентами управления клиентам в указанном имени хоста или IP-адресе (и возможно порт, если это также определяется). В таких случаях клиент управления, пытающийся соединяться с сервером управления от любого другого адреса, перестал работать с ошибкой, Неспособной устанавливать порт: host:port!

Если port не определяется, клиент управления пытается использовать порт 1186.

--no-nodeid-checks

Не выполняйте проверки ID узла.

--configdir=path

Определяет каталог кэша конфигурации сервера управления кластером. --config-dir псевдоним для этой опции.

Эта опция, значение по умолчанию которой 1 (или TRUE, или ON), может использоваться, чтобы отключить кэш конфигурации сервера управления, так, чтобы он считал свою конфигурацию из config.ini каждый раз это запускается (см. Раздел 17.3.2, "MySQL Cluster Configuration Files"). Можно сделать это, запуская процесс ndb_mgmd с любой из следующих опций:

Используя одну из опций, только перечисленных, эффективно, только если у сервера управления нет никакой сохраненной конфигурации в то время, когда это запускается. Если сервер управления находит любые файлы кэша конфигурации, то --config-cache опция или --skip-config-cache опция игнорируется. Поэтому, чтобы отключить кэширование конфигурации, опция должна использоваться в первый раз, когда сервер управления запускается. Иначе — то есть, если Вы хотите отключить конфигурацию, кэширующуюся для сервера управления, который уже создал кэш конфигурации — следует остановить сервер управления, удалить любые существующие файлы кэша конфигурации вручную, затем перезапустить сервер управления с --skip-config-cache (или с --config-cache набор, равный 0, OFF, или FALSE).

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

ndb_node-id_config.bin.seq-number

node-id ID узла сервера управления; seq-number порядковый номер, начинаясь 1. Например, если ID узла сервера управления 5, то первые три файла кэша конфигурации, когда они создаются, назвали бы ndb_5_config.bin.1, ndb_5_config.bin.2, и ndb_5_config.bin.3.

Если Ваше намерение состоит в том, чтобы произвести чистку или перезагрузить кэш конфигурации, фактически не отключая кэширование, следует запустить ndb_mgmd с одной из опций --reload или --initial вместо --skip-config-cache.

Чтобы повторно включить кэшу конфигурации, просто перезапустите сервер управления, но без --config-cache или --skip-config-cache опция, которая использовалась ранее, чтобы отключить кэш конфигурации.

ndb_mgmd не проверяет на каталог конфигурации (--configdir) или попытки создать тот, когда --skip-config-cache используется. (Ошибка #13428853)

--config-file=filename, -f filename

Сообщает серверу управления, относительно которого файла это должно использовать для его конфигурационного файла. По умолчанию сервер управления ищет названный файл config.ini в том же самом каталоге как ndb_mgmd исполнимая программа; иначе имя файла и расположение должны быть определены явно.

Эта опция не имеет никакого значения по умолчанию, и игнорируется, если сервер управления не вынуждается считать конфигурационный файл, также потому что ndb_mgmd был запущен с --reload или --initial опция, или потому что сервер управления не мог найти кэш конфигурации. Эта опция также читается, если ndb_mgmd был запущен с --config-cache=OFF. См. Раздел 17.3.2, "MySQL Cluster Configuration Files", для получения дополнительной информации.

Прежде, используя эту опцию вместе с --initial вызванное удаление кэша конфигурации, даже если файл не был найден. Этот вопрос был решен в MySQL Cluster NDB 7.3.2. (Ошибка #1299289)

--mycnf

Считайте данные конфигурации из my.cnf файл.

--daemon, -d

Дает ndb_mgmd команду запускаться как процесс демона. Это - поведение значения по умолчанию.

Эта опция не имеет никакого эффекта, работая ndb_mgmd на платформах Windows.

--interactive

Запускает ndb_mgmd в интерактивном режиме; то есть, ndb_mgm клиентский сеанс запускается, как только сервер управления работает. Эта опция не запускает никакие другие узлы MySQL Cluster.

--initial

Данные конфигурации кэшируются внутренне, вместо того, чтобы быть считанными из глобального конфигурационного файла кластера каждый раз, когда сервер управления запускается (см. Раздел 17.3.2, "MySQL Cluster Configuration Files"). Используя --initial опция переопределяет это поведение, вынуждая сервер управления удалить любые существующие файлы кэша, и затем перечитать данные конфигурации от файла кластерной конфигурации и создать новый кэш.

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

Если ndb_mgmd вызывается с --initial но не может найти глобальный конфигурационный файл, сервер управления не может запуститься.

Когда сервер управления запускается, он проверяет на другой сервер управления в том же самом MySQL Cluster и попытках использовать другие данные конфигурации сервера управления; ndb_mgmd игнорирует --initial если это не единственное выполнение сервера управления. У этого поведения также есть импликации, выполняя прокручивающийся перезапуск MySQL Cluster с многократными узлами управления. См. Раздел 17.5.5, "Выполняя Прокручивающийся Перезапуск MySQL Cluster", для получения дополнительной информации.

Прежде, используя эту опцию вместе с --config-file вызванное удаление опции кэша конфигурации, даже если файл не был найден. Запускаясь с MySQL Cluster NDB 7.3.2, кэш очищается в таких случаях, только если конфигурационный файл фактически находится. (Ошибка #1299289)

--log-name=name

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

--nodaemon

Дает ndb_mgmd команду не запускаться как процесс демона.

Поведение значения по умолчанию для ndb_mgmd на Windows должно работать на переднем плане, делая эту опцию, ненужную на платформах Windows.

--print-full-config, -P

Шоу расширенная информация относительно конфигурации кластера. С этой опцией на командной строке ndb_mgmd обрабатывают информацию о печатных изданиях об установке кластера включая обширный список разделов кластерной конфигурации так же как параметров и их значений. Обычно используемый вместе с --config-file (-f) опция.

--reload

В MySQL Cluster NDB 7.3, данные конфигурации сохранены внутренне вместо того, чтобы быть считанными из глобального конфигурационного файла кластера каждый раз, когда сервер управления запускается (см. Раздел 17.3.2, "MySQL Cluster Configuration Files"). Используя эти силы опции сервер управления, чтобы проверить его внутреннее хранилище данных по файлу кластерной конфигурации и перезагрузить конфигурацию, если это находит, что конфигурационный файл не соответствует кэш. Существующие файлы кэша конфигурации сохраняются, но не используются.

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

Если сервер управления не может найти глобальный конфигурационный файл, то --reload опция игнорируется.

Когда сервер управления запускается, он проверяет на другой сервер управления в том же самом MySQL Cluster и попытках использовать другие данные конфигурации сервера управления; ndb_mgmd игнорирует --reload если это не единственное выполнение сервера управления. У этого поведения также есть импликации, выполняя прокручивающийся перезапуск MySQL Cluster с многократными узлами управления. См. Раздел 17.5.5, "Выполняя Прокручивающийся Перезапуск MySQL Cluster", для получения дополнительной информации.

--nowait-nodes

Когда запуск MySQL Cluster конфигурируется с двумя узлами управления, каждый сервер управления обычно проверяет, чтобы видеть, является ли другой ndb_mgmd также операционным и идентична ли другая конфигурация сервера управления своему собственному. Однако, это является иногда требуемым, чтобы запустить кластер только с одного узла управления (и возможно позволить другому ndb_mgmd быть запущенным позже). Эта опция заставляет узел управления обходить любые проверки на любые другие узлы управления, ID узла которых передают к этой опции, разрешая кластер запуститься, как если бы сконфигурированный, чтобы использовать только узел управления, который был запущен.

В целях иллюстрации рассмотрите следующую часть a config.ini файл (где мы опустили большинство параметров конфигурации, которые не относятся к этому примеру):

[ndbd]NodeId = 1HostName = 192.168.0.101[ndbd]NodeId = 2HostName = 192.168.0.102[ndbd]NodeId = 3HostName = 192.168.0.103[ndbd]NodeId = 4HostName = 192.168.0.104[ndb_mgmd]NodeId = 10HostName = 192.168.0.150[ndb_mgmd]NodeId = 11HostName = 192.168.0.151[api]NodeId = 20HostName = 192.168.0.200[api]NodeId = 21HostName = 192.168.0.201

Предположите, что Вы хотите запустить этот кластер, используя только сервер управления, имеющий ID узла 10 и работа узла, имеющего IP-адрес 192.168.0.150. (Предположите, например, что главный компьютер, на котором Вы предназначаете к другому серверу управления, временно недоступен из-за отказа оборудования, и Вы ожидаете этого, чтобы быть восстановленными.), Чтобы запустить кластер таким образом, используйте командную строку на машине в 192.168.0.150, чтобы ввести следующую команду:

shell> ndb_mgmd --ndb-nodeid=10
                    --nowait-nodes=11

Как показано в предыдущем примере, при использовании --nowait-nodes, следует также использовать --ndb-nodeid опция, чтобы определить ID узла этого процесса ndb_mgmd.

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

shell> ndbd -c
                    192.168.0.150,192.168.0.151

То же самое является истиной относительно connectstring, используемого с любыми процессами mysqld, которые Вы хотите запустить как узлы SQL MySQL Cluster, соединенные с этим кластером. См. Раздел 17.3.2.3, "MySQL Cluster Connectstring", для получения дополнительной информации.

Когда использующийся с ndb_mgmd, эта опция влияет на поведение узла управления относительно других узлов управления только. Не путайте это с --nowait-nodes опция, используемая с ndbd или ndbmtd, чтобы разрешить кластеру запускаться с меньше чем его полное дополнение узлов данных; когда использующийся с узлами данных, эта опция влияет на их поведение только относительно других узлов данных.

Многократные ID узла управления можно передать к этой опции как список разделенных запятой значений. Каждый ID узла должен быть не менее чем 1 и не больше чем 255. Практически, довольно редко использовать больше чем два сервера управления для того же самого MySQL Cluster (или иметь любую потребность в выполнении так); в большинстве случаев Вы должны передать к этой опции только единственный ID узла для одного сервера управления, который Вы не хотите использовать, запуская кластер.

config.ini конфигурационный файл для кластера в целом. Этот файл создается пользователем и чтением сервером управления. Раздел 17.3, "Конфигурация MySQL Cluster NDB 7.3", обсуждает, как установить этот файл.

ndb_node_id_cluster.log файл журнала событий кластера. Примеры таких событий включают запуск контрольной точки и завершение, события запуска узла, отказы узла, и уровни использования памяти. Полный список событий кластера с описаниями может быть найден в Разделе 17.5, "Управление MySQL Cluster".

Когда размер журнала кластера достигает одного миллиона байтов, файл переименовывается к ndb_node_id_cluster.log.seq_id, где seq_id порядковый номер файла журнала кластера. (Например: Если файлы с порядковыми номерами 1, 2, и 3 уже существуют, следующий файл журнала называют, используя число 4.)

ndb_node_id_out.log файл, используемый для stdout и stderr выполняя сервер управления как демон.

ndb_node_id.pid файл ID процесса, используемый, выполняя сервер управления как демон.

--install[=name]

Причины ndb_mgmd, чтобы быть установленным как служба Windows. Дополнительно, можно определить имя для службы; если не набор, значения по умолчанию имени службы к ndb_mgmd. Хотя предпочтительно определить другие ndb_mgmd опции программы в a my.ini или my.cnf конфигурационный файл, возможно использовать их вместе с --install. Однако, в таких случаях, --install опция должна быть определена сначала, прежде, чем любые другие опции даются для установки службы Windows, чтобы успешно выполниться.

Обычно не желательно использовать эту опцию вместе с --initial опция, так как это заставляет кэш конфигурации быть вытертым и восстановило каждый раз, когда служба останавливается и запускается. Забота должна также быть проявлена, если Вы намереваетесь использовать какие-либо другие ndb_mgmd опции, которые влияют на запуск сервера управления, и следует сделать абсолютно бесспорным, что Вы полностью понимаете и учитываете любые возможные последствия выполнения так.

--install опция не имеет никакого эффекта на платформы не-Windows.

--remove[=name]

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

--remove опция не имеет никакого эффекта на платформы не-Windows.