Если отказал основной (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-сервера и включается репликация.