Глава 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_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 | | |
+--------+----------+----------+---------+-----------+---------+
|
|