Настройка репликации MySQL, аварийное переключение slave->master

• Увеличение производительности СУБД путем подключения к ней серверов для адаптации к возрастающей нагрузке. Производительность растет за счет выделения одного сервера преимущественно для модификации данных (master) и остальных для чтения данных (slaves). Данное решение особенно эффективно для веб-приложений: у данной категории приложений большая часть запросов к СУБД – запросы на чтение.
• Онлайн бэкап – данные передаются в режиме онлайн на резервные/slave-сервера. При отказе основного сервера на одном из резервных/slave серверов имеется “свежая” копия данных.
• Организация эффективного резервного копирования: бэкап делается с резервного сервера без прерывания /замедления работы основного сервера СУБД. При необходимости для осуществления целостного бинарного бэкапа СУБД (в особенности InnoDB) можно остановить на необходимое время резервный сервер, выполнить бэкап и запустить резервный сервер снова.
• Обеспечение высокой доступности: при выходе из строя одного из серверов СУБД система продолжает обрабатывать запросы.

Надежность репликации

Для обеспечения максимальной надежности репликации рекомендуется установить параметры MySQL следующим образом:
innodb_flush_log_at_trx_commit = 1

sync_binlog = 1
sync_relay_log = 1
sync_relay_log_info = 1

Для повышения производительности можно использовать такие параметры (чревато потерей данных нескольких транзакций в момент аварии на базе данных):

innodb_flush_log_at_trx_commit  = 2
sync_binlog = 0

Динамический hostname

Если у настраиваемого сервера динамический IP-адрес/hostname, рекомендуется явно задать параметры:

relay-log, relay-log-index.

Привилегии

Для работы репликации учетные записи основного и резервных master/slave-серверов должны иметь, кроме стандартных, также привилегии:

SUPER

REPLICATION CLIENT

REPLICATION SLAVE

Временные зоны

Если сервера СУБД кластера расположены в разных дата-центрах, необходимо настроить на них единую временную зону.

Администрирование репликации

Репликация после настройки работает надежно и требует минимального администрирования. Тем не менее, рекомендуется периодически проверять ее состояние утилитами мониторинга операционной системы (nagios, zabbix, monit, linux-ha).

В маловероятном случае возникновения ошибки на slave-сервере рекомендуется его переинициализировать – заново залить на него данные с основного сервера. Для этого нужно его Прекратить использовать, а затем Начать использовать в разделе Репликация (Настройки > Веб-кластер > Репликация).

Резервное копирование

Можно свободно останавливать slave-сервера, в т.ч. для осуществления логического и целостного бинарного резервного копирования средствами MySQL и операционной системы. При этом не прерывается работа основного сервера СУБД.

Переключение slave->master в случае отказа master

В случае отказа основного (master) сервера СУБД, необходимо вручную или автоматически скриптом переключить кластер на другой master-сервер СУБД. Для этого обычно slave-сервер, хранящий последние реплицированные данные, переводят в режим основного.

Общая схема этой процедуры такова:

1. Закрываем доступ клиентов к веб-приложениюЕсли используется двухуровневая конфигурация (фронтэнд nginx – бэкэнд apache и т.п.), рекомендуется на фронтэнде отключить доступ к бэкэнду (веб-приложению) и отдавать при обращении клиентов к кластеру информационную страницу о регламентных работах.
2. Останавливаем на всех slave-серверах поток получения обновлений бинарного лога с основного (master) сервера:

   STOP SLAVE IO_THREAD;
   SHOW PROCESSLIST;
   

   Ждем, пока от потока выполнения команд slave (SQL_THREAD) не появится сообщение "Has read all relay log; waiting for the slave I/O thread to update it", говорящее о том, что slave-сервер выполнил все команды из relay-лога в своей базе. Сразу останавливать slave командой STOP SLAVE не рекомендуется, т.к. не все SQL-команды могут быть выполнены из relay-лога (по причине отставания и т.п.), а при переключении slave на новый мастер, relay-лог будет очищен и, возможно, потеряется часть “непроигранных” данных.

3. Подготовка нового master-сервераУбеждаемся, что на slave-сервере, который мы хотим сделать master-сервером, бинарный лог ведется и не логируются запросы из master:

   SHOW VARIABLES LIKE 'log_bin';
   log_bin       | ON
   SHOW VARIABLES LIKE 'log_slave_updates';
   log_slave_updates | OFF

   Полностью останавливаем slave – потоки чтения бинарного лога и выполнения SQL-команд:

   STOP SLAVE;
   RESET MASTER;

   Команда RESET MASTER необходима для очистки бинарного лога нового master, иначе, если в бинарном логе будут записи (устаревшие и т.п.), они проиграются на подключаемых к нему slave-серверах. Такое возможно, если сервер был master с включенным бинарным логом, потом стал slave и перестал использовать бинарный лог, потом снова переводится в режим master.
   Итак, новый master подготовлен, у него очищен бинарный лог, и он готов обрабатывать запросы.

4. Переключение slave-серверов на новый master-серверНа всех slave-серверах выполняем:

   STOP SLAVE;
   CHANGE MASTER TO MASTER_HOST='#new_master_host_name#';
   START
   В момент выполнения на slave
   CHANGE MASTER ...
    очищается
    relay-лог
    slave-сервера, а позиция c которой читается бинарный лог master-сервера устанавливается, если не задано иное, в значение по умолчанию: первый файл бинарного лога, 4 позиция (т.е. в самое начало бинарного лога master-сервера).

5. Переключаем веб-приложение на новый master-серверНеобходимо настроить кластер на использование нового master-сервера.
6. Открываем доступ клиентов к веб-приложениюЕсли используется двухуровневая конфигурация (фронтэнд nginx – бэкэнд nginx+php-fpm и т.п.), на фронтэнде убираем информационную страницу о регламентных работах и переключаем запросы на бэкэнд (веб-приложение).В итоге кластер использует новый master-сервер.

Еще один способ переключения slaves на нового master

На мастере

FLUSH LOGS;

На слейве 1

STOP SLAVE;
RESET MASTER;

Optional: CHANGE MASTER TO MASTER_HOST=”;

На слейве 2

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST = 'SLAVE S1 hostname';
RESET SLAVE;
START SLAVE;