Аварийное переключение в случае отказа master
Если вышел из строя master |
Если отказал основной (master) сервер СУБД, то вручную или автоматически скриптом переключите кластер на другой master-сервер СУБД. Slave-сервер, хранящий последние реплицированные данные, станет основным.
Общая схема этой процедуры:
- Закрываем доступ клиентов к веб-приложению
В двухуровневой конфигурации (фронтэнд nginx - бэкэнд apache и т.п.) на фронтэнде отключите доступ к бэкэнду (веб-приложению) и отдавайте при обращении клиентов информационную страницу о регламентных работах.
Остановите на всех 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-лог будет очищен и, возможно, потеряется часть "непроигранных" данных.- Подготовка нового 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 подготовлен, у него очищен бинарный лог, и он готов обрабатывать запросы.
- Переключение slave-серверов на новый master-сервер
На всех slave-серверах выполняем:
STOP SLAVE; CHANGE MASTER TO MASTER_HOST='#new_master_host_name#'; START SLAVE;
В момент выполнения на slave
CHANGE MASTER ...
очищается relay-лог slave-сервера, а позиция c которой читается бинарный лог master-сервера устанавливается, если не задано иное, в значение по умолчанию: первый файл бинарного лога, 4 позиция (т.е. в самое начало бинарного лога master-сервера). - Переключаем веб-приложение на новый master-сервер
Необходимо настроить кластер на использование нового master-сервера. Для этого вписываем его характеристики (
$DBHost
) в файл/bitrix/php_interface/dbconn.php
. Затем, если интервал синхронизации статического контента кластера достаточно велик, вручную запускаем процесс синхронизации на master-сервере:csync2 - x
(см. урок Синхронизация данных между серверами Задачу организации общего файлового хранилища данных веб-кластера можно решить разными, хорошо известными способами, начиная от "расшаривания" папки с файлами продукта на одной из нод, заканчивая высокопроизводительными SAN/NAS-решениями уровня предприятия.
Подробнее ... ). - Открываем доступ клиентов к веб-приложению
В двухуровневой конфигурации (фронтэнд nginx - бэкэнд apache и т.п.), на фронтэнде уберите информационную страницу о регламентных работах и переключите запросы на бэкэнд (веб-приложение).
В итоге кластер использует новый master-сервер.
- Подключение вышедшего из строя master-сервера как slave-сервера
В административном разделе на странице Репликация Репликация базы данных - это процесс создания и поддержания в актуальном состоянии её копии .
Подробнее... (Настройки > Веб-кластер > Репликация) нажимаем Добавить slave базу данных и следуем указаниям мастера. Происходит переинициализация slave-сервера: в него переносится текущая база данных с master-сервера и включается репликация.
Подробнее ... удалить этот слейв.
и Ваше мнение важно для нас