Аварийное переключение в случае отказа master

Урок 247 из 293
Автор: Роберт Басыров
Сложность урока:
3 уровень - средняя сложность. Необходимо внимание и немного подумать.
3 из 5
Просмотров: 12163
Дата изменения: 15.01.2024
Недоступно в лицензиях:
Текущую редакцию Вашего 1С-Битрикс можно просмотреть на странице Обновление платформы (Marketplace > Обновление платформы).
Старт, Стандарт, Малый бизнес, Бизнес

Если вышел из строя 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;
    

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

  5. Переключаем веб-приложение на новый master-сервер

    Необходимо настроить кластер на использование нового master-сервера. Для этого вписываем его характеристики ($DBHost) в файл /bitrix/php_interface/dbconn.php. Затем, если интервал синхронизации статического контента кластера достаточно велик, вручную запускаем процесс синхронизации на master-сервере: csync2 - x (см. урок Синхронизация данных между серверами Задачу организации общего файлового хранилища данных веб-кластера можно решить разными, хорошо известными способами, начиная от "расшаривания" папки с файлами продукта на одной из нод, заканчивая высокопроизводительными SAN/NAS-решениями уровня предприятия.

    Подробнее ...
    ).

  6. Открываем доступ клиентов к веб-приложению

    В двухуровневой конфигурации (фронтэнд nginx - бэкэнд apache и т.п.), на фронтэнде уберите информационную страницу о регламентных работах и переключите запросы на бэкэнд (веб-приложение).

    В итоге кластер использует новый master-сервер.

  7. Подключение вышедшего из строя master-сервера как slave-сервера

    В административном разделе на странице Репликация Репликация базы данных - это процесс создания и поддержания в актуальном состоянии её копии .

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

Примечание: После того, как слейв стал мастером (после аварии), необходимо на странице Slave базы данных Подключение к сайту дополнительных серверов баз данных позволяет снизить нагрузку на основную базу данных. В этом случае чтение данных происходит из дополнительных (slave) баз данных, а запись - в основную.

Подробнее ...
удалить этот слейв.


Нам жаль это слышать… Но мы постараемся быть лучше!

Мы благодарны Вам за помощь в улучшении документации.

Спасибо, мы рады что смогли помочь Вам. Ниже Вы можете оставить свой отзыв или пожелание :)
Мы стараемся сделать документацию понятнее и доступнее,
и Ваше мнение важно для нас
Курсы разработаны в компании «1С-Битрикс»