Mysql репликация и переключение на новый мастер

Автор:human

Mysql репликация и переключение на новый мастер

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

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

Примечание: Подробнее о примерах использования репликации MySQL читайте в официальной документации.

 

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

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

Примечание: Установка именно таких параметров может привести к общему снижению производительности системы.

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

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

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

Привилегии

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

Учетные записи

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

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

 

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

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

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

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

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

 

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

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

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

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

    Ждем, пока от потока выполнения команд 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:

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

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

    В момент выполнения на slave

    очищается

    slave-сервера, а позиция c которой читается бинарный лог master-сервера устанавливается, если не задано иное, в значение по умолчанию: первый файл бинарного лога, 4 позиция (т.е. в самое начало бинарного лога master-сервера).

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

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

На мастере

На слейве 1

Optional: CHANGE MASTER TO MASTER_HOST=»;

На слейве 2

Об авторе

human administrator

    Оставить ответ

    Войти с помощью: 

     

    Яндекс.Метрика