Изменение реплики на главную

В этой статье описано, как изменить реплику на главную и, по желанию, установить прежнюю главную как реплику для новой главной.

Типичный сценарий, когда это полезно, — это когда вы установили новую версию MariaDB в качестве реплики, например, для тестирования, и хотите обновить свой главный сервер до новой версии.

В репликации MariaDB реплика должна быть версии, равной или новее, чем у главного сервера. Поэтому перед изменением реплики на главную необходимо сначала обновить все реплики до последней версии. В некоторых случаях реплика может быть более старой версии, чем главный сервер, но только если вы не выполняете на главном сервере команды SQL, которые реплика не понимает. Однако это не гарантируется между всеми основными версиями MariaDB.

Обратите внимание, что в примерах ниже используется [connection_name] в качестве названия подключения. Если вы не используете именованные подключения, можете пропустить эту информацию.

Остановка исходного главного сервера

Сначала необходимо остановить исходный главный сервер таким образом, чтобы реплика получила всю информацию о главном сервере.

Если вы используете полусинхронную репликацию, вы можете просто остановить сервер с помощью команды SHUTDOWN, так как реплики должны автоматически быть обновлены.

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

Если ни одно из вышеперечисленного не относится к вам, нужно выполнить эту операцию вручную:

Вручную остановить главный сервер

Сначала нам нужно установить главный сервер в режим только для чтения, чтобы гарантировать отсутствие новых обновлений на главном сервере:

FLUSH TABLES WITH READ LOCK;

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

Затем вам необходимо проверить текущую позицию главного сервера:

SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000003 |      343 |              |                  |
+--------------------+----------+--------------+------------------+
SELECT @@global.gtid_binlog_pos;
+--------------------------+
| @@global.gtid_binlog_pos |
+--------------------------+
| 0-1-2                    |
+--------------------------+

И подождите, пока у реплики не будет той же позиции: (Следующее должно быть получено на реплике)

SHOW SLAVE [connection_name] STATUS;
+-------------------+-------------------+
Master_Log_File     | narttu-bin.000003 +
Read_Master_Log_Pos | 343               +
Exec_Master_Log_Pos | 343               +
...
Gtid_IO_Pos          0-1-2              +
+-------------------+-------------------+

Самая важная информация для наблюдения — Master_Log_File и Exec_Master_Log_Pos, так как при совпадении с главным сервером это означает, что все транзакции были подтверждены на реплике.

Обратите внимание, что Gtid_IO_Pos на реплике может содержать множество различных позиций, разделенных запятыми, если реплика была подключена к множеству разных главных серверов. Важно, чтобы все последовательности, которые есть на главном сервере, также были на реплике.

После того, как реплика будет обновлена, вы можете остановить ГЛАВНОЙ сервер. Это должно быть выполнено в той же сессии, где вы выполнили FLUSH TABLES WITH READ LOCK.

SHUTDOWN;

Подготовка реплики к назначению главной

Остановить все старые подключения к старому главному серверу(ам) и сбросить режим только для чтения, если он был включен. Вы также хотите сохранить значения SHOW MASTER STATUS и gtid_binlog_pos, так как вам могут понадобиться эти значения для настройки новых реплик.

STOP ALL SLAVES;
RESET SLAVE ALL;
SHOW MASTER STATUS;
SELECT @@global.gtid_binlog_pos;
SET @@global.read_only=0;

Подключение других реплик к новому главному серверу

На других репликах укажите их на новый главный сервер (реплика, которую вы повысили до главного).

STOP SLAVE [connection_name];
CHANGE MASTER [connection_name] TO MASTER_HOST="new_master_name",
MASTER_PORT=3306, MASTER_USER='root', MASTER_USE_GTID=current_pos,
MASTER_LOG_FILE="XXX", MASTER_LOG_POS=XXX;
START SLAVE;

Значения XXX для MASTER_LOG_FILE и MASTER_LOG_POS должны соответствовать значениям, полученным из команды SHOW MASTER STATUS после завершения настройки реплики.

Переключение старого главного сервера на реплику

Теперь вы можете обновить новый главный сервер до более новой версии MariaDB, а затем выполнить ту же процедуру, чтобы подключить его как реплику.

При запуске исходного главного сервера рекомендуется запустить исполняемый файл mysqld с параметрами --with-skip-slave-start и --read-only, чтобы гарантировать, что старые конфигурации реплики не приведут к конфликтам.

По той же причине рекомендуется выполнить следующие команды на старом главном сервере (так же, как и для других реплик, но с дополнительной безопасностью). Параметр read_only ниже предназначен для того, чтобы предотвратить случайные попытки обновления старого главного сервера со стороны старых приложений. Он влияет только на обычные подключения к реплике, а не на изменения с нового главного сервера.

set @@global.read_only=1;
STOP ALL SLAVES;
RESET MASTER;
RESET SLAVE ALL;
CHANGE MASTER [connection_name] TO MASTER_HOST="new_master_name",
MASTER_PORT=3306, MASTER_USER='root', MASTER_USE_GTID=current_pos,
MASTER_LOG_FILE="XXX", MASTER_LOG_POS=XXX;
START SLAVE;

Перенос приложений на использование нового главного сервера

Теперь вы должны настроить ваши приложения на использование нового главного сервера. Если вы используете прокси-сервер MariaDB MaxScale, то вам не нужно выполнять этот шаг, так как MaxScale позаботится о перенаправлении запросов записи на новый главный сервер.

См. также

• команда CHANGE MASTER TO
• Блог MaxScale о использовании Switchover для переключения главного и реплики
• Блог Percona о том, как обновить реплику до главного сервера