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

Глава 3. Использование MySQL Cluster Manager В этой главе рассматриваются старт и остановка агента и клиента MySQL Cluster Manager, подготовка, поддержка и восстановление кластеров MySQL NDB Clusters через MySQL Cluster Manager. 3.1. mcmd, MySQL Cluster Manager Agent mcmd это агент MySQL Cluster Manager, вызов этого исполняемого файла запускает MySQL Cluster Manager Agent с которым можно соединиться с использованием клиента mcm (см. раздел 3.3 главу 4). Можно изменить поведение агента различными способами, определив один или больше вариантов, обсужденных в этом секции. Большинство этих вариантов может быть определено в командной строке или в конфигурационном файле агента (обычно это etc/mcmd.ini). Некоторые исключения включают опции --defaults-file и --bootstrap, которые, если используются, должны быть определены в командной строке и являются взаимоисключающими друг с другом. Например, можно установить уровень регистрации группы агента в warning вместо значения по умолчанию message любым из следующих двух способов: Включить --log-level=warning в командной строке, вызывая mcmd. Определяя параметр конфигурации агента в командной строке, название выбора предваряется двумя символами тире (--). Включить следующую строку в конфигурационный файл агента: log-level=warning Можно изменить уровень журналирования во время выполнения, используя в клиенте mcm команду change log-level. Когда используется в конфигурационном файле, название выбора не должно быть указано ни с какими другими знаками. Каждый выбор должен быть определен в отдельной строке. Можно прокомментировать всю строку, вставив символ хэша (#) вот так: #log-level=warning Можно также прокомментировать часть: любой текст после символа # проигнорирован, до конца текущей строки. Следующая таблица содержит резюме вариантов агента, которые прочитаны при запуске mcmd . Более подробная информация о каждом из этих вариантов, такая как позволенный диапазон значений, может быть найдена в списке после таблицы. Таблица 3.1. Опции MySQL Cluster Manager Agent (mcmd) Имя Описание Добавлено в --agent-uuid Установите UUID агента, необходимо только управляя многими агентами на том же самом хосте --basedir Каталог, чтобы использовать в качестве префикса для относительных путей в конфигурации --bootstrap Улучшите группу по умолчанию на запуске --copy-port Определите порт для операций по копированию файла 1.4.2 --daemon Режим демона. Выбор применяется только к Linux и другим подобным Unix платформам --defaults-file Конфигурационный файл, чтобы использовать --event-threads Количество потоков обработчика событий, чтобы использовать --help Покажите параметры приложения --help-all Покажите все варианты (параметры приложения и варианты модуля менеджера) --help-manager Покажите варианты модуля менеджера --initial Стереть содержимое в хранилище конфигурации агента после создания резервной копии 1.4.7 --keepalive Попытайтесь перезапустить mcmd в случае сбоя. Выбор применяется только к Linux и другим подобным Unix платформам --log-backtrace-on-crash Попытайтесь загрузить отладчик в случае сбоя --log-file Название файла, чтобы записать журнал --log-level Уровень журналирования mcmd --log-use-syslog Журналирование в syslog --manager-directory Каталог для хранения данных менеджера --manager-password Пароль для учетной записи пользователя mcmd --manager-port Порт для клиента, чтобы использовать, соединяясь с менеджером --manager-username Имя пользователя для учетной записи пользователя mcmd --max-open-files Максимальное количество открытых файлов (ulimit -n) --pid-file Определите файл PID (используемый, работая в качестве демона) --plugin-dir Каталог, в котором можно искать плагины --plugins Список разделенных запятой плагинов, чтобы загрузить, должен включать "manager" --verbose-shutdown Всегда регистрируйте код выхода, закрывая процесс --version Покажите версию менеджера --xcom-port Определите порт XCOM Описание опций MySQL Cluster Manager Agent (mcmd) Следующий список содержит описания каждой опции запуска, доступной для использования с mcmd, включая позволенные значения и значения по умолчанию. --agent-uuid=uuid Формат командной строки --agent-uuid=uuid Тип String Значение по умолчанию [set internally] Установите UUID для этого агента. Обычно это значение установлено автоматически и должно быть определено только управляя больше, чем одним процессом mcmd на том же самом хосте. --basedir=dir_name Формат командной строки --basedir=dir_name Тип Имя каталога Значение по умолчанию . Каталог с путем, чтобы использовать в качестве префикса для относительных путей в конфигурации. --bootstrap Формат командной строки --bootstrap Запустить агент с конфигурацией по умолчанию, создайте названную группу из одной машины с именем по умолчанию mycluster и запустите ее. Этот выбор работает, только если никакие группы еще не были созданы. --copy-port Формат командной строки --copy-port=port Добавлено в 1.4.2 Тип Numeric Значение по умолчанию 0 Позволяет вам определять порт для операций по копированию файла. По умолчанию 0. --daemon Формат командной строки --daemon Система Linux Выполнить mcmd как демон. --defaults-file= filename Формат командной строки --defaults-file=file_name Тип Имя файла Значение по умолчанию etc/mcmd.ini Установите файл, из которого можно прочитать параметры конфигурации. По умолчанию etc/mcmd.ini. См. раздел 2.4. --event-threads= # Формат командной строки --event-threads=# Тип Numeric Значение по умолчанию 1 Минимум 1 Максимум Зависит от системы Количество потоков обработчика событий. По умолчанию 1, этого достаточно для наиболее нормального функционирования. --help, -? Формат командной строки --help mcmd выведет помощь по разделам Application и Manager. Когда используется с mcmd, --help заставляет вывести опции Application: shell> mcmd --help Usage: mcmd [OPTION...] - MySQL Cluster Manager Help Options: -?, --help Show help options --help-all Show all help options --help-manager Show options for the manager-module Application Options: -V, --version Show version --defaults-file=<file> configuration file --verbose-shutdown Always log the exit code when shutting down --daemon Start in daemon-mode --basedir=<absolute path> Base directory to prepend to relative paths in the config --pid-file=<file> PID file in case we are started as daemon --plugin-dir=<path> Path to the plugins --plugins=<name> Plugins to load --log-level=<string> Log all messages of level ... or higher --log-file=<file> Log all messages in a file --log-use-syslog Log all messages to syslog --log-backtrace-on-crash Try to invoke debugger on crash --keepalive Try to restart mcmd if it crashed --max-open-files Maximum number of open files (ulimit -n) --event-threads Number of event-handling threads (default: 1) --help-all Формат командной строки --help-all mcmd выведет помощь по разделам Application и Manager. Когда используется с --help-all, mcmd выведет опции Application и Manager: shell> mcmd --help-all Usage: mcmd [OPTION...] - MySQL Cluster Manager Help Options: -h, --help Show help options --help-all Show all help options --help-manager Show options for the manager-module manager-module --bootstrap Bootstrap a cluster on localhost on initial startup --copy-port=<copy_port> Port for file copy operations (default: 0) --initial Wipes the repository files after making a backup --manager-directory=<directory> Path to mcmd config information --manager-password=<password> Password for the mcmd user-account (default: super) --manager-port=<client_port> Port to contact the mcmd (default: 1862) --manager-username=<username> Username for the mcmd user-account (default: mcmd) --xcom-port=<xcom_port> Xcom port for mcmds to communicate (default: 18620) Application Options: -V, --version Show version --defaults-file=<file> configuration file --verbose-shutdown Always log the exit code when shutting down --daemon Start in daemon-mode --basedir=<absolute path> Base directory to prepend to relative paths in the config --pid-file=<file> PID file in case we are started as daemon --plugin-dir=<path> Path to the plugins --plugins=<name> Plugins to load --log-level=<string> Log all messages of level ... or higher --log-file=<file> Log all messages in a file --log-use-syslog Log all messages to syslog --log-backtrace-on-crash Try to invoke debugger on crash --keepalive Try to restart mcmd if it crashed --max-open-files Maximum number of open files (ulimit -n) --event-threads Number of event-handling threads (default: 1) --help-manager Формат командной строки --help-manager mcmd выведет помощь по разделам Application и Manager. Когда используется с --help-manager, mcmd выведет опции Manager: shell> mcmd --help-manager Usage: mcmd [OPTION...] - MySQL Cluster Manager manager-module --bootstrap Bootstrap a cluster on localhost on initial startup --copy-port=<copy_port> Port for file copy operations (default: 0) --initial Wipes the repository files after making a backup --manager-directory=<directory> Path to mcmd config information --manager-password=<password> Password for the mcmd user-account (default: super) --manager-port=<client_port> Port to contact the mcmd (default: 1862) --manager-username=<username> Username for the mcmd user-account (default: mcmd) --xcom-port=<xcom_port> Xcom port for mcmds to communicate (default: 18620) --initial Формат командной строки --initial Добавлено в 1.4.7 MySQL Cluster Manager 1.4.7 и позже: Делает резервную копию хранилища конфигурации агента (mcm_data/rep/) как команда backup agents сделала бы для местного хоста, затем стирает содержание хранилища конфигурации прежде, чем запустить mcmd . Конфигурация агента будет восстановлена от других агентов. Это полезно, когда агент попал в непоследовательный статус и не может быть правильно перезапущен. --keepalive Формат командной строки --keepalive Система Linux Используйте этот выбор, чтобы заставить mcmd пытаться перезапуститься в случае сбоя. --log-backtrace-on-crash Формат командной строки --log-backtrace-on-crash Попытайтесь загрузить отладчик в случае сбоя. --log-file= filename Формат командной строки --log-file=file Тип Имя файла Значение по умолчанию mcmd.log Определите имя файла, чтобы записать журнал. По умолчанию mcmd.log в инсталляционном каталоге. На Linux и других подобных Unix-платформах, можно использовать относительный путь, это будет относительно инсталляционного каталога MySQL Cluster Manager, а не подкаталога bin или etc. В Windows необходимо использовать абсолютный путь, и он не может содержать пробелы, кроме того, необходимо заменить любую наклонную черту влево (\) в пути наклонными чертами вправо (/). --log-level=level Формат командной строки --log-level=level Тип Enumeration Значение по умолчанию message Допустимые значения critical error warning message info debug Установить уровень отчета mcmd. Возможные значения для этого выбора и их описания перечисляются в таблице 3.2 в порядке понижения важности. Когда выбор установлен в определенный уровень серьезности, все события этого или более высоких уровней зарегистрированы. Уровень регистрации по умолчанию message, он рекомендуется для производственной среды, переход на более серьезный уровень регистрации пишет меньше сообщений, поэтому труднее проследить проблему, когда она происходит. Таблица 3.2. Уровни журналирования MySQL Cluster Manager Agent Уровень Описание critical Условия, которые должны быть немедленно исправлены, такие как поврежденный репозиторий данных MySQL Cluster Manager error Условия, которые должны быть исправлены, такие как ошибки конфигурации warning Условия, которые не нарушают работу, но могут потребовать пользовательского внимания message Сообщения о главных событиях и о выполнении команд info Информационные сообщения, чтобы предоставить пользователям некоторые подробности выполнения debug Сообщения отладки, которые дают подробности выполнения, полезные для разработчиков. Это производит большие файлы журнала, если используется длительный период времени. Можно также изменить уровень журналирования во время выполнения mcmd командой change log-level в клиенте mcm. В то время, как опция --log-level применяется только к хосту, агент mcmd которого использует выбор (в командной строке или в конфигурационном файле), команда change log-level может использоваться, чтобы применить уровень ко всему сайту управления или определенным хостам. --log-use-syslog Формат командной строки --log-use-syslog Писать журнал в syslog. --manager-directory= dir_name Формат командной строки --manager-directory=dir Тип Имя каталога Значение по умолчанию ../mcm_data (связан с каталогом установки MySQL Cluster Manager) Установите местоположение хранилища агента, которое содержит коллекции файлов данных MySQL Cluster Manager и MySQL NDB Cluster. Значение должно быть действительным абсолютным путем. В Linux если каталог не существует, он создается. В Windows должен быть создан каталог, если он не существует. Дополнительно в Windows путь может не содержать пробелы или наклонную черту влево (\), наклонные черты влево должны быть заменены наклонными чертами вправо (/). Местоположение по умолчанию ../mcm_data (относительно инсталляционного каталога MySQL Cluster Manager). Если вы изменяете умолчание, необходимо использовать стандартное местоположение, внешнее для инсталляционного каталога MySQL Cluster Manager, например, /var/opt/mcm в Linux. В дополнение к файлам данных для всех групп под контролем MySQL Cluster Manager каталог также содержит подкаталог rep, в котором сохранены конфигурация и метаданные mcmd. Обычно нет никакой потребности взаимодействовать с этими каталогами вне определения местоположения manager-directory в конфигурационном файле агента (mcmd.ini), см. исключения, например, в разделах 3.8 и 3.7. --manager-port=# Формат командной строки --manager-port=port Тип Numeric Значение по умолчанию localhost:1862 Определите порт, используемый MySQL Cluster Manager для клиентских подключений. Любой действительный номер порта TC/IP может использоваться. Обычно нет никакой потребности изменить его от значения по умолчанию (1862). Ранее этот выбор мог произвольно взять имя хоста в дополнение к номеру порта, но в MySQL Cluster Manager 1.1.1 и позже больше не принимается имя хоста. --manager-username= user_name Выбор служит следующим двум целям: Устанавливает имя пользователя для клиента mcm, чтобы соединиться с агентом mcmd . Если выбор не определяется, значение по умолчанию mcmd. Если выбор определяется с другим значением, клиент должен поставлять его, используя опцию --user, пытаясь соединиться с агентом. Пароль для использования этого имени пользователя, чтобы соединиться с агентом, установлен с помощью параметра --manager-password. Устанавливает имя пользователя для MySQL, чтобы использоваться агентом mcmd , чтобы получить доступ к узлам SQL. Если выбор не определяется, значение по умолчанию mcmd. Когда узел SQL инициализируется, mcmd создает новую учетную запись пользователя MySQL на нем, используя имя пользователя, установленное опцией и паролем, установленным опцией --manager-password. Этот пользователь создается со всеми привилегиями на сервере MySQL включая предоставление привилегий. Другими словами, это создается, как будто вы выполнили GRANT ALL PRIVILEGES ON *.* ... WITH GRANT OPTION в клиенте mysql. Существующий MySQL-пользователь root не изменен в таких случаях, и сохранена база данных по умолчанию test. --manager-password= password Выбор служит следующим двум целям: Устанавливает пароль пользователя для клиента mcm, чтобы связаться с mcmd с именем пользователя, установленным --manager-username. Если выбор не определяется, значение по умолчанию super. Если выбор определяется с другим значением, клиент должен поставлять его, используя опцию --password, пытаясь соединиться с агентом. Устанавливает пароль для пользователя MySQL, применяемый агентом mcmd, чтобы получить доступ к узлам SQL. Если выбор не определяется, значение по умолчанию super. Когда узел SQL инициализируется, mcmd создает новую учетную запись пользователя MySQL на нем, используя имя пользователя, установленное опцией --manager-username и пароль, установленный этим выбором. См. описания --manager-username. --max-open-files=# Формат командной строки --max-open-files=# Тип Numeric Значение по умолчанию 1 Минимум 1 Максимум Зависит от системы Определите максимальный номер открытых файлов (как с ulimit -n). --pid-file=file Формат командной строки --pid-file=file_name Тип Имя файла Значение по умолчанию mcmd.pid Определите имя и путь к файлу ID процесса (.pid). Этот выбор не поддерживается в системах Windows. --plugin-dir Формат командной строки --plugin-dir=dir_name Тип Имя каталога Значение по умолчанию lib/mcmd Установите каталог, где искать плагины. По умолчанию lib/mcmd в каталоге установки MySQL Cluster Manager, обычно нет никакой потребности изменить это. --plugins Формат командной строки --plugins=list Тип Имя каталога Значение по умолчанию manager Определите список плагинов, которые будут загружены при запуске. Чтобы позволить MySQL Cluster Manager, этот список должен включать manager (значение по умолчанию). Пожалуйста, знайте, что мы в настоящее время не проверяем MySQL Cluster Manager ни с какими значениями plugins, кроме manager. Поэтому мы рекомендуем использовать значение по умолчанию в производственном окружении. --verbose-shutdown Формат командной строки --verbose-shutdown Заставляет mcmd зарегистрировать код выхода, закрываясь, независимо от причины. --version, -V Формат командной строки --version Покажите информацию о версии. Вывод может измениться, согласно версии программного обеспечения MySQL Cluster Manager, операционной платформе и версиям библиотек, использовавшихся на вашей системе, но должен напоминать то, что показывают здесь, с первой строки, содержащей номер выпуска MySQL Cluster Manager: shell> mcmd --version MySQL Cluster Manager 1.4.8 (64bit) chassis: 0.8.5.15734304 glib2: 2.44.0 libevent: 2.1.11-stable -- modules manager: 1.4.8 --xcom-port Формат командной строки --xcom-port=port Тип Numeric Значение по умолчанию 18620 Позволяет вам определять порт XCOM, по умолчанию 18620. 3.2. Запуск и останов агента MySQL Cluster Manager Прежде чем можно будет начать использовать MySQL Cluster Manager, чтобы создать и управлять группой MySQL NDB, агент MySQL Cluster Manager должен быть запущен на каждом компьютере, который предназначается, чтобы принять один или несколько узлов в группе MySQL NDB. Агент MySQL Cluster Manager использует учетную запись пользователя MySQL для административного доступа к процессам mysqld. Возможно, но не обязательно изменить имя пользователя по умолчанию и/или пароль по умолчанию, используемый для этого доступа. Для получения дополнительной информации посмотрите раздел 2.3.3. 3.2.1. Запуск и останов агента в Linux Чтобы запустить агент MySQL Cluster Manager на данном хосте под Linux или подобной операционной системой, необходимо выполнить mcmd в подкаталоге bin в рамках инсталляционного каталога менеджера на том хосте. Типичные опции, используемые с mcmd : mcmd [--defaults-file | --bootstrap] [--log-file] [--log-level] См. раздел 3.1 для получения информации о дополнительных опциях, которые могут использоваться, вызывая mcmd из командной строки, или в конфигурационном файле. mcmd обычно работает на переднем плане. При необходимости можно использовать обычный механизм платформы для фоновой обработки процесса. В Linux можно сделать это, добавив знак амперсанд (&) примерно так (не включая любые опции, которые могли бы требоваться): shell> ./bin/mcmd & По умолчанию агент предполагает, что конфигурационный файл агента etc/mcmd.ini в каталоге установки MySQL Cluster Manager. Можно сказать агенту использовать иной конфигурационный файл, задав путь к этому файлу в опции --defaults-file: shell> ./bin/mcmd --defaults-file=/home/mcm/mcm-agent.conf Опция --bootstrap заставляет агента начинать со значений конфигурации по умолчанию, создавать группу из одной машины, по умолчанию названную mycluster, и запустить ее. Этот выбор работает, только если никакая группа еще не создана и является взаимоисключающим с --defaults-file. В настоящее время любые данные, хранящиеся в группе по умолчанию mycluster, не сохранены между перезапусками группы, это известная проблема, которую мы можем решить в будущем выпуске MySQL Cluster Manager. Использование опции --bootstrap с mcmd показывается здесь на системе, имеющей имя хоста torsk, где MySQL Cluster Manager установлен в /home/jon/mcm: shell> ./mcmd --bootstrap MySQL Cluster Manager 1.4.8 started Connect to MySQL Cluster Manager by running "/home/jon/mcm/bin/mcm" -a torsk:1862 Configuring default cluster 'mycluster'... Starting default cluster 'mycluster'... Cluster 'mycluster' started successfully ndb_mgmd torsk:1186 ndbd torsk ndbd torsk mysqld torsk:3306 mysqld torsk:3307 ndbapi * Connect to the database by running "/home/jon/mcm/cluster/bin/mysql" -h torsk -P 3306 -u root Можно соединиться с агентом, используя клиент mcm (см. раздел 3.3), и/или с серверами MySQL на портах 3306 и 3307 через mysql или другое клиентское приложение MySQL. Опция --log-file позволяет вам отвергать местоположение по умолчанию для файла журнала агента (обычно это mcmd.log в каталоге установки MySQL Cluster Manager). Можно использовать опцию --log-level, чтобы перекрыть настройку log-level в конфигурационном файле агента. См. раздел 3.1. Агент MySQL Cluster Manager должен быть запущен на каждом хосте в группе MySQL NDB, которая будет им управляться. Чтобы остановить один или несколько экземпяров агента MySQL Cluster Manager, используйте команду stop agents в клиенте MySQL Cluster Manager. Если клиент недоступен, можно остановить каждый процесс агента, используя стандартный метод системы, например, ^C или kill. Можно также настроить агента как демона или сервис в Linux и других Unix-системах (см. раздел 2.3.1). Если вы также хотите, чтобы упавшие процессы узла данных работающего кластера MySQL NDB Cluster были перезапущены в случае сбоя агента, необходимо удостовериться что StopOnError = 0 на каждом узле данных (по умолчанию 1). 3.2.2. Запуск и остановка MySQL Cluster Manager Agent в Windows Чтобы запустить агента MySQL Cluster Manager вручную на хосте Windows, необходимо вызвать mcmd.exe в подкаталоге bin в соответствии с инсталляционным каталогом менеджера на том хосте. По умолчанию агент использует файл настроек etc/mcmd.ini в каталоге установки MySQL Cluster Manager, это может быть отвергнуто, задав местоположение желаемого файла как значение опции --defaults-file. Типичные варианты для запуска mcmd: mcmd[.exe] [--defaults-file | --bootstrap] [--log-file] [--log-level] Для получения информации о дополнительных опциях, которые могут использоваться с mcmd в командной строке или в файле настроек, см. раздел 3.1. По умолчанию агент предполагает, что конфигурационный файл агента etc/mcmd.ini в инсталляционном каталоге MySQL Cluster Manager. Можно сказать агенту использовать иной конфигурационный файл, задав путь к этому файлу в опции --defaults-file: C:\Program Files (x86)\MySQL\MySQL Cluster Manager 1.4.8\bin> mcmd --defaults-file="C:\Program Files (x86)\MySQL\MySQL Cluster Manager 1.4.8\etc\mcmd.ini" Опция --bootstrap заставляет агента начинать с параметров конфигурации по умолчанию, создавать группу из одной машины, названную по умолчанию mycluster, и ее запустить. Использование этого выбора с mcmd показывают здесь на системе, имеющей имя хоста torsk, где MySQL Cluster Manager был установлен в местоположении по умолчанию: C:\Program Files (x86)\MySQL\MySQL Cluster Manager 1.4.8\bin> mcmd --bootstrap MySQL Cluster Manager 1.4.8 started Connect to MySQL Cluster Manager by running "C:\Program Files (x86)\MySQL\MySQL Cluster Manager 1.4.8\bin\mcm" -a TORSK:1862 Configuring default cluster 'mycluster'... Starting default cluster 'mycluster'... Cluster 'mycluster' started successfully ndb_mgmd TORSK:1186 ndbd TORSK ndbd TORSK mysqld TORSK:3306 mysqld TORSK:3307 ndbapi * Connect to the database by running "C:\Program Files (x86)\MySQL\MySQL Cluster Manager 1.4.8\cluster\bin\mysql" \ -h TORSK -P 3306 -u root Можно соединиться с агентом, используя клиент mcm (см. раздел 3.3), и/или с сервером MySQL Servers на портах 3306 и 3307, используя клиент mysql. Запуская агент агент MySQL Cluster Manager, можно видеть один или несколько диалогов Windows Security Alert : Рис. 3.1. Запуск MySQL Cluster Manager Agent в Windows: Security Alert Необходимо дать разрешение соединяться с частными сетями для любой из программ mcmd.exe, ndb_mgmd.exe, ndbd.exe, ndbmtd.exe или mysqld.exe. Чтобы это сделать, отметьте Private Networks... и нажмите кнопку Allow access. Обычно не надо предоставлять MySQL Cluster Manager или MySQL NDB Cluster доступ к общедоступным сетям, таким как Интернет. Опции --defaults-file и --bootstrap взаимоисключающие. Опция --log-file позволяет вам отвергать местоположение по умолчанию для файла журнала агента (обычно это mcmd.log в каталоге установки MySQL Cluster Manager). Можно использовать опцию --log-level, чтобы отвергнуть log-level в конфигурационном файле агента. См. раздел 3.1. Возможно установить MySQL Cluster Manager как службу Windows так, чтобы это было запущено автоматически каждый раз при запуске Windows. Посмотрите раздел 2.3.2.1. Чтобы остановить один или несколько экземпляров агента MySQL Cluster Manager, примените команду stop agents в клиенте MySQL Cluster Manager. Можно также остановить процесс агента, используя Windows Task Manager. Кроме того, если вы установили MySQL Cluster Manager как службу Windows, можно остановить (и запустить) агента, используя Windows Service Manager, CTRL-C, команды SC STOP (или SC START) или NET STOP (или NET START), см. здесь подробности. 3.3. Запуск клиента MySQL Cluster Manager Эта секция охватывает запуск клиента MySQL Cluster Manager и соединение с агентом MySQL Cluster Manager. MySQL Cluster Manager 1.4.8 включает клиент командной строки mcm , расположенный в подкаталоге bin. mcm может быть с опциями из таблицы ниже: Таблица 3.3. Опции mcm Длинная форма Краткая форма Описание --help -? Отображает опции клиента mcm. --version -V Показать версии агента и клиента MySQL Cluster Manager. -W Показать версии агента и клиента MySQL Cluster Manager с версией используемого клиента mysql. --address -a Хост и возможно порт, чтобы использовать, соединяясь с mcmd , в формате host[:port], по умолчанию 127.0.0.1:1862. --mysql-help -I Показать справку для клиента mysql. Протокол клиент-сервер, используемый MySQL Cluster Manager, независим от платформы. Можно соединить с любым агентом MySQL Cluster Manager с помощью клиента mcm на любой платформе, где это доступно. Это означает, например, что можно использовать клиент mcm в Microsoft Windows для связи с агентом MySQL Cluster Manager под Linux. mcm на самом деле действует как обертка для клиента mysql, который включен со связанным дистрибутивом MySQL NDB Cluster. Вызов mcm без определенных опций эквивалентен следующему: shell> mysql -umcmd -psuper -h 127.0.0.1 -P 1862 --prompt="mcm>" Опции -u и -p и их значения жестко закодированы и не могут быть изменены. Это означает, что можно использовать mysql для работы с клиентскими сессиями MySQL Cluster Manager на платформах, где сам mcm (или mcmd ) недоступен. Если вы испытываете проблемы с запуском MySQL Cluster Manager потому, что клиент не соединяется, посмотрите здесь почему это могло бы произойти, а также предложения для некоторых возможных решений. Чтобы закончить сессию клиента, используйте команду exit или quit (краткая форма: \q). Ни одна из этих команд не требует символов завершения или разделения. Соединение с агентом с помощью клиента mcm. Можно соединиться с агентом MySQL Cluster Manager вызывая mcm (или в Windows mcm.exe). Вы, возможно, также должны определить один или больше следующих параметров командной строки: --host =hostname или -h []hostname Этот выбор берет имя или IP-адрес хоста, чтобы соединиться с ним. По умолчанию localhost (который не может быть признан на всех платформах при запуске клиентской сессии mcm, даже если она работает на запуск клиентской сессии mysql). Необходимо иметь в виду, что клиент mcm не выполняет разрешение имени хоста, любая информация об имени прибывает из операционной системы на хосте клиента. Поэтому обычно лучше использовать числовой IP-адрес, а не имя хоста для этого выбора. --port =portnumber или -P[] portnumber Этот выбор определяет порт TCP/IP для клиента. Это должно быть тем же самым портом, который используется агентом MySQL Cluster Manager. Как упомянуто в другом месте, если никакой порт не определяется в конфигурационном файле агента MySQL Cluster Manager (mcmd.ini), номер по умолчанию порта, используемого агентом MySQL Cluster Manager, 1862, который также используется по умолчанию mcm. --user =username или -u[] username Выбор определяет имя пользователя для соединения с агентом. Значение по умолчанию mcmd используется, если выбор не определяется. Чтобы соединиться успешно, значение должно соответствовать опции настройки mcmd --manager-username. --password[=password] или -p [password] Выбор определяет пароль для соединения с агентом. Значение по умолчанию super используется, если выбор не определяется. Чтобы соединиться успешно, значение должно соответствовать опции mcmd --manager-password. При использовании короткой формы выбора (-p), вы не должны оставлять пробел между этим выбором и паролем. Если вы опускаете значение password после опции --password или -p в командной строке, mcm запросит пароль явно. Определение пароля в командной строке нужно считать опасным. Предпочтительно, что вы опускаете пароль, вызывая клиента, а затем указываете его по запросу или помещаете пароль в скрипт запуска или конфигурационный файл. mcm принимает дополнительные опции mysql, некоторые из которых могут возможно быть полезными для MySQL Cluster Manager. Например, опция --pager может оказаться полезной когда вывод get содержит слишком много строк, чтобы поместиться на экран. --prompt может использоваться, чтобы помочь избежать беспорядка между многими сессиями клиента. Однако, варианты, не показанные в текущем руководстве, не были проверены с mcm и не гарантируется, что они будут работать правильно (или даже вообще). См. здесь для получения полного списка и описаний всех опций mysql. Подобно клиенту mysql, mcm также понимает \G как терминатор запроса, который заставляет отформатировать вывод вертикально. Это может быть полезно, используя терминал, ширина которого ограничивается некоторым количеством (как правило, 80) знаков. См. главу 4. Соединение с агентом, используя клиент mysql. Как упомянуто ранее, mcm на самом деле служит оберткой для mysql. На самом деле mysql из любого дистрибутива MySQL должен работать без проблем при соединении с mcmd . Кроме того, так как протокол клиент-сервер, используемый MySQL Cluster Manager, независим от платформы, можно использовать mysql на любой платформе, поддержанной MySQL. Это означает, например, что можно использовать mysql в Microsoft Windows, чтобы соединиться с агентом MySQL Cluster Manager в Linux. Связь с агентом MySQL Cluster Manager достигается, вызывая mysql и определяя имя хоста, номер порта, имя пользователя и пароль, используя следующие параметры командной строки: --host= hostname или -h hostname Этот выбор берет имя или IP-адрес хоста, чтобы соединиться с ним. По умолчанию localhost. Аналогично mcm, mysql не выполняет разрешение имени хоста и полагается на хостовую операционную систему для этой задачи. Поэтому обычно лучше использовать числовой IP-адрес, а не имя хоста для этого выбора. --port= portnumber или -P portnumber Этот выбор определяет порт TCP/IP для клиента, чтобы использовать. Это должно быть тем же самым портом, который используется агентом MySQL Cluster Manager. Хотя номер по умолчанию порта, используемого MySQL Cluster Manager 1862 (который также используется по умолчанию mcm ), это значение по умолчанию неизвестно клиенту mysql , который использует порт 3306 (порт по умолчанию для сервера MySQL), если этот выбор не определяется при вызове mysql. Таким образом необходимо использовать --port или -P, чтобы соединиться с агентом MySQL Cluster Manager, используя клиент mysql, даже если процесс агента использует порт по умолчанию MySQL Cluster Manager и даже если процесс агента работает на том же самом хосте, что и mysql. Если правильный номер порта агента не поставляется ему при запуске, mysql не способен соединиться с агентом. --user= username или -u username Выбор определяет имя пользователя для соединения с агентом. По умолчанию mysql пытается использовать имя пользователя существующей системы на системах Unix и ODBC в Windows, таким образом, необходимо задать имя пользователя, пытаясь получить доступ к агенту MySQL Cluster Manager с mysql, иначе mysql не может соединиться с агентом. Чтобы соединиться успешно, значение опции должно соответствовать опции конфигурации mcmd --manager-username. --password [=password] или -p[ password] Выбор определяет пароль для соединения с агентом. Если вы не включаете --password или -p при вызове mysql, он не может соединиться с агентом. Чтобы соединиться успешно, значение должно соответствовать значению опции конфигурации mcmd --manager-password. При использовании короткой формы (-p) вы не должны оставлять пробел между этим выбором и паролем. Если вы опускаете значение password после --password или -p в командной строке, mysql спросит его явно. Кроме того, можно использовать опцию --prompt, чтобы в mysql задать приглашение. Это рекомендуется, поскольку приглашение по умолчанию (mysql>) может привести к беспорядку между сессиями клиента MySQL Cluster Manager и MySQL. Таким образом можно соединиться с агентом MySQL Cluster Manager вызовом mysql на той же машине. shell> mysql -h127.0.0.1 -P1862 -umcmd -p --prompt='mcm> ' Для удобства, на системах, где mcm недоступен, вы могли бы даже хотеть поместить этот вызов в скрипт запуска. В Linux или аналогичной системе можно было бы назвать этот скрипт mcm-client.sh: #!/bin/sh /usr/local/mysql/bin/mysql -h127.0.0.1 -P1862 -umcmd -p --prompt='mcm> ' В этом случае вы могли тогда запустить клиентскую сессию MySQL Cluster Manager, используя что-то вроде этого: shell> ./mcm-client В Windows можно создать пакетный файл с именем mcm-client.bat: C:\mysql\bin\mysql.exe -umcmd -psuper -h localhost -P 1862 --prompt="mcm> " Приспособьте путь к исполняемому файлу клиента mysql.exe по мере необходимости, чтобы соответствовать его местоположению в вашей системе. Если вы сохранили этот файл в удобное место, такое как рабочий стол Windows, можно запустить MySQL Cluster Manager просто дважды щелкнув по соответствующему значку файла на рабочем столе (или в Windows Explorer), сессия клиента открывается в новом окне cmd.exe. 3.4. Подготовка групп MySQL NDB с MySQL Cluster Manager Эта секция предоставляет основную информацию о подготовке новой группы MySQL NDB Cluster с MySQL Cluster Manager. Это также поставляет руководство по миграции существующего MySQL NDB Cluster в MySQL Cluster Manager. Для получения дополнительной информации о получении и установке MySQL Cluster Manager см. главу 2. См. главу 4 для получения дальнейшей информации по командам клиента MySQL Cluster Manager. 3.4.1. Создание MySQL NDB Cluster с MySQL Cluster Manager В этой секции мы обсуждаем процедуру использования MySQL Cluster Manager, чтобы создать и запустить новый MySQL NDB Cluster. Мы предполагаем, что вы уже получили программное обеспечение MySQL Cluster Manager и MySQL NDB Cluster и что вы уже знакомы с установкой MySQL Cluster Manager (см. главу 2). MySQL Cluster Manager также поддерживает импортирование существующих автономных MySQL NDB Clusters, см. раздел 3.5. Мы также предполагаем, что вы знаете хосты, на которых вы планируете управлять группой и выбрали типы и распределения различных типов узлов среди этих хостов, а также требования базовой конфигурации на основе этих факторов и характеристик оборудования хост-машин. Можно создать и запустить MySQL NDB Cluster на единственном хосте для тестирования или подобных целей, просто вызвав mcmd с опцией --bootstrap, см. раздел 3.2. Создание новой группы состоит из следующих задач: Установка и запуск агента MySQL Cluster Manager. Установите дистрибутив MySQL Cluster Manager, сделайте любые необходимые правки конфигурационных файлов агента и начните процессы агента, как объяснено в главе 2. Процессы агента должны работать на всех хостах группы, прежде чем можно будет создать группу. Это означает, что необходимо поместить полную копию дистрибутива программного обеспечения MySQL Cluster Manager на каждом хосте. Программное обеспечение MySQL Cluster Manager не должно быть в определенном местоположении или даже том же самом местоположении на всех хостах, но оно должно присутствовать, вы не можете работать ни с какими процессами группы на компьютере, где не запущен mcmd. Запуск сессии клиента MySQL Cluster Manager. Запустите клиент MySQL Cluster Manager и соединитесь с агентом MySQL Cluster Manager. Можно соединиться с процессом агента на любом из хостов группы, используя клиент mcm на любом компьютере, который может установить сетевое соединение с желаемым хостом. Посмотрите раздел 3.3. В системах, где mcm недоступен, можно использовать mysql. См. здесь. Разверните софт MySQL NDB Cluster. Самый простой и самый легкий способ сделать это: скопировать полный дистрибутив MySQL NDB Cluster в то же самое место на каждом хосте в группе. Если вы установили MySQL Cluster Manager 1.4.8 на каждом хосте, MySQL NDB Cluster 7.6.13 уже включен в mcm_installation_dir /cluster. Если вы не используете то же самое местоположение на каждом хосте, убедитесь, что софт установлен. Пока не начинайте процессы MySQL NDB Cluster и не редактируйте любые конфигурационные файлы: создавая новую группу, MySQL Cluster Manager заботится об этих задачах автоматически. В Windows вы не должны устанавливать как сервис ни одну из программ процесса узла MySQL NDB Cluster, включая ndb_mgmd.exe, ndbd.exe, ndbmtd.exe и mysqld.exe. MySQL Cluster Manager управляет MySQL NDB Cluster независимо от Windows Service Manager и не взаимодействует с Service Manager или любыми службами Windows. Можно на самом деле выполнить этот шаг в любое время до пункта, где пакет программного обеспечения зарегистрирован (через add package ). Однако мы рекомендуем, чтобы вы установили все программное обеспечение, включая программное обеспечение MySQL NDB Cluster на место прежде, чем выполните любые команды клиента MySQL Cluster Manager. Определение места управления. Командой create site в клиенте MySQL Cluster Manager определите место управления MySQL Cluster Manager то есть, набор хостов, чтобы управлять. Эта команда обеспечивает название места и должна сослаться на все хосты в группе. Раздел 4.2.6 обеспечивает синтаксис и другую информацию об этой команде. Чтобы проверить, что место было создано правильно, используйте в MySQL Cluster Manager команды list sites и list hosts . Регистрация пакета MySQL NDB Cluster. На этом шаге вы обеспечиваете местоположение программного обеспечения MySQL NDB Cluster на всех хостах в группе, используя одну или больше команд add package . Чтобы проверить, что пакет был создан правильно, используйте команды list packages и list processes. Определение кластера. Выполните команду create cluster, чтобы определить набор узлов (процессы) и хосты, на которых каждый процесс работает, составляя кластер MySQL NDB. Эта команда также использует название пакета, зарегистрированного на предыдущем шаге, чтобы MySQL Cluster Manager знал местоположение исполняемого файла, управляющего каждым процессом группы. Можно использовать list clusters и list processes, чтобы определить, был ли кластер определен, как надо. Если вы хотите использовать объединение связи узла SQL, посмотрите здесь прежде, чем создать группу. Начальная конфигурация. Выполните любую конфигурацию группы, которая требуется или желаема до старта. Можно установить значения для параметров настройки MySQL Cluster Manager (параметры MySQL NDB Cluster и MySQL Server) с использованием в клиенте MySQL Cluster Manager команды set. Вы не должны редактировать конфигурационные файлы непосредственно. Следует иметь в виду, что определенные параметры предназначены только для чтения и что некоторые другие не могут быть изменены после того, как кластер был впервые запущен. Можно использовать команду get, чтобы проверить, что признаки были установлены в правильные значения. Запуск кластера. Как только вы закончили предыдущие шаги, включая необходимую начальную конфигурацию, вы готовы запустить кластер. Команда start cluster начинает все процессы группы в правильном порядке. Можно проверить, что кластер стартовал обычно после того, как эта команда закончит работу, используя в MySQL Cluster Manager команду show status . В этот момент кластер готов к употреблению приложениями MySQL NDB Cluster. 3.5. Импорт кластеров MySQL NDB в MySQL Cluster Manager Возможно перенести MySQL NDB Cluster в MySQL Cluster Manager. Следующие разделы обеспечивают схему процедуры, требуемой, чтобы импортировать такую группу в MySQL Cluster Manager. 3.5.1. Импорт кластера в MySQL Cluster Manager: основная процедура Процесс импортирования обычно состоит из шагов, перечисленных здесь: Подготовьте дикий кластер для переноса. Проверьте файлы PID для процессов группы. Создайте и сформируйте в MySQL Cluster Manager кластер назначения с соответствующей конфигурацией. Выполните тестовый прогон, а затем выполните команду import cluster. Этот расширенный листинг показывает каждую из задач: Подготовка дикого кластера Настоятельно рекомендуется сделать полную резервную копию, используя клиент ndb_mgm. См. здесь. Любые процессы группы, которые находятся под контролем средства для управления процессами времени начальной загрузки системы, например, /etc/init.d в Linux или Services Manager в Windows, должны быть удалены из-под этого контроля. Конфигурация дикой группы должна отвечать следующим требованиям, она должна повторно формироваться и перезапускаться, если она не соответствует: NodeID должен быть назначен для каждого узла. DataDir должен быть определен для каждого узла управления и узла данных, каталоги данных для различных узлов не могут быть общими. Свободный узел API, не привязанный к любому хосту, должен быть обеспечен, через него агент mcmd может общаться с группой. Создайте пользователя MySQL mcmd на каждом узле SQL и предоставьте ему привилегии root. Удостоверьтесь, что отключен кэш конфигурации для каждого узла управления. Так как он включен позволен по умолчанию, если узел управления не был запущен с опцией --config-cache=false, необходимо будет остановить и перезапустить его с этой опцией в дополнение к другим опциям, с которыми это было запущено ранее. MySQL Cluster Manager 1.4.6 и ранее: Завершите каждый процесс ангела узла данных, используя средство вашей системы. Не завершайте демоны узла данных. Этот шаг не нужен для MySQL Cluster Manager 1.4.7 и позже. Проверьте, что группа обрабатывает файлы PID. Проверьте, что у каждого процесса в диком кластере есть действительный файл PID. Если у данного процесса нет действительного файла PID, необходимо создать его. См. раздел 3.5.2.2. Создайте и настройте целевой кластер под управлением MySQL Cluster Manager Установите MySQL Cluster Manager и запустите mcmd на всех хостах с тем же самым пользователем системы, который запускал процессы дикой группы. Создайте место MySQL Cluster Manager, охватывающее эти хосты, используя команду create site. Добавьте пакет MySQL Cluster Manager, ссылающийся на исполняемые модули MySQL NDB Cluster, используя команду add package . Используйте эту команду с опцией --basedir, чтобы указать на местоположение инсталляционного каталога MySQL NDB Cluster. Создайте целевую группу, используя команду create cluster, включая те же самые процессы и хосты, которые используются дикой группой. Используйте опцию --import, чтобы определить, что группа это цель импорта. Если дикая группа придерживается рекомендации для узла назначения ID, данные в описании для create cluster, вы не должны определять ID узлов для процессов в create cluster. Кроме того, этот шаг может быть разделен на команду create cluster, которая сопровождается одной или больше команд add process (см. раздел 3.5.2.3). Используйте import config, чтобы скопировать данные конфигурации дикой группы в целевую группу. Используйте эту команду с опцией --dryrun (краткая форма: -y), чтобы выполнить тестовый прогон, который просто регистрирует конфигурационную информацию копии команды, когда она выполняется без опции. Если любой процесс ndb_mgmd или mysqld в дикой группе работают на портах кроме порта по умолчанию, необходимо сначала скомандовать set, чтобы назначить правильные номера порта для них в целевой группе. Когда все такие процессы работают на правильных портах, а пробный прогон успешен, можно выполнить import config (без опции --dryrun), чтобы скопировать данные конфигурации дикой группы. Выполняя этот шаг, необходимо проверить журнал, а также конфигурацию целевой группы, чтобы гарантировать, что все признаки конфигурации были скопированы правильно и с правильным объемом. Исправьте любые несоответствия с конфигурацией дикой группы, используя соответствующие команды set. Проверьте и выполните миграцию дикой группы . Выполните тестовый прогон миграции через import cluster с параметром --dryrun, который заставляет MySQL Cluster Manager проверять ошибки, но не мигрировать на самом деле любые процессы или данные. Исправьте найденные ошибки с использованием --dryrun. Повторите пробный прогон, чтобы гарантировать, что никакие ошибки не были пропущены. Когда пробный прогон больше не сообщает ни о каких ошибках, можно выполнить миграцию с использованием import cluster, но без опции --dryrun. 3.5.2. Импортирование группы в MySQL Cluster Manager: пример Как обсуждено ранее (см. раздел 3.5.1), импорт автономной или дикой группы, которая не была создана с MySQL Cluster Manager, в менеджера требует завершения четырех главных задач. Пример показывает все шаги, требуемые, чтобы выполнить те задачи. Типовая группа используется в примере. Дикий кластер в этом примере состоит из четырех узлов: один узел управления, два узла данных и один узел SQL. Каждый из этих узлов работает на одном из трех хостов, IP-адрес для каждого показывают в следующей таблице: Таблица 3.4. Узлы в группе в качестве примера Узел управления (ndb_mgmd) Тип узла Имя хоста 198.51.100.102 Узел данных (ndbd) 198.51.100.103 Узел данных (ndbd) 198.51.100.104 Узел SQL (mysqld) 198.51.100.102 Мы предполагаем, что эти хосты находятся в специальной сети или подсети, и что каждый из них управляет только двоичными модулями MySQL NDB Cluster и приложениями, обеспечивающими требуемую систему и сетевые службы. Мы предполагаем на каждом хосте, что программное обеспечение MySQL NDB Cluster было установлено из двоичного архива (см. здесь). Мы также предполагаем, что узел управления использует /home/ari/bin/cluster/wild-cluster/config.ini как глобальный конфигурационный файл группы, который показан здесь: [ndbd default] NoOfReplicas= 2 [ndb_mgmd] HostName= 198.51.100.102 DataDir= /home/ari/bin/cluster/wild-cluster/50/data NodeId= 50 [ndbd] HostName= 198.51.100.103 DataDir= /home/ari/bin/cluster/wild-cluster/2/data NodeId=2 [ndbd] HostName= 198.51.100.104 DataDir= /home/ari/bin/cluster/wild-cluster/3/data NodeId=3 [mysqld] HostName= 198.51.100.102 NodeId= 51 [api] NodeId= 52 Заметьте, что для импорта в MySQL Cluster Manager следующее должно быть верным для конфигурации группы: NodeID должен быть явно назначен для каждого узла. DataDir должен быть определен для каждого узла управления и узла данных, каталоги данных для различных узлов не могут быть общими. Свободный узел API, не привязанный к любому хосту, должен быть обеспечен, через него агент mcmd может общаться с группой. 3.5.2.1. Подготовка автономной группы для миграции Следующий шаг в процессе импорта должен подготовить дикую группу к миграции. Это требует, среди прочего, удаления процессов группы из-под контроля любым средством управления системной службой, удостоверяясь, что все узлы управления работают с отключенным кэшированием конфигурации. Для MySQL Cluster Manager 1.4.6 и ранее надо выключить любые процессы ангела узла данных. Любые процессы группы, которые находятся под контролем средства управления процессом начальной загрузки системы, например, /etc/init.d в Linux или Services Manager в Windows, должны быть удалены из-под контроля этого средства. Консультируйтесь с документацией своей операционной системы для получения информации о том, как это сделать. Создайте учетную запись пользователя MySQL на каждом из узлов SQL дикой группы для MySQL Cluster Manager, чтобы выполнить команды import config и import cluster. Имя учетной записи и пароль определяются опциями клиента mcmd manager-username и manager-password (по умолчанию values are mcmd и super, соответственно), используйте эти значения, создавая пользователя на узлах SQL дикой группы и предоставьте пользователю все привилегии на сервере, включая привилегию предоставить привилегии. Например, авторизуйтесь на каждом из узлов SQL дикой группы с mysql как root и выполните: CREATE USER 'mcmd'@'localhost' IDENTIFIED BY 'super'; GRANT ALL PRIVILEGES ON *.* TO 'mcmd'@'localhost' WITH GRANT OPTION; Следует иметь в виду, что это должно быть сделано на всех узлах SQL, если распределенные привилегии не позволены в дикой группе. Удостоверьтесь, что каждый узел дикой группы был запущен с ID узла, указанным как --ndb-nodeid в командной строке, а не только в файле кластерной конфигурации. Это требуется для каждого процесса, чтобы быть правильно определенным mcmd во время импорта. Можно проверить, выполняется ли требование, командой ps -ef | grep , которая показывает опции, с которыми был начат процесс: shell> ps -ef | grep ndb_mgmd ari 8118 10 20:51 ?00:00:04 /home/ari/bin/cluster/bin/ndb_mgmd --config-file=/home/ari/bin/cluster/wild-cluster/config.ini --configdir=/home/ari/bin/cluster/wild-cluster --initial --ndb-nodeid=50 Для ясности в выводе команды ps -ef | grep в этой и следующих секциях, мы пропускаем строку вывода самой команды grep. Если требование не выполняется, перезапустите процесс с опцией --ndb-nodeid, перезапуск может также быть выполнен позже для любых узлов, которые вы перезапускаете. Удостоверьтесь, что отключен кэш конфигурации для каждого узла управления. Так как он включен позволен по умолчанию, если узел управления не был запущен с опцией --config-cache=false, необходимо будет остановить и перезапустить его с ней в дополнение к другим. В Linux мы можем еще раз использовать ps, чтобы получить информацию. В оболочке на хосте 198.51.100.102 на котором проживает узел управления: shell> ps -ef | grep ndb_mgmd ari 8118 10 20:51 ?00:00:04 /home/ari/bin/cluster/bin/ndb_mgmd --config-file=/home/ari/bin/cluster/wild-cluster/config.ini --configdir=/home/ari/bin/cluster/wild-cluster --initial --ndb-nodeid=50 ID процесса 8118. Кэш конфигурации включен по умолчанию, каталог конфигурации был определен, используя опцию --configdir. Во-первых, остановите узел управления с использованием kill с ID процесса из ps: shell> kill -15 8118 Проверьте, что процесс узла управления был остановлен, это больше не должно появляться в выводе ps. Теперь перезапустите узел управления, как описано ранее с отключенным кэшем конфигурации и с опциями, с которыми это было начато ранее. Кроме того, как уже указано выше, удостоверьтесь, что опция --ndb-nodeid определяется при перезапуске: shell> /home/ari/bin/cluster/bin/ndb_mgmd --config-file=/home/ari/bin/cluster/wild-cluster/config.ini --config-cache=false--ndb-nodeid=50 MySQL Cluster Management Server mysql-5.7.29-ndb-7.6.13 2016-11-08 21:29:43 [MgmtSrvr] INFO -- Skipping check of config directory since config cache is disabled. Не надо использовать 0 или OFF для значения опции --config-cache, перезапуская ndb_mgmd. Использование любого из этих значений вместо false в это время заставляет миграцию процесса узла управления терпеть неудачу в процессе импорта. Проверьте, что процесс работает как ожидалось, используя ps: shell> ps -ef | grep ndb_mgmd ari 10221 10 19:38 ?00:00:09 /home/ari/bin/cluster/bin/ndb_mgmd --config-file=/home/ari/bin/cluster/wild-cluster/config.ini --config-cache=false --ndb-nodeid=50 Узел управления теперь готов к миграции. В то время как у нашей группы в качестве примера есть только единственный узел управления, для группы MySQL NDB возможно иметь больше, чем один. В таких случаях необходимо удостовериться, что кэш конфигурации отключен для каждого узла управления. MySQL Cluster Manager 1.4.6 и ранее: Завершите каждый процесс ангела узла данных, используя средство системы. Процесс ангела контролирует процесс узла данных во время действия группы и при необходимости пытается перезапустить процесс узла данных (см. вот здесь). Прежде чем группа может быть импортирована, процессы ангела должны быть остановлены. В Linux можно определить процессы ангела в выводе ps -ef, выполненной на хосте процессов, вот пример выполнения этого на хосте 198.51.100.103 из типовой группы: shell> ps -ef | grep ndbd ari 12836 10 20:52 ?00:00:00 ./bin/ndbd --initial --ndb-nodeid=2 --ndb-connectstring=198.51.100.102 ari 12838 12836 2 20:52 ?00:00:00 ./bin/ndbd --initial --ndb-nodeid=2 --ndb-connectstring=198.51.100.102 В то время как фактический процесс узла данных и его процесс ангела появляются как процессы ndbd, можно определить каждого, смотря на ID процесса. ID процесса ангела появляется дважды в выводе команды, однажды для себя (в первой строке) и однажды как ID родительского процесса фактического демона узла данных (во второй строке). Используйте команду kill, чтобы закончить процесс с определенным ID: shell> kill -9 12836 Проверьте, что процесс ангела был завершен, а другой процесс ndbd (демон узла данных неангела) все еще работает, командой ps -ef: shell> ps -ef | grep ndbd ari 12838 10 20:52 ?00:00:02 ./bin/ndbd --initial --ndb-nodeid=2 --ndb-connectstring=198.51.100.102 Теперь повторите этот процесс на хосте 198.51.100.104: shell> ps -ef | grep ndbd ari 11274 10 20:57 ?00:00:00 ./cluster//bin/ndbd --initial --ndb-nodeid=3 --ndb-connectstring=198.51.100.102 ari 11276 11274 0 20:57 ?00:00:01 ./cluster//bin/ndbd --initial --ndb-nodeid=3 --ndb-connectstring=198.51.100.102 shell> kill -9 11274 shell> ps -ef | grep ndbd ari 11276 10 20:57 ?00:00:01 ./cluster/bin/ndbd --initial --ndb-nodeid=3 --ndb-connectstring=198.51.100.102 MySQL Cluster Manager 1.4.7 и позже: нет никакой потребности завершать процессы ангела вручную, поскольку они будут завершены автоматически применением опции --remove-angel в команде import cluster на последнем шаге процесса импорта. Узлы данных дикой группы теперь готовы к миграции. 3.5.2.2. Проверьте все файлы PID группы Необходимо проверить, что у каждого процесса в дикой группе есть действительный файл PID. В целях этого у действительного файла PID есть следующие особенности: Имя файла находится в формате ndb_node_id .pid, где node_id ID узла, используемый для процесса. Файл расположен в каталоге данных, используемом процессом. Первая строка файла содержит ID процесса узла. Чтобы проверить файл PID на процесс узла управления, авторизуйтесь в системную оболочку на хосте 198.51.100.102, перейдите в каталог данных узла управления, как определено параметром Datadir в конфигурационном файле группы, затем проверьте, чтобы видеть, присутствует ли файл PID. В Linux можно использовать команду, показанную здесь: shell> ls ndb_*.pid ndb_50.pid Проверьте содержание файла .pid, используя текстовый редактор. Мы используем more: shell> more ndb_50.pid 10221 Показанное число должно соответствовать ID процесса ndb_mgmd. Мы можем проверить это в Linux, используя команду ps: shell> ps -ef | grep ndb_mgmd ari 10221 10 19:38 ?00:00:09 /home/ari/bin/cluster/bin/ndb_mgmd --config-file=/home/ari/bin/cluster/wild-cluster/config.ini --config-cache=false --ndb-nodeid=50 Файл PID узла управления удовлетворяет требованиям, перечисленным в начале этой секции. Затем мы проверяем файлы PID на узлы данных на хостах 198.51.100.103 и 198.51.100.104. Войдите в систему на 198.51.100.103, получите ID процесса ndbd на этом хосте, как показано здесь: shell> ps -ef | grep ndbd ari 12838 10 Nov 08 ?00:10:12 ./bin/ndbd --initial --ndb-nodeid=2 --ndb-connectstring=198.51.100.102 Как определено в конфигурационном файле группы, DataDir узла это /home/ari/bin/cluster/wild-cluster/2/data. Перейдите в этот каталог, чтобы искать файл, названный ndb_2.pid: shell> ls ndb_*.pid ndb_2.pid Теперь проверьте содержание этого файла на ID для процесса ангела для узла данных: shell> more ndb_2.pid 12836 MySQL Cluster Manager 1.4.6 и ранее: Измените число в файле PID к собственному PID узла данных: shell> sed -i 's/12836/12838/' ndb_2.pid shell> more ndb_2.pid 12838 Точно так же мы определяем местонахождение и регулируем содержание файла PID для остающегося узла данных (узел ID 3, каталог данных которого /home/ari/bin/cluster/wild-cluster/3/data) на хосте 198.51.100.104: shell> ps -ef | grep ndbd ari 11276 10 Nov 09 ?00:09:44 ./cluster//bin/ndbd --initial --ndb-nodeid=3 --ndb-connectstring=198.51.100.102 shell> more /home/ari/bin/cluster/wild-cluster/3/data/ndb_3.pid 11274 Отредактируйте файл .pid таким образом, что он содержит собственный PID процесса узла данных: shell> cd /home/ari/bin/cluster/wild-cluster/3/data/ shell> sed -i 's/11274/11276/' ndb_3.pid shell> more ndb_3.pid 11276 Файл PID для этого узла данных также отвечает нашим требованиям. MySQL Cluster Manager 1.4.7 и позже: нет никакой потребности приспособить файлы PID, чтобы они содержали собственные ID процессов узла данных, это сделает опция --remove-angel команды import cluster позже. Узлы данных готовы к импорту, пока у них есть действительные файлы PID, содержащие PID для их процессов ангела. Мы готовы продолжить двигаться к узлу mysqld на хосте 198.51.100.102. Чтобы проверить файл PID на узле mysqld: местоположение по умолчанию для него это каталог данных узла, определенный опцией datadir в конфигурационном файле или в командной строке процесса mysqld. Давайте пойдем в каталог данных /home/ari/bin/cluster/wild-cluster/51/data хоста 198.51.100.104 и найдем файл PID. shell> ls *.pid localhost.pid Заметьте, что MySQL Server , возможно, был запущен с опцией --pid-file, который помещает файл PID в указанное местоположение. В следующем случае тот же самый узел был запущен скриптом mysqld_safe, поэтому команда ps показывает значение опции --pid-file: shell> ps -ef | grep mysqld ari 11999 56670 13:15 pts/100:00:00 /bin/sh ./bin/mysqld_safe --defaults-file=/home/ari/bin/cluster/wild-cluster.cnf --ndb-nodeid=51 ari 12136 119991 13:15 pts/100:00:00 /home/ari/bin/cluster/bin/mysqld --defaults-file=/home/ari/bin/cluster/wild-cluster.cnf --basedir=/home/ari/bin/cluster/ --datadir=/home/ari/bin/cluster/wild-cluster/51/data/ --plugin-dir=/home/ari/bin/cluster//lib/plugin --ndb-nodeid=51 --log-error=/home/ari/bin/cluster/wild-cluster/51/data//localhost.localdomain.err --pid-file=/home/ari/bin/cluster/wild-cluster/51/data//localhost.localdomain.pid Как в примере, вероятно, что у вас есть файл PID, который не назван в требуемом формате для импорта группы (ndb_node_id .pid), и если применена опция --pid-file, файл PID не мог бы быть в необходимом местоположении (каталог данных). Давайте изучим файл PID, упоминаемый в последнем примере: shell> more /home/ari/bin/cluster/wild-cluster/51/data//localhost.localdomain.pid 12136 Файл PID для узла SQL в приемлемом местоположении (в каталоге данных) имеет правильное содержание (правильный PID), но имеет неправильное имя. Нам надо просто скопировать файл PID в правильно названный файл в том же самом каталоге вот так: shell> cd /home/ari/bin/cluster/wild-cluster/51/data/ shell> cp localhost.localdomain.pid ndb_51.pid 3.5.2.3. Создание и формирование целевого кластера Следующая задача состоит в том, чтобы создать целевой кластер. Как только это сделано, мы изменяем конфигурацию целевой группы, чтобы она соответствовала конфигурации дикой группы, которую мы хотим импортировать. Позже в примере мы также показываем, как проверить конфигурацию в пробном прогоне прежде, чем попытаться выполнить фактический импорт конфигурации. Чтобы создать и затем формировать целевую группу, выполните эти шаги: Установите MySQL Cluster Manager и запустите mcmd на всех хостах тем же самым пользователем системы, который запускал процессы дикой группы. Как только вы сделали это, можно запустить клиент mcm (см. раздел 3.3) на любом из этих хостов, чтобы выполнить следующие несколько шагов. Импорт группы может потерпеть неудачу из-за недостаточных прав для агентов mcmd, если агенты mcmd запущены не тем же самым пользователем системы, который запускал процессы дикой группы. Создайте место MySQL Cluster Manager, охватывающее все четыре хоста дикой группы, используя create site: mcm> create site --hosts=198.51.100.102, 198.51.100.103, \ 198.51.100.104 newsite; +---------------------------+ | Command result | +---------------------------+ | Site created successfully | +---------------------------+ 1 row in set (0.15 sec) Мы назвали это место newsite. Необходимо быть в состоянии видеть, что это перечислено в выводе list sites : mcm> list sites; +---------+------+-------+----------------------------------------------+ | Site | Port | Local | Hosts | +---------+------+-------+----------------------------------------------+ | newsite | 1862 | Local | 198.51.100.102,198.51.100.103,198.51.100.104 | +---------+------+-------+----------------------------------------------+ 1 row in set (0.01 sec) Добавьте пакет MySQL Cluster Manager, ссылающийся на двоичные модули MySQL NDB Cluster, используя add package, используйте опцию --basedir, чтобы указать на правильное местоположение исполняемых файлов MySQL NDB Cluster. Команда, показанная здесь, создает такой пакет, названный newpackage: mcm> add package --basedir=/home/ari/bin/cluster newpackage; +----------------------------+ | Command result | +----------------------------+ | Package added successfully | +----------------------------+ 1 row in set (0.70 sec) Вы не должны включать каталог bin, содержащий исполняемые файлы MySQL NDB Cluster, в путь в опции --basedir. Если исполняемые файлы находятся в /home/ari/bin/cluster/bin, достаточно определить /home/ari/bin/cluster. MySQL Cluster Manager автоматически проверяет на исполняемые модули подкаталог bin в рамках каталога, определенного в --basedir. Создайте целевую группу включая, по крайней мере, некоторые из тех же самых процессов и хостов, используемых автономной группой. Не включайте процессы или хосты, которые не являются частью этой группы. Чтобы препятствовать тому, чтобы потенциально подрывной процесс или операции по группе вмешались случайно в процесс импорта, сильно рекомендуется, чтобы вы создали группу для импорта, используя опцию --import команды create cluster. Необходимо также заботиться, чтобы сохранить правильный ID узла (как перечислено в файле config.ini выше) для каждого узла. Следующая команда создает группу newcluster для импорта и включает узлы управления и данных, но не SQL или свободный узел API (который мы добавляем на следующем шаге): mcm> create cluster --import --package=newpackage \ --processhosts=ndb_mgmd:50@198.51.100.102, \ ndbd:2@198.51.100.103, ndbd:3@198.51.100.104 \ newcluster; +------------------------------+ | Command result | +------------------------------+ | Cluster created successfully | +------------------------------+ 1 row in set (0.96 sec) Можно проверить, что группа была создана правильно, проверив вывод show status с опцией --process ( -r): mcm> show status -r newcluster; +--------+----------+----------------+--------+-----------+------------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+----------------+--------+-----------+------------+ | 50 | ndb_mgmd | 198.51.100.102 | import | | newpackage | | 2 | ndbd | 198.51.100.103 | import | n/a | newpackage | | 3 | ndbd | 198.51.100.104 | import | n/a | newpackage | +--------+----------+----------------+--------+-----------+------------+ 3 rows in set (0.05 sec) Если необходимо, добавьте любые остающиеся процессы и хосты от дикой группы, не включенные в предыдущий шаг, используя одну или больше команд add process . Мы еще не рассмотрели два узла дикой группы: узел SQL с ID 51 на хосте 198.51.100.102 и узел API с ID 52 который не связан ни с каким определенным хостом. Можно использовать следующую команду, чтобы добавить оба из этих процессов к newcluster: mcm> add process --processhosts=mysqld:51@198.51.100.102, \ ndbapi:52@* newcluster; +----------------------------+ | Command result | +----------------------------+ | Process added successfully | +----------------------------+ 1 row in set (0.41 sec) Еще раз проверяя вывод show status с опцией -r, мы видим, что процессы mysqld и ndbapi были добавлены как ожидалось: mcm> show status -r newcluster; +--------+----------+----------------+--------+-----------+------------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+----------------+--------+-----------+------------+ | 50 | ndb_mgmd | 198.51.100.102 | import | | newpackage | | 2 | ndbd | 198.51.100.103 | import | n/a | newpackage | | 3 | ndbd | 198.51.100.104 | import | n/a | newpackage | | 51 | mysqld | 198.51.100.102 | import | | newpackage | | 52 | ndbapi | * | import | | | +--------+----------+----------------+--------+-----------+------------+ 5 rows in set (0.06 sec) Можно также видеть, что с тех пор, как newcluster был создан, используя create cluster с опцией --import, статус всех процессов в этой группе включая тех, которых мы просто добавили, import. Это означает, что мы еще не можем запустить newcluster или любой из его процессов. Статус import и его эффекты на newcluster и его процессы группы сохраняются, пока мы не закончили импорт другой группы в newcluster. Целевой кластер newcluster теперь имеет те же самые процессы с теми же самыми ID узлов и на тех же самых хостах, как оригинальная автономная группа. Мы готовы продолжить двигаться к следующему шагу. Дублируйте признаки конфигурации дикой группы в целевой группе, используя import config. Проверьте сначала эффекты команды, управляя им с опцией --dryrun (шаг работает только, если вы создали пользователя mcmd на узлах mysqld группы): Прежде, чем выполнить эту команду необходимо установить любые порты не по умолчанию для процессов ndb_mgmd и mysqld командой set в клиенте mcm. mcm> import config --dryrun newcluster; +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Command result | +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Import checks passed. Please check /home/ari/bin/mcm_data/clusters/newcluster/tmp/import_config.49d541a9_294_0.mcm on host localhost.localdomain for settings that will be applied. | +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (6.87 sec) Как обозначено выводом import config --dryrun, вы видите признаки конфигурации и значения, которые были бы скопированы в newcluster командой без опции --dryrun в файл / path-to-mcm-data-repository/clusters/ clustername /tmp/import_config.message_id .mcm. Если вы откроете этот файл в текстовом редакторе, вы будете видеть серию команд set, которые выполнили бы эту задачу: # The following will be applied to the current cluster config: set NoOfReplicas:ndbd=2 newcluster; set DataDir:ndb_mgmd:50=/home/ari/bin/cluster/wild-cluster/50/data newcluster; set DataDir:ndbd:2=/home/ari/bin/cluster/wild-cluster/2/data newcluster; set DataDir:ndbd:3=/home/ari/bin/cluster/wild-cluster/3/data newcluster; set basedir:mysqld:51=/home/ari/bin/cluster/ newcluster; set datadir:mysqld:51=/home/ari/bin/cluster/wild-cluster/51/data/ newcluster; set sql_mode:mysqld:51="NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES" newcluster; set ndb_connectstring:mysqld:51=198.51.100.102 newcluster; Варианты, используемые в командной строке вместо конфигурационного файла, чтобы запустить узел автономной группы, не импортируются в целевую группу командой import config, кроме того, они заставят одно из следующего происходить при выполнении import config --dryrun: Для некоторых вариантов MySQL Cluster Manager выпустит предупреждение Option <param> may be removed on next restart of process <type> <nodeid>. Это подразумевает, что те варианты не будут импортированы в целевую группу и таким образом не будут применены, когда те узлы будут перезапущены после импорта. Вот списки таких возможностей для каждого типа узла: Для узлов ndb_mgmd: ---configdir, --initial, --log-name, --reload, --verbose, --core-file Для узлов ndbd и ndbmtd: --connect-retries, --connect-delay, --daemon=false, --nodaemon, --verbose, --core-file Для узлов mysqld: --ndbcluster, опции --ndbinfo-*, --verbose, --datadir, --defaults-group-suffix, --core-file Для некоторых других опций в то время, как их значения не будут также импортированы в целевую группу, никакие предупреждения не будут выпущены для них. Вот списки таких возможностей для каждого типа узла: Для узлов ndb_mgmd: --config-cache, --daemon, --ndb-nodeid, ---nodaemon=false, --config-file, --skip-config-cache Для узлов ndbd и ndbmtd: --daemon, --foreground, --initial, --ndb-connectstring, --connect-string, --ndb-mgmd-host, --ndb-nodeid, --nodaemon=false Для узлов mysqld: --ndb-connectstring, --ndb-mgmd-host, --ndb-nodeid, --defaults-file, --no-defaults, --basedir Для опций, которые не принадлежат ни одной из этих двух групп, описанных выше, запуск узлов автономной группы с ними в командной строке заставит команду import config --dryrun терпеть неудачу с ошибкой, жалуясь, что опции не поддерживаются. Когда вы сталкиваетесь с первым или третьим случаем, описанным выше, необходимо сделать одно из следующего: Если варианты требуются для целевой группы, и они могут быть установлены, используя команду set (см. здесь), установите их для целевой группы, используя команду set, затем повторите import config --dryrun. Если опции не необходимы для целевой группы или не могут быть установлены, используя set, перезапустите узел дикой группы без этих опций, затем повторите import config --dryrun. После успешного пробного прогона вы теперь готовы импортировать конфигурацию дикой группы в newcluster: mcm> import config newcluster; +------------------------------------------------------------------------------------------------------------------+ | Command result | +------------------------------------------------------------------------------------------------------------------+ | Configuration imported successfully. Please manually verify plugin options, abstraction level and default values | +------------------------------------------------------------------------------------------------------------------+ Как альтернатива, вместо того, чтобы импортировать все параметры настройки, используя import config, можно внести изменения в файл / path-to-mcm-data-repository/clusters/ clustername /tmp/import_config.message_id .mcm, произведенный пробным прогоном, как вы желаете, затем импортировать параметры настройки, выполняя файл агентом mcm: mcm> source /path-to-mcm-data-repository/clusters/clustername/tmp/import_config.message_id.mcm Необходимо тщательно проверить получающуюся конфигурацию newcluster на соответствие конфигурации дикой группы. Если вы находите какие-либо несоответствия, необходимо исправить их в newcluster соответствующими командами set. 3.5.2.4. Тестирование и перемещение автономной группы Тестирование и выполнение миграции автономной группы MySQL NDB Cluster в MySQL Cluster Manager состоят из следующих шагов: Выполните тестовый прогон предложенного использования импорта import cluster с опцией --dryrun. Когда этот выбор используется, MySQL Cluster Manager выполняет проверки на несогласованные признаки конфигурации, отсутствующие или недействительные процессы или хосты, отсутствующие или недействительные файлы PID и другие ошибки, и предупреждает обо всем, что он находит, на самом деле не выполняя миграции процессов или данных (шаг работает только, если вы создали пользователя mcmd на узлах mysqld группы): mcm> import cluster --dryrun newcluster; Если ошибки происходят, их исправляют и повторяют пробный прогон, показанный в предыдущем шаге, пока это не возвращает больше ошибок. Следующий список содержит некоторые распространенные ошибки, с которыми можно столкнуться, и их вероятные причины: MySQL Cluster Manager требует определенного пользователя MySQL и привилегий, чтобы управлять узлами SQL. Если учетная запись пользователя MySQL mcmd не настраивается правильно, вы можете видеть сообщения No access for user..., Incorrect grants for user... или возможно другие ошибки. Следуйте инструкциям, данным здесь в разделе 3.5.2.1. Как описано ранее, каждый процесс группы (кроме процесса, тип которого ndbapi) для переноса под контроль MySQL Cluster Manager должен иметь действительный файл PID. Отсутствующие, неверно названные или недействительные файлы PID могут произвести ошибки, такие как PID file does not exist for process..., PID ... is not running ... и PID ... is type .... См. раздел 3.5.2.2. Несоответствия версии процесса могут также произвести с виду случайные ошибки, найти причину которых может оказаться трудно. Гарантируйте, что все узлы поставляются с правильным выпуском программного обеспечения MySQL NDB Cluster, и что это тот же самый выпуск и версия программного обеспечения. Каждый процесс ангела узла данных в автономной группе должен быть завершен до импорта. Работающий процесс ангела может вызвать ошибки, такие как Angel process pid exists ... или Process pid is an angel process for .... Сделайте следующее, когда вы будете видеть такие ошибки: MySQL Cluster Manager 1.4.6 и ранее: См. здесь в разделе 3.5.2.1. MySQL Cluster Manager 1.4.7 и позже: Продолжите двигаться к следующему шагу, если это единственные ошибки. Процессы ангела и PID узла данных будут обработаны с опцией --remove-angel команды option used with the import cluster на последнем шаге процесса импорта. Количество процессов, их типов и хостов, где они проживают в автономной группе, должно быть отражено точно, создавая целевое место, пакет и группу для импорта. Иначе можно получить ошибки, такие как Process id reported # processes ..., Process id ... does not match configured process ..., Process id not configured ... и Process id does not match configured process .... См. раздел 3.5.2.3 . Другие факторы, которые могут вызвать определенные ошибки, включают процессы в неправильном состоянии, процессы, которые были начаты с неподдержанными параметрами командной строки (см. раздел 3.5.2.3) или без необходимых опций, и процессы, имеющие неправильный ID или использующих неправильный ID узла. Когда import cluster --dryrun больше не предупреждает ни о каких ошибках, можно выполнить импорт с помощью import cluster, на этот раз опуская опцию --dryrun. MySQL Cluster Manager 1.4.6 и ранее: mcm> import cluster newcluster; +-------------------------------+ | Command result | +-------------------------------+ | Cluster imported successfully | +-------------------------------+ 1 row in set (5.58 sec) MySQL Cluster Manager 1.4.7 и позже: используйте опцию --remove-angel команды import cluster, которая закрывает процессы ангела для узлов данных и регулирует файлы PID узлов данных, чтобы содержать собственные ID процессов узла данных прежде, чем импортировать группу: mcm> import cluster --remove-angel newcluster; +-------------------------------+ | Command result | +-------------------------------+ | Cluster imported successfully | +-------------------------------+ 1 row in set (5.58 sec) Можно проверить, что дикая группа была импортирована и теперь находится под контролем MySQL Cluster Manager: mcm> show status -r newcluster; +--------+----------+----------------+---------+-----------+------------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+----------------+---------+-----------+------------+ | 50 | ndb_mgmd | 198.51.100.102 | running | | newpackage | | 2 | ndbd | 198.51.100.103 | running | 0 | newpackage | | 3 | ndbd | 198.51.100.104 | running | 0 | newpackage | | 51 | mysqld | 198.51.100.102 | running | | newpackage | | 52 | ndbapi | * | added | | | +--------+----------+----------------+---------+-----------+------------+ 5 rows in set (0.01 sec) 3.6. Резервирование и восстановление MySQL NDB Cluster Backup через MySQL Cluster Manager Эта секция описывает использование встроенной в NDB функциональности в MySQL Cluster Manager, чтобы выполнить много общих задач. 3.6.1. Требования для резервной копии и восстановления Эта секция предоставляет информацию об основных требованиях для выполнения резервной копии и восстановления с использованием MySQL Cluster Manager. Требования для резервной MySQL NDB Cluster. Основные требования для выполнения использования резервных копий в MySQL Cluster Manager минимальны. По крайней мере один узел данных в каждой группе узла должен работать, в файловых системах узла должно быть достаточное дисковое пространство. Частичные резервные копии не поддерживаются. Требования для восстановления MySQL NDB Cluster. В целом следующие требования применяются, когда вы пытаетесь восстановить MySQL NDB Cluster с использованием MySQL Cluster Manager: Полное восстановление требует, чтобы все узлы данных были в порядке, и что все файлы, принадлежащие данной резервной копии, доступны. Частичное восстановление возможно, но должно быть определено как таковое. Это может быть достигнуто, используя команду restore cluster с опцией --skip-nodeid. См. раздел 3.6.2.3 . Если узлы данных были добавлены к группе после того, как резервная копия была сделана, только те узлы данных, для которых существуют резервные файлы, восстановлены. В таких случаях данные автоматически не распределяются новым узлам, а после восстановления необходимо перераспределить данные вручную, командой ALTER ONLINE TABLE ... REORGANIZE PARTITION в клиенте mysql для каждой таблицы NDB кластера. См. здесь. Чтобы восстановить резервную копию, созданную MySQL Cluster Manager на кластере с меньшим количеством узлов данных, необходимо восстановить сначала логическую резервную копию метаданных таблиц NDB (доступно в резервных копиях, созданных MySQL Cluster Manager 1.4.1 и позже), используя утилиту mysqldump, а затем восстановить данные через программу ndb_restore. См. раздел 3.6.2.5. 3.6.2. Основы резервирования и восстановления MySQL NDB Cluster через MySQL Cluster Manager Эта секция описывает поддержку и восстановление группы MySQL NDB с примерами полных и частичных операций восстановления. Отметьте, что команды backup cluster и restore cluster работают только с таблицами NDB, таблицы, применяющие другие механизмы хранения MySQL (например, InnoDB или MyISAM), игнорируются. В целях примера мы используем MySQL NDB Cluster mycluster чьи процессы и статус таковы: mcm> show status -r mycluster; +--------+----------+----------+---------+-----------+-----------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+----------+---------+-----------+-----------+ | 49 | ndb_mgmd | tonfisk | running | | mypackage | | 1 | ndbd | tonfisk | running | 0 | mypackage | | 2 | ndbd | tonfisk | running | 0 | mypackage | | 50 | mysqld | tonfisk | running | | mypackage | | 51 | mysqld | tonfisk | running | | mypackage | | 52 | ndbapi | *tonfisk | added | | | | 53 | ndbapi | *tonfisk | added | | | +--------+----------+----------+---------+-----------+-----------+ 7 rows in set (0.08 sec) Вы видите, есть ли какие-либо существующие резервные копии mycluster, используя list backups: mcm> list backups mycluster; +----------+--------+---------+---------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+---------------------+---------+ | 1 | 1 | tonfisk | 2012-12-04 12:03:52 | | | 1 | 2 | tonfisk | 2012-12-04 12:03:52 | | | 2 | 1 | tonfisk | 2012-12-04 12:04:15 | | | 2 | 2 | tonfisk | 2012-12-04 12:04:15 | | | 3 | 1 | tonfisk | 2012-12-04 12:17:41 | | | 3 | 2 | tonfisk | 2012-12-04 12:17:41 | | +----------+--------+---------+---------------------+---------+ 6 rows in set (0.12 sec) 3.6.2.1. Простое резервирование Чтобы создать резервную копию, используйте backup cluster с названием группы как аргумент: mcm> backup cluster mycluster; +-------------------------------+ | Command result | +-------------------------------+ | Backup completed successfully | +-------------------------------+ 1 row in set (3.31 sec) backup cluster требует только название группы как аргумент, для получения информации о дополнительных опциях, поддержанных этой командой, посмотрите раздел 4.7.2. Чтобы проверить, что новая резервная копия mycluster была создана с уникальным идентификатором, проверьте вывод list backups: mcm> list backups mycluster; +----------+--------+---------+---------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+---------------------+---------+ | 1 | 1 | tonfisk | 2012-12-04 12:03:52 | | | 1 | 2 | tonfisk | 2012-12-04 12:03:52 | | | 2 | 1 | tonfisk | 2012-12-04 12:04:15 | | | 2 | 2 | tonfisk | 2012-12-04 12:04:15 | | | 3 | 1 | tonfisk | 2012-12-04 12:17:41 | | | 3 | 2 | tonfisk | 2012-12-04 12:17:41 | | | 4 | 1 | tonfisk | 2012-12-12 14:24:35 | | | 4 | 2 | tonfisk | 2012-12-12 14:24:35 | | +----------+--------+---------+---------------------+---------+ 8 rows in set (0.04 sec) При попытке создать резервную копию MySQL NDB Cluster, в котором у каждого узла нет по крайней мере одного рабочего узла данных, backup cluster выдаст ошибку Backup cannot be performed as processes are stopped in cluster cluster_name. 3.6.2.2. Простое полное восстановление Чтобы выполнить полное восстановление MySQL NDB Cluster из резервной копии с данным ID, выполняют шаги, перечисленные здесь: Определите резервную копию, которая будет использоваться. В этом примере мы используем резервную копию, имеющую ID 4, которая была создана для mycluster ранее в этой секции. Сотрите данные MySQL NDB Cluster. Самый простой способ сделать это: остановить и затем выполнить начальный запуск кластера как показано здесь, используя mycluster: mcm> stop cluster mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster stopped successfully | +------------------------------+ 1 row in set (15.24 sec) mcm> start cluster --initial mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster started successfully | +------------------------------+ 1 row in set (34.47 sec) Восстановите резервную копию. Это сделано, используя restore cluster, которая требует резервного ID и названия кластера как аргументы. Таким образом можно вернуть резервную копию 4 на mycluster: mcm> restore cluster --backupid=4 mycluster; +--------------------------------+ | Command result | +--------------------------------+ | Restore completed successfully | +--------------------------------+ 1 row in set (16.78 sec) 3.6.2.3. Частичное восстановление образов Можно выполнить частичное восстановление MySQL NDB Cluster силами MySQL Cluster Manager, то есть восстановить из резервной копии, в которой образы резервной копии от одного или более узлов данных недоступны. Это требуется, если мы хотим восстановить mycluster к резервной копии номер 6, так как образ для этой резервной копии доступен только для узла 1, как видно в выводе list backups: mcm> list backups mycluster; +----------+--------+---------+---------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+---------------------+---------+ | 1 | 1 | tonfisk | 2012-12-04 12:03:52 | | | 1 | 2 | tonfisk | 2012-12-04 12:03:52 | | | 2 | 1 | tonfisk | 2012-12-04 12:04:15 | | | 2 | 2 | tonfisk | 2012-12-04 12:04:15 | | | 3 | 1 | tonfisk | 2012-12-04 12:17:41 | | | 3 | 2 | tonfisk | 2012-12-04 12:17:41 | | | 4 | 1 | tonfisk | 2012-12-12 14:24:35 | | | 4 | 2 | tonfisk | 2012-12-12 14:24:35 | | | 5 | 1 | tonfisk | 2012-12-12 14:31:31 | | | 5 | 2 | tonfisk | 2012-12-12 14:31:31 | | | 6 | 1 | tonfisk | 2012-12-12 14:32:09 | | +----------+--------+---------+---------------------+---------+ 11 rows in set (0.08 sec) Чтобы выполнить восстановление только тех узлов, для которых у нас есть образы (в этом случае только узел 1), мы можем использовать опцию --skip-nodeid при выполнении команды restore cluster. Этот выбор заставляет один или несколько узлов быть пропущенными, выполняя восстановление. Будем считать, что mycluster был очищен от данных (как описано ранее в этой секции), тогда мы сможем выполнить восстановление, которое пропускает узел 2, как показано здесь: mcm> restore cluster --backupid=6 --skip-nodeid=2 mycluster; +--------------------------------+ | Command result | +--------------------------------+ | Restore completed successfully | +--------------------------------+ 1 row in set (17.06 sec) Поскольку мы исключили узел 2 из процесса восстановления, никакие данные не были распределены ему. Чтобы распределить данные MySQL NDB Cluster любым таким исключенным или пропущенным узлам после частичного восстановления, необходимо перераспределить данные вручную, выполняя ALTER ONLINE TABLE ... REORGANIZE PARTITION в клиенте mysql для каждой таблицы NDB кластера. Чтобы получить список таблиц NDB в клиенте mysql можно использовать многократный запрос SHOW TABLES или такой запрос: SELECT CONCAT('' TABLE_SCHEMA, '.', TABLE_NAME) FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE='ndbcluster'; Можно произвести необходимые SQL-операторы, используя более тщательно продуманную версию запроса: mysql> SELECT CONCAT('ALTER ONLINE TABLE `', TABLE_SCHEMA, -> '`.`', TABLE_NAME, '` REORGANIZE PARTITION;') -> AS Statement FROM INFORMATION_SCHEMA.TABLES -> WHERE ENGINE='ndbcluster'; +--------------------------------------------------------------------------+ | Statement | +--------------------------------------------------------------------------+ | ALTER ONLINE TABLE `mysql`.`ndb_apply_status` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `mysql`.`ndb_index_stat_head` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `mysql`.`ndb_index_stat_sample` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `db1`.`n1` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `db1`.`n2` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `db1`.`n3` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `test`.`n1` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `test`.`n2` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `test`.`n3` REORGANIZE PARTITION; | | ALTER ONLINE TABLE `test`.`n4` REORGANIZE PARTITION; | +--------------------------------------------------------------------------+ 10 rows in set (0.09 sec) 3.6.2.4. Частичное восстановление добавленных узлов данных Частичное восстановление может также быть выполнено, когда новые узлы данных были добавлены к группе MySQL NDB уже после резервной копии. В этом случае можно исключить использование новых узлов с помощью опции --skip-nodeid команды restore cluster. Например: mcm> show status -r mycluster; +--------+----------+----------+---------+-----------+-----------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+----------+---------+-----------+-----------+ | 49 | ndb_mgmd | tonfisk | stopped | | mypackage | | 1 | ndbd | tonfisk | stopped | 0 | mypackage | | 2 | ndbd | tonfisk | stopped | 0 | mypackage | | 50 | mysqld | tonfisk | stopped | | mypackage | | 51 | mysqld | tonfisk | stopped | | mypackage | | 52 | ndbapi | *tonfisk | added | | | | 53 | ndbapi | *tonfisk | added | | | +--------+----------+----------+---------+-----------+-----------+ 7 rows in set (0.03 sec) Вывод list backups показывает нам доступные образы резервной копии для этой группы: mcm> list backups mycluster; +----------+--------+---------+---------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+---------------------+---------+ | 1 | 1 | tonfisk | 2012-12-04 12:03:52 | | | 1 | 2 | tonfisk | 2012-12-04 12:03:52 | | | 2 | 1 | tonfisk | 2012-12-04 12:04:15 | | | 2 | 2 | tonfisk | 2012-12-04 12:04:15 | | | 3 | 1 | tonfisk | 2012-12-04 12:17:41 | | | 3 | 2 | tonfisk | 2012-12-04 12:17:41 | | | 4 | 1 | tonfisk | 2012-12-12 14:24:35 | | | 4 | 2 | tonfisk | 2012-12-12 14:24:35 | | +----------+--------+---------+---------------------+---------+ 8 rows in set (0.06 sec) Теперь предположите, что позже 2 узла данных были добавлены к mycluster, используя команду add process . Запрос show status для mycluster: mcm> show status -r mycluster; +--------+----------+----------+---------+-----------+-----------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+----------+---------+-----------+-----------+ | 49 | ndb_mgmd | tonfisk | running | | mypackage | | 1 | ndbd | tonfisk | running | 0 | mypackage | | 2 | ndbd | tonfisk | running | 0 | mypackage | | 50 | mysqld | tonfisk | running | | mypackage | | 51 | mysqld | tonfisk | running | | mypackage | | 52 | ndbapi | *tonfisk | added | | | | 53 | ndbapi | *tonfisk | added | | | | 3 | ndbd | tonfisk | running | 1 | mypackage | | 4 | ndbd | tonfisk | running | 1 | mypackage | +--------+----------+----------+---------+-----------+-----------+ 9 rows in set (0.01 sec) Так как узлы 3 и 4 не были включены в резервную копию, мы должны исключить их, выполняя восстановление. Можно вызвать restore cluster, чтобы пропустить узлы данных, определяя список разделенных запятой значений ID узлов в опции --skip-nodeid. Предположите, что мы только что очистили mycluster от данных MySQL NDB Cluster командами stop cluster и start cluster --initial, тогда мы можем восстановить mycluster (теперь нумерация 4 узлов данных 1, 2, 3 и 4) из резервной копии номер 4 (сделанной, когда mycluster имел только 2 узла данных, пронумерованных 1 и 2), как показано здесь: mcm> restore cluster --backupid=4 --skip-nodeid=3,4 mycluster; +--------------------------------+ | Command result | +--------------------------------+ | Restore completed successfully | +--------------------------------+ 1 row in set (17.61 sec) Никакие данные не распределяются пропущенным (новым) узлам, необходимо вынудить узлы 3 и 4 быть включенными в перераспределение данных, используя запрос ALTER ONLINE TABLE ... REORGANIZE PARTITION как описано ранее в этой секции. MySQL Cluster Manager 1.4.1 и позже: альтернатива созданию и выполнению ALTER ONLINE TABLE ... REORGANIZE PARTITION это использовать логическую резервную копию метаданных таблиц NDB, которые являются частью резервной копии группы, созданной MySQL Cluster Manager. Чтобы сделать это, надо прежде, чем вы выполните restore cluster: Определите местонахождение логической резервной копии для метаданных, посмотрите раздел 3.6.2.5. Восстановите логическую резервную копию, посмотрите здесь. Можно тогда выполнить restore cluster, данные будут перераспределенными на все узлы данных без потребности в дальнейшем ручном вмешательстве. 3.6.2.5. Восстановление резервной копии к группе с меньшим количеством узлов данных Иногда вы хотите передать данные от своей группы в другую, у которой есть меньше узлов данных, например, когда вы хотите сократить свою группу или подготовить меньшую группу точной копии к установке репликации. В то время как методы, описанные в разделе 3.6.2 не будут работать в этом случае, начиная с MySQL Cluster Manager 1.4.1, можно выполнить передачу, просто используя backup cluster и ndb_restore . Процесс начинается с создания резервной копии для оригинальной группы, используя backup cluster. Затем создайте новую группу с меньшим количеством узлов данных, используя create cluster. Прежде чем данные о таблице NDB могут быть переданы, метаданные для таблиц NDB должны сначала вернуться новой группе. Начиная с MySQL Cluster Manager 1.4.1, backup cluster также создает логическую резервную копию для метаданных таблиц NDB (см. здесь). Используйте опцию --all команды list backups, чтобы перечислить все резервные копии, включая логические резервные копии для метаданных таблиц NDB, которые отмечены комментарием Schema: mcm> list backups --all mycluster; +----------+--------+---------+----------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+----------------------+---------+ | 1 | 1 | tonfisk | 2016-09-21 21:13:09Z | | | 1 | 2 | tonfisk | 2016-09-21 21:13:09Z | | | 1 | 3 | tonfisk | 2016-09-21 21:13:09Z | | | 1 | 4 | tonfisk | 2016-09-21 21:13:09Z | | | 1 | 50 | tonfisk | 2016-09-21 21:13:12Z | Schema | | 2 | 1 | tonfisk | 2016-09-21 21:17:50Z | | | 2 | 2 | tonfisk | 2016-09-21 21:17:50Z | | | 2 | 3 | tonfisk | 2016-09-21 21:17:50Z | | | 2 | 4 | tonfisk | 2016-09-21 21:17:50Z | | | 2 | 50 | tonfisk | 2016-09-21 21:17:52Z | Schema | +----------+--------+---------+----------------------+---------+ 10 rows in set (0.01 sec) Затем, мы должны узнать местоположения логического резервного файла и резервных файлов для каждого узла данных оригинальной группы. Местоположения резервных файлов. Резервные файлы для каждого узла должны быть найдены под папкой, определенной параметром группы BackupDataDir для узлов данных и параметром backupdatadir для узлов mysqld. Поскольку команда get нечувствительна к регистру, можно использовать эту единственную команду, чтобы проверить значения обоих параметров: mcm> get BackupDataDir mycluster; +---------------+----------------+----------+---------+----------+---------+---------+----------+ | Name | Value | Process1 | NodeId1 | Process2 | NodeId2 | Level | Comment | +---------------+----------------+----------+---------+----------+---------+---------+----------+ | BackupDataDir | /opt/mcmbackup | ndbmtd | 1 | | | Process | | | BackupDataDir | /opt/mcmbackup | ndbmtd | 2 | | | Process | | | BackupDataDir | /opt/mcmbackup | ndbmtd | 3 | | | Process | | | BackupDataDir | /opt/mcmbackup | ndbmtd | 4 | | | Process | | | backupdatadir | /opt/mcmbackup | mysqld | 50 | | | Process | MCM only | +---------------+----------------+----------+---------+----------+---------+---------+----------+ 5 rows in set (0.18 sec) Резервные файлы для каждой резервной копии определенного BackupID найдены в BackupDataDir /BACKUP/BACKUP-ID/ для каждого узла данных и в backupdatadir /BACKUP/BACKUP-ID/ для каждого узла mysqld. Поле comment = MCM only в строке для параметра backupdatadir указывает, что backupdatadir используется только MySQL Cluster Manager, а каталог, который это определяет, содержит только резервные копии для метаданных таблиц NDB. Заметьте, что если BackupDataDir не задан, get не возвратит значение для него, и это поднимает значение DataDir, так что образ был сохранен в каталоге Datadir /BACKUP/BACKUP-backup_id. Если не указан backupdatadir, команда get не возвратит значение, а логические резервные файлы для узла mysqld должны быть найдены в местоположениях по умолчанию / path-to-mcm-data-repository/clusters/ clustername/nodeid /BACKUP/BACKUP-Id. Процесс восстановления поддержанных данных из оригинальной группы в новую состоит из следующих шагов: Остановите оригинальный кластер: mcm> stop cluster mycluster; +------------------------------+ | Command result | +------------------------------+ | Cluster stopped successfully | +------------------------------+ 1 row in set (19.54 sec) mcm> show status mycluster; +-----------+---------+---------+ | Cluster | Status | Comment | +-----------+---------+---------+ | mycluster | stopped | | +-----------+---------+---------+ 1 row in set (0.05 sec) Запустите свою новую группу. Удостоверьтесь, что новая группа готова к эксплуатации, и у нее есть по крайней мере один свободный слот ndbapi, чтобы утилита ndb_restore могла соединиться с группой: mcm> start cluster newcluster2nodes; +------------------------------+ | Command result | +------------------------------+ | Cluster started successfully | +------------------------------+ 1 row in set (33.68 sec) mcm> show status -r newcluster2nodes; +--------+----------+---------+---------+-----------+-----------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+---------+---------+-----------+-----------+ | 49 | ndb_mgmd | tonfisk | running | | mypackage | | 1 | ndbmtd | tonfisk | running | 0 | mypackage | | 2 | ndbmtd | tonfisk | running | 0 | mypackage | | 50 | mysqld | tonfisk | running | | mypackage | | 51 | ndbapi | * | added | | | +--------+----------+---------+---------+-----------+-----------+ 5 rows in set (0.09 sec) Восстановите логическую резервную копию метаданных таблиц NDB на новый кластер, см. здесь для различных способов восстановить логическую резервную копию. Один способ сделать это состоит в том, чтобы открыть клиент mysql, соединить его с узлом mysqld кластера и затем поставить логический резервный файл клиентом mysql: mysql> source path-to-logical-backup-file/BACKUP-BackupID.mysqld_nodeid.schema.sql См. здесь о том, как найти путь логического резервного файла. Для наших типовых групп эта команда похожа на команду для восстановления метаданных таблиц NDB из резервной копии с BackupID 2: mysql> source /opt/mcmbackup/BACKUP/BACKUP-2/BACKUP-2.50.schema.sql Восстановите одну за другой резервную копию для каждого узла данных оригинальной группы к новой группе, используя программу ndb_restore : shell> ndb_restore -b BackupID -n nodeID -r \ --backup_path=backup-folder-for-data_node См. здесь о том, как найти путь резервных файлов узла данных. Для наших типовых групп, чтобы восстановить данные из резервной копии с BackupID 2 для узлов данных 1-4 из mycluster, выполните: shell> ndb_restore --backupid=2 --nodeid=1 --restore_data \ --backup_path=/opt/mcmbackup/BACKUP/BACKUP-2/ \ --disable-indexes shell> ndb_restore --backupid=2 --nodeid=2 --restore_data \ --backup_path=/opt/mcmbackup/BACKUP/BACKUP-2/ \ --disable-indexes shell> ndb_restore --backupid=2 --nodeid=3 --restore_data \ --backup_path=/opt/mcmbackup/BACKUP/BACKUP-2/ \ --disable-indexes shell> ndb_restore --backupid=2 --nodeid=4 --restore_data \ --backup_path=/opt/mcmbackup/BACKUP/BACKUP-2/ \ --disable-indexes Опция --disable-indexes используется, чтобы индексы проигнорированы во время восстановления. Это вызвано тем, что, если мы также пытаемся восстановить узел индексов, они не могли бы быть восстановлены в правильном порядке для внешних ключей и ограничений уникального ключа, чтобы работать правильно. Поэтому опция --disable-indexes используется используется в вышеупомянутых командах, после выполнение которых мы восстанавливаем индексы командой ndb_restore с опцией --rebuild-indexes (необходимо выполнить только на одном из узлов данных): shell> ndb_restore --backupid=2 --nodeid=1 --rebuild-indexes \ --backup_path=/opt/mcmbackup/BACKUP/BACKUP-2/ Данные и индексы теперь полностью восстановлены на кластере. 3.7. Резервирование и восстановление агентов MySQL Cluster Manager Эта секция объясняет, как сохранить и восстановить данные конфигурации для агентов mcmd. Используемая вместе с командой backup cluster, backup agents позволяет вам делать копию и восстанавливать полную установку группы плюс менеджер. Если никакие имена хоста не заданы в команде backup agents, резервные копии создаются для всех агентов места: mcm> backup agents mysite; +-----------------------------------+ | Command result | +-----------------------------------+ | Agent backup created successfully | +-----------------------------------+ 1 row in set (0.07 sec) Чтобы сделать копию одного или нескольких определенных агентов, определите их с помощью опции --hosts: mcm> backup agents --hosts=tonfisk mysite; +-----------------------------------+ | Command result | +-----------------------------------+ | Agent backup created successfully | +-----------------------------------+ 1 row in set (0.07 sec) Если никакое название сайта не дано, только агент, с которым связан клиент mcm, поддерживается. Резервная копия для каждого агента включает следующее содержание хранилища агента (каталог mcm_data): Подкаталог rep. Файлы метаданных high_water_mark и repchksum. Хранилище блокировано в то время, как резервная копия создается, чтобы избежать создания непоследовательной резервной копии. Резервная копия для каждого агента создается в подкаталоге rep_backup/timestamp каталога агента mcm_data, где timestamp отражает время, когда резервная копия началась. Если вы хотите, чтобы резервная копия была в другом месте, создайте мягкую связь из mcm_data/rep_backup к вашему желаемому месту хранения. MySQL Cluster Manager 1.4.6 и позже : можно перечислить резервные копии агента, используя list backups с опцией --agent и именем места: 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) Чтобы восстановить резервную копию для агента: Сотрите содержание агентского каталога mcm_data/rep. Удалите файлы метаданных high_water_mark и repchksum из каталога mcm_data. Скопируйте все из каталога mcm_data/rep_backup/ timestamp/rep в каталог mcm_data/rep. Скопируйте файлы метаданных high_water_mark и repchksum из каталога mcm_data/rep_backup/ timestamp в каталог mcm_data. Перезапустите агент. Шаги иллюстрированы ниже: mysql@tonfisk$ cd mcm_data mysql@tonfisk$ cp mcm_data/rep_backup/timestamp/rep/* ./rep/ mysql@tonfisk$ cp mcm_data/rep_backup/timestamp/high_water_mark ./ mysql@tonfisk$ cp mcm_data/rep_backup/timestamp/repchksum ./ mysql@tonfisk$ mcm1.4.8/bin/mcmd Резервная копия может быть вручную восстановлена на один или больше агентов. Если резервная копия будет восстановлена только для одного агента на, скажем, хосте А, хост А свяжется с другими агентами места, чтобы заставить их получить свои хранилища от хоста с использованием обычного механизма для восстановления агента. Если все агенты на всех хостах будут восстановлены и перезапущены вручную, ситуация будет подобна нормальному перезапуску всех агентов после остановки их в немного отличающихся моментах времени. Если изменения конфигурации были сделаны в кластере после того, как восстановленная резервная копия была создана, те же самые изменения должны быть внесены снова, после того, как восстановление агента было закончено, чтобы гарантировать, что конфигурации агентов соответствуют фактически работающему кластеру. Например: когда-то после того, как резервная копия была сделана, была команда set MaxNoOfTables:ndbmtd=500 mycluster, затем что-то произошло и испортило хранилище агента, после того, как резервная копия агента была восстановлена, та же команда set должна быть запущена повторно, чтобы обновить конфигурации mcmd. В то время как команда ничего эффективно не изменяет в кластере после того, как ее выполнили, все еще требуется перезапуск процессов группы, используя restart cluster. 3.8. Восстановление агента MySQL Cluster Manager с данными от других агентов Иногда mcmd может не перезапуститься после сбоя потому, что хранилище конфигурации было повреждено (например, неправильным закрытием хоста). Если есть по крайней мере еще один агент mcmd , который все еще функционирует правильно на другом хосте группы, можно восстановить агент следующими шагами: MySQL Cluster Manager 1.4.6 и ранее: Удостоверьтесь, что mcmd был действительно остановлен. Пойдите в хранилище агента (каталог агента mcm_data). Сотрите содержание подкаталога rep . Удалите файлы метаданных high_water_mark и repchksum. Удалите файл manager.lck. Перезапустите агент. MySQL Cluster Manager 1.4.7 и позже: Удостоверьтесь, что mcmd был действительно остановлен. Перезапустите mcmd с опцией --initial , это удалит содержание подкаталога rep после резервирования и запустит агент. Агент тогда возвращает хранилище конфигурации от других агентов на других хостах. Однако, если все агенты mcmd кластера работают со сбоями, необходимо будет сделать одно из следующего: Восстановите один из агентов через резервную копию агента (см. раздел 3.7), затем восстановите другие агенты с него. Воссоздайте кластер и восстановите его, используя резервную копию кластера (см. раздел 3.6). 3.9. Подготовка репликации MySQL NDB Cluster с MySQL Cluster Manager Эта секция обеспечивает типовые шаги для подготовки репликации MySQL NDB Cluster с единственным каналом, используя MySQL Cluster Manager. Прежде, чем попробовать следующие шаги, рекомендуется, чтобы вы сначала прочитали этот раздел, чтобы ознакомиться с понятиями, требованиями, операциями и ограничениями репликации MySQL NDB Cluster. Создайте и запустите исходную группу: mcm> create site --hosts=tonfisk msite; mcm> add package --basedir=/usr/local/cluster-mgt/cluster-7.3.2 7.3.2; mcm> create cluster -P 7.3.2 -R \ ndb_mgmd@tonfisk,ndbmtd@tonfisk,ndbmtd@tonfisk,mysqld@tonfisk,mysqld@tonfisk,ndbapi@*,ndbapi@* \ source; mcm> set portnumber:ndb_mgmd=4000 source; mcm> set port:mysqld:51=3307 source; mcm> set port:mysqld:50=3306 source; mcm> set server_id:mysqld:50=100 source; mcm> set log_bin:mysqld:50=binlog source; mcm> set binlog_format:mysqld:50=ROW source; mcm> set ndb_connectstring:mysqld:50=tonfisk:4000 source; mcm> start cluster source; Создайте и запустите кластер точной копии (мы начинаем с создания нового места, названного ssite только для точной копии, можно пропустить это и разместить хосты обоих кластеров точной копии под тем же самым местом вместо этого): mcm> create site --hosts=flundra ssite; mcm> add package --basedir=/usr/local/cluster-mgt/cluster-7.3.2 7.3.2; mcm> create cluster -P 7.3.2 -R \ ndb_mgmd@flundra,ndbmtd@flundra,ndbmtd@flundra,mysqld@flundra,mysqld@flundra,ndbapi@*,ndbapi@* \ replica; mcm> set portnumber:ndb_mgmd=4000 replica; mcm> set port:mysqld:50=3306 replica; mcm> set port:mysqld:51=3307 replica; mcm> set server_id:mysqld:50=101 replica; mcm> set ndb_connectstring:mysqld:50=flundra:4000 replica; mcm> set slave_skip_errors:mysqld=all replica; mcm> start cluster replica; Создайте учетную запись точной копии (с именем пользователя myreplica и паролем mypw) на исходном кластерес соответствующей привилегией, регистрируясь в исходном клиенте репликации (mysql M ): mysqlM > GRANT REPLICATION SLAVE ON *.* TO 'myreplica'@'flundra' \ IDENTIFIED BY 'mypw'; Авторизуйтесь в клиенте кластера точной копии (mysqlS ) и скомандуйте: mysqlS > CHANGE MASTER TO MASTER_HOST='tonfisk', MASTER_PORT=3306, \ MASTER_USER='myreplica', \ MASTER_PASSWORD='mypw'; Запустите репликацию на кластере репликации: mysql S> START SLAVE; Вышеупомянутый пример предполагает, что кластеры (исходный и точной копии) создаются приблизительно в то же самое время без данных на обоих прежде, чем репликация начнется. Если исходный кластер уже работал и имеет данные, когда кластер репликации создается после шага 3 выше, выполните эти шаги, чтобы передать данные от исходного кластера и подготовить к репликации кластер точной копии: Зарезервируйте свой исходный кластер, используя backup cluster в MySQL Cluster Manager: mcm> backup cluster source; Только таблицы типа NDB поддерживаются командой, таблицы, использующие другие механизмы хранения MySQL, будут проигнорированы. Ищите ID резервной копии, перечисляя все резервные копии для исходного кластера: mcm> list backups source; +----------+--------+---------+---------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+---------------------+---------+ | 1 | 1 | tonfisk | 2014-10-17 20:03:23 | | | 1 | 2 | tonfisk | 2014-10-17 20:03:23 | | | 2 | 1 | tonfisk | 2014-10-17 20:09:00 | | | 2 | 2 | tonfisk | 2014-10-17 20:09:00 | | +----------+--------+---------+---------------------+---------+ Вы видите, что у последней резервной копии, которую вы создали, есть ID 2, данные резервного копирования существуют для узлов 1 и 2. Используя резервный ID и связанные ID узлов, определите резервные файлы, созданные в подкаталоге /mcm_data/clusters/ cluster_name/node_id /data/BACKUP/BACKUP-backup_id / в исходном инсталляционном каталоге кластера (в этом случае файлы в /mcm_data/clusters/source/1/data/BACKUP/BACKUP-2 и /mcm_data/clusters/source/2/data/BACKUP/BACKUP-2 ), скопируйте их к эквивалентным местам для кластера точной копии (в этом случае /mcm_data/clusters/replica/1/data/BACKUP/BACKUP-2 и /mcm_data/clusters/replica/2/data/BACKUP/BACKUP-2 в соответствии с инсталляционным каталогом кластера точной копии). После того, как копирование закончено, используйте следующую команду, чтобы проверить, что резервная копия теперь доступна для кластера точной копии: mcm> list backups replica; +----------+--------+---------+---------------------+---------+ | BackupId | NodeId | Host | Timestamp | Comment | +----------+--------+---------+---------------------+---------+ | 2 | 1 | flundra | 2014-10-17 21:19:00 | | | 2 | 2 | flundra | 2014-10-17 21:19:00 | | +----------+--------+---------+---------------------+---------+ Верните поддержанные данные кластеру точной копии (обратите внимание на то, что вам нужно неиспользуемый слот ndbapi для работы команды restore cluster): mcm> restore cluster --backupid=2 replica; На исходном клиенте используйте следующую команду, чтобы определить правильный двоичный файл журнала и положение для репликации, чтобы начать: mysqlM> SHOW MASTER STATUS\G; *************************** 1. row *************************** File: binlog.000017 Position: 2857 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: На клиенте кластера точной копии предоставьте информацию исходного кластера, включая имя файла двоичного журнала (опцией MASTER_LOG_FILE) и позицию (опцией MASTER_LOG_POS), которые вы обнаружили в шаге 5 выше: mysqlS > CHANGE MASTER TO MASTER_HOST='tonfisk', \ MASTER_PORT=3306, MASTER_USER='myreplica', \ MASTER_PASSWORD='mypw', MASTER_LOG_FILE='binlog.000017', \ MASTER_LOG_POS=2857; Запустите процесс репликации: mysql S> START SLAVE; Как альтернатива этим шагам, можно также выполнить шаги, описанные здесь, чтобы скопировать данные и определить двоичный файл журнала и положение для репликации, чтобы начать. 3.10. Даунгрейд NDB Cluster, включающий логический даунгрейд узлов MySQL В то время как команда upgrade cluster может использоваться, чтобы выполнить даунгрейд для NDB Cluster (см. описание команды upgrade cluster), специальные шаги требуются, когда это включает даунгрейд для mysqld, для которого не поддерживается оперативный даунгрейд. Например, от NDB Cluster 7.5 к 7.4 включает даунгрейд сервера MySQL с 5.7 на 5.6, для которого должен использоваться логический метод (см. здесь для получения информации о даунгрейде mysqld). Эта секция объясняет шаги, чтобы выполнить задачу. Давайте использовать этот типовой кластер в качестве примера: mcm> show status -r mycluster; +--------+----------+----------+---------+-----------+----------+ | NodeId | Process | Host | Status | Nodegroup | Package| +--------+----------+----------+---------+-----------+----------+ | 49 | ndb_mgmd | tonfisk | running | | 7.5-DMR1 | | 1 | ndbmtd | flundra | running | 0 | 7.5-DMR1 | | 2 | ndbmtd | grindval | running | 0 | 7.5-DMR1 | | 50 | mysqld | flundra | running | | 7.5-DMR1 | | 51 | mysqld | grindval | running | | 7.5-DMR1 | | 52 | ndbapi | * | added | | | +--------+----------+----------+---------+-----------+----------+ Предположим, что NDB Cluster был модернизирован от версии 7.4 до 7.5, пользователь столкнулся с большой проблемой и теперь должен вернуть кластер к версии 7.4: Сделайте копию всех данных кластера: mcm> backup cluster mycluster; +-------------------------------+ | Backup completed successfully | +-------------------------------+ Используйте mysqldump, чтобы сделать копию не-NDB данных каждого узла mysqld. Предположим, что пакет для более низкой версии NDB Cluster, до которой вы хотите понизить версию, все еще доступен MySQL Cluster Manager (если это не так, используйте add package, чтобы поставить пакет), используйте upgrade cluster с опцией --nodeid, чтобы понизить узлы управления и данных: mcm> upgrade cluster -P 7.4.10 --nodeid=49,1,2 --retry mycluster; +-------------------------------+ | Cluster upgraded successfully | +-------------------------------+ Не забудьте включить ВСЕ узлы управления и узлы данных с опцией --nodeid, но не учитывайте узлы mysqld. show status покажет, какие узлы были понижены: mcm> show status -r mycluster; +--------+----------+----------+---------+-----------+----------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+----------+---------+-----------+----------+ | 49 | ndb_mgmd | tonfisk | running | | 7.4.10 | | 1 | ndbmtd | flundra | running | 0 | 7.4.10 | | 2 | ndbmtd | grindval | running | 0 | 7.4.10 | | 50 | mysqld | flundra | running | | 7.5-DMR1 | | 51 | mysqld | grindval | running | | 7.5-DMR1 | | 52 | ndbapi | * | added | | | +--------+----------+----------+---------+-----------+----------+ Воссоздайте каталог данных для каждого узла mysqld: Остановите узел mysqld: mcm> stop process 50 mycluster; +-------------------------------+ | Process stopped successfully | +-------------------------------+ Удалите каталог данных узла mysqld и воссоздайте его как пустой: user@host$ cd mcm_data/clusters/mycluster/50/ user@host$ rm -rf data user@host$ mkdir data Инициализируйте воссозданный каталог данных, используя скрипт mysql_install_db в пакете версии NDB Cluster, до которой вы понижаете версию: user@host$ /clusters/7.4/scripts/mysql_install_db \ --defaults-file=/mcm_data/clusters/mycluster/50/cfg/my.cnf \ --datadir=/mcm_data/clusters/mycluster/50/data --basedir=/clusters/7.4.10 \ > mysql_install_db.log 2>&1 Когда вы понижаете до NDB Cluster 7.5 или позже, каталог данных mysqld должен быть инициализирован с помощью mysqld --initialize, см. подробности. Перезапустите узел mysqld через MySQL Cluster Manager (из-за снижения, уже выполненного раньше, узлы управления и данных mcmd собирается запустить узел mysqld с двоичными модулями кластера целевой версии): mcm> start process 50 mycluster; ERROR 9003 (00MGR): Tx {690be0d6 270 0 15} timed out on agent 0 @{19 0 50 Wait for mysqld to start} participants: 0@tonfisk:18620[X] 1@flundra:18620[ ] 2@grindval:18620[ ] Могла бы быть ошибка из-за тайм-аута как показано выше, которая появляется вследствие того, что пользователь mcmd все еще должен быть создан на узле mysqld (это происходит на следующем шаге). Ошибки можно избежать, если вы выполняете следующий шаг достаточно быстро. Но даже если ошибка происходит, здесь нет никакой проблемы, поскольку mcmd будет продолжать пытаться соединиться с узлом mysqld . Воссоздайте пользователя mcmd на узле mysqld: mysql> CREATE USER 'mcmd'@'127.0.0.1' IDENTIFIED BY '<manager-password>'; mysql> GRANT ALL PRIVILEGES ON *.* TO 'mcmd'@'127.0.0.1' IDENTIFIED BY \ '<manager-password>' WITH GRANT OPTION; mysql> FLUSH PRIVILEGES; Перезагрузите на узел mysqld не-NDB данные из резервной копии: mysql -h 127.0.0.1 -P 3306 -u root -p < dumpfile.sql Повторите шаг 4 выше и каждый из его подшагов для каждого узла mysqld . После того, как все узлы mysqld были понижены, а их каталоги данных подготовлены, mcmd в конечном счете снова соединяется с ними со всеми: mcm> show status -r mycluster; +--------+----------+----------+---------+-----------+---------+ | NodeId | Process | Host | Status | Nodegroup | Package | +--------+----------+----------+---------+-----------+---------+ | 49 | ndb_mgmd | tonfisk | running | | 7.4.10 | | 1 | ndbmtd | flundra | running | 0 | 7.4.10 | | 2 | ndbmtd | grindval | running | 0 | 7.4.10 | | 50 | mysqld | flundra | running | | 7.4.10 | | 51 | mysqld | grindval | running | | 7.4.10 | | 52 | ndbapi | * | added | | | +--------+----------+----------+---------+-----------+---------+

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

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