Управление процессом отказоустойчивости#

Переключение трафика между серверами#

Примечание

Перед выполнением действий из статьи должен быть настроен keepalived по инструкции для настройки keepalived.

Внимание

Перед выполнением переключения необходимо убедиться, что репликация завершила синхронизацию данных.
Критерием готовности является значение поля Seconds_Behind_Master равное нулю, что указывает на отсутствие отставания реплики от мастера.

Для переключения трафика с основного сервера на резервный достаточно, чтобы VIP на некоторое время перестал получать сигналы от keepalived.

  1. Как переключить трафик на резервный сервер.

    Примечание

    Выполнять эту команду НЕ требуется, если нет необходимости вручную переключать трафик с основного сервера на резервный.

    Команда для перезапуска keepalived, которая также переключает трафик с основного сервера на резервный (её необходимо выполнять на активном основном сервере):

    Внимание

    Обратите внимание, что переключение домена со старого IP к IP VIP требует время. В этом случае не рекомендуется переключать или отключать keepalived на текущем мастер-сервере.

    sudo systemctl restart keepalived

    На резервном сервере проверьте логи на наличие ошибок:

    sudo tail -n 100 /var/log/keepalived-state.log

    Данную команду рекомендуется использовать, если нужно вручную переключить трафик с активного основного сервера на резервный — например, для бесшовного обновления сервера.

    Одновременно с переключением на основном сервере отключается lsyncd — файлы с этого сервера перестают отправляться на резервный.

    На резервном сервере в этот момент lsyncd запустится автоматически. Уже новые файлы с резервного сервера отправляются на основной.

  2. После переключения рекомендуется проверить состояние серверов, чтобы убедиться что переключение сработало корректно:

    Проверьте, что VIP IP переключился на резервный сервер:

    ip a | grep <VIP IP>

    Проверьте, является ли основной и резервный сервера текущим активным сервером:

    sudo python3 script/replication/check_current_master_server.py

    Примечание

    В случае некорректного переключения рекомендуется проверить логи lsyncd.

  3. На резервном сервере после переключения отключается процесс автоматической репликации баз данных с основного сервера.

    Предупреждение

    Репликация баз данных автоматически НЕ включается.

    Если вы переключили трафик с основного сервера на резервный, то для запуска обратной репликации:

    На основном сервере перейдите в директорию инсталлятора:

    cd <путь к инсталлятору Compass>

    На основном сервере запустите репликацию с резервного сервера командами:

    sudo python3 script/replication/start_slave_replication.py --type monolith

    sudo python3 script/replication/start_slave_replication.py --type team

    Предупреждение

    Запуск скриптов старта репликации необходимо выполнять на тех серверах, которые НЕ являются активным.

    В случае ошибки репликации рекомендуется использовать скрипты из раздела «Диагностика ошибок репликации».

    После действий выше активным сервером является резервный сервер, а «горячим резервом» для него — бывший основной сервер.

Изменение конфигурационных файлов#

Изменения для конфигурационных файлов требуется вносить на основном и резервном серверах.

После внесения изменений необходимо выполнить на обоих серверах обновление с помощью скрипта:

sudo python3 script/update.py

Это также касается запуска скриптов, которые затрагивают конфигурационные файлы. Такие скрипты требуется запускать на основном и резервном серверах.
Рекомендуется выполнять обновление сначала на резервном сервере, затем на основном.

Процесс обновления серверной части приложения#

Для обновления серверной части приложения необходимо обновить установщик. Для этого на основном и резервном серверах перейдите в директорию ранее загруженного установщика и выполните команду:

git pull

После выполнения команды установщик будет готов к дальнейшему обновлению серверной части.

Редактирование конфигурационных файлов и последующий запуск скрипта для обновления необходимо выполнять на основном и резервном серверах.

Предупреждение

Обратите внимание: иногда процесс обновления включает дополнительные команды. Полная и актуальная инструкция приведена в разделе обновление серверной части приложения.

Первым делом обновим сервер, который не является активным для использования пользователями, например, резервный.

Выполните команду для запуска скрипта обновления серверной части на резервном сервере:

sudo python3 script/update.py

После завершения обновления переключите пользователей с основного сервера на резервный, чтобы появилась возможность обновить основной сервер.

Предупреждение

Репликация на текущий момент с основного сервера на резервный должна быть включена, чтобы не было расхождения в данных баз данных между серверами.

Выполните перезапуск keepalived на основном сервере:

sudo systemctl restart keepalived

На резервном сервере проверьте логи на наличие ошибок:

sudo tail -n 100 /var/log/keepalived-state.log

Выполните команду на резервном сервере, чтобы убедиться, что он стал активным:

ip addr show | grep <внутренний IP VIP>

Если команды выдаст результат - значит резервный сервер является активным.

Выполните обновление серверной части на основном сервере:

sudo python3 script/update.py

После завершения обновления необходимо запустить репликацию на основном сервере, чтобы получить изменения с активного резервного сервера:

sudo python3 script/replication/start_slave_replication.py --type monolith

sudo python3 script/replication/start_slave_replication.py --type team

После завершения репликации выполните перезапуск keepalived на резервном сервере, чтобы основной сервер снова стал активным:

sudo systemctl restart keepalived

Далее запустите репликацию на резервном сервере, чтобы получить изменения с основного активного сервера:

sudo python3 script/replication/start_slave_replication.py --type monolith

sudo python3 script/replication/start_slave_replication.py --type team

Создание нового пространства#

После создания нового пространства необходимо настроить для него репликацию.

  1. Так как процесс асинхронный, необходимо дождаться, когда новое пространство появится на неактивном сервере.

    В выводе скрипта create_team.py после успешного создания получите номер порта, который использует новое пространство. Затем на резервном сервере проверьте, что контейнер mysql успешно запущен для нового пространства, подставив порт в следующую команду:

    while true; do sudo docker ps | grep mysql-<порт нового пространства> \
  && break; sleep 2; done

    Дождитесь, когда команда отобразит результат - контейнер mysql с указанным портом.

  2. Запустите на резервном сервере скрипт для создания mysql-пользователя для репликации:

    sudo python3 script/replication/create_mysql_user.py --type team

    Дождитесь завершения работы скрипта.

  3. На резервном сервере запустите скрипты для старта репликации с основного на резервный сервер:

    sudo python3 script/replication/start_slave_replication.py --type team

    Дождитесь завершения работы скрипта.

Диагностика ошибок репликации#

Если репликация не завершается успешно, используйте команды ниже для получения данных об ошибке.

Проверьте значение лейблов на обоих серверах:

grep service_label src/values.compass.yaml

Ответ команды для настроенных на отказоустойчивость серверов должен выдать:

service_label: primary        # лейбл для сервера primary
master_service_label: primary # лейбл сервера, который выступает активным для других

Для резервного сервера ответ будет выглядеть следующим образом:

service_label: reserve        # лейбл для сервера reserve
master_service_label: primary # лейбл сервера, который выступает активным для других

Запустите следующие команды для проверки статуса репликации:

sudo python3 script/replication/show_slave_replication_status.py --type monolith

sudo python3 script/replication/show_slave_replication_status.py --type team

Скрипт выведет данные по статусу репликации, которые подскажут в чём может быть ошибка.

Далее рекомендуется использовать скрипт для сброса репликации:

sudo python3 script/replication/reset_slave_replication.py --type monolith

sudo python3 script/replication/reset_slave_replication.py --type team

После сброса требуется повторно запустить старт репликации:

sudo python3 script/replication/start_slave_replication.py --type monolith

sudo python3 script/replication/start_slave_replication.py --type team

Восстановление после сбоя основного сервера#

Рассмотрим ситуацию, когда у нас имеются:

  • основной сервер (активный), на который сейчас отправляется трафик;

  • резервный сервер, выступающий «горячим резервом».

Допустим, основной сервер по техническим неполадкам остановился. В этом случае весь трафик переключается на резервный сервер, который становится активным в этой ситуации.
На резервном сервере включается lsyncd для отправки новых файлов на основной сервер, когда тот станет исправным. Репликация на резервном сервере остановилась, на основном — сейчас недоступна.

Теперь, основной сервер снова стал доступным.

Важные моменты:

  • трафик на основной сервер автоматически НЕ переключается;

  • приложение lsyncd на основном сервере автоматически НЕ включается;

  • репликация баз данных на основном сервере автоматически НЕ включается.

Примечание

lsyncd на основном сервере так и должен оставаться выключенным. Он включится автоматически при переключении активного сервера на основной.

Теперь потребуется подтянуть все изменения в базах данных с резервного сервера на основной.
Для этого первым делом на основном сервере запустите скрипты для перезапуска настроек репликации:

sudo python3 script/replication/reset_slave_replication.py --type monolith

sudo python3 script/replication/reset_slave_replication.py --type team

После этого на основном сервере запустите скрипты для старта репликации:

sudo python3 script/replication/start_slave_replication.py --type monolith

sudo python3 script/replication/start_slave_replication.py --type team

Дождитесь завершения репликации.

Доступные проверки отказоустойчивости#

Чтобы узнать какой сервер сейчас выступает активным выполните команду:

ip addr show | grep <внутренний IP VIP>

Если команды выдаст результат - сервер, на котором она выполнялась, является активным.

Чтобы узнать состояние репликации на сервере, запустите скрипты:

sudo python3 script/replication/show_slave_replication_status.py --type monolith

sudo python3 script/replication/show_slave_replication_status.py --type team

Эти скрипты покажут информацию о статусе репликации в базах Pivot и команд.

Для просмотра статуса lsyncd используйте команду:

sudo systemctl status lsyncd

Примечание

На сервере, который на данный момент не является активным сервером, lsyncd должен быть выключен.

После переключения или отключения сервера также рекомендуется проверить переключение лейблов на серверах.
Для этого выполните команду:

grep service_label src/values.compass.yaml

Ответ команды для настроенных на отказоустойчивость серверах должен выдать:

service_label: primary        # лейбл для сервера primary
master_service_label: primary # лейбл того сервера, что выступает активным для других

Для резервного сервера ответ будет выглядеть следующим образом:

service_label: reserve        # лейбл для сервера reserve
master_service_label: primary # лейбл того сервера, что выступает активным для других

Если в ответе «master_service_label» для серверов выдаёт разный результат или пустую строку — значит что-то пошло не так.
В этом случае рекомендуется написать нам в пространстве поддержки On-premise, Telegram или на почту support@getcompass.ru, чтобы получить индивидуальную поддержку.

Примечание

Статьи по настройке отказоустойчивости:

Напишите нам в пространстве поддержки On-premise, Telegram или на почту support@getcompass.ru, чтобы получить индивидуальную демонстрацию функционала и помощь по вопросам интеграции мессенджера в вашей компании.