Руководство по восстановлению системы

Настоящее руководство необходимо для быстрого восстановления системы в случае различных сбоев и выхода из строя компонент.

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

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

При частичном выходе из строя компонент в большинстве случаев достаточно просто перезагрузить его (или ознакомиться со статьей Устранение ошибок).

Рассматриваемые схемы развертывания

Документ подойдет для следующих ситуаций:

1. standalone-инсталляция системы, когда необходимо восстановить вышедшую из строя систему на том же хосте.
2. Использование второго (пассивного) плеча, готового и настроенного для запуска при выходе из строя активного плеча.

Основные шаги восстановления системы

Для успешного восстановления работоспособности необходимо обеспечить 2 условия:

1. Восстановления данных в операционной БД и аналитической БД.
2. Восстановление настроек системы.

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

При использовании active-passive системы рекомендуется держать образы на passive-плече в актуальном состоянии (аналогично active-плечу).

Алгоритм восстановления системы

Шаг 1. Восстановление данных

Слой данных рекомендуется держать отдельно от сервисного слоя системы.

Рекомендации по резервному копированию и восстановлению описаны на соответствующей странице.

В случае standalone установки разверните компоненты Redis, Clickhouse (или Postgres) и RabbitMQ на новом сервере и восстановите их данные из резервных копий.

Запустите компоненты и проверьте факт восстановления данных.

Например, для clickhouse можно выполнить SQL-запрос, который подтвердит наличие таблиц и их размеры:

SELECT * FROM SYSTEM.TABLES WHERE DATABASE = 'название вашей базы данных'

Шаг 2. Восстановление настроек

Для более быстрого и бесшовного запуска нового инстанса (включая пассивное плечо) рекомендуется выполнять резервное копирование настроек системы (docker-compose файл, helm chart и тд).

Способы репликации:

1. Ведение документа с настройками, который является мастер-справочником.
2. Использование утилит бэкапа для копирования и восстановления файла.

Файлы настроек обычно выглядят как главный yaml-файл с описанием сервисов и .env-файл, в котором хранятся переменные среды.
В зависимости от предпочтений и желания администратора системы состав таких настроек и количество файлов может быть изначально другим (например образы broker и clickhouse заданы в другом yaml-файле), соответственно количество и состав может быть другим.

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

Шаг 3. Восстановление образов системы

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

docker-compose -f <путь к вашему compose-файлу> pull

Если вы используете образы из сжатых gz-архивов, загрузите данные архивы на диск сервера, а затем загрузите их в локальное хранилище образов командой

docker load < <путь к вашему .tar.gz архиву с образами>

Если система представлена в нескольких архивах выполните данную команду последовательно для каждого архива.

Шаг 4. Запуск и проверка работоспособности

После успешного запуска компонент и восстановления настроек запустите систему командой

docker-compose -f <путь к вашему compose-файлу> up -d

Или, если вы используете docker-swarm:

docker stack deploy -c <путь к вашему compose-файлу> accelera

После успешного запуска системы проверьте логи на отсутствие ошибок

docker-compose -f <путь к вашему compose-файлу> logs -f --tail N

где N - количество последних строк лога для просмотра.

Или, если вы используете docker-swarm:

docker service logs -f --tail N accelera_<имя сервиса, например flows_backoffice>

В полученном логе убедитесь, что все компоненты успешно подключены.

Затем войдите в интерфейс системы и убедитесь, что данные из резервных копий восстановлены и в системе есть ранее настроенные сущности (сценарии, сегменты, профили, аудитории).

Заметки о параллельном запуске

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

Для разных ситуаций разные ответы:

В случае, если БД и RabbitMQ запущены как отдельные компоненты (active имеет свой сервер, passive - свой, на который была развернута резервная копия), то в параллельной работе нет никаких проблем, убедитесь, что основной инстанс запущен и работает в штатном режиме, затем отключайте passive.

Если БД и RabbitMQ запущены как общие компоненты, на которые смотрит как active так и passive узлы, возможна проблема двойного запуска задач. Она касается сервисов timers и segments. А также, в некоторых случаях, engine.
Timers при запуске в двух экземплярах будет отправлять два таймера (хотя необходим только один). Segments в случае запуска кампании во временной промежуток восстановительных работ будет запускать одну кампанию дважды (они завершатся с ошибкой).

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