4. Бекапирование Компонента «Витрины данных»

4.1. Реализация бекапирования в слое адаптеров Компонента «Витрины данных»

4.1.1. Работа модулей для обеспечения резервного копирования

Модули, подлежащие бекапированию, подписываются на топик adapter.command под одним groupId: (имя модуля)_adapter_command и создают продюсеров на топики:

adapter.status;
adapter.backup.

Все топики размещаются во внутренней кафке ADS.

Модули требующие консистентности с Prostore дополнительно подписываются на топик adapter.command.broadcast под уникальными groupId (случайными (имя модуля)_(UUID)).

Обработка команды не зависит от топика, через который она получена.

4.1.1.1. Сообщения в топиках команд

Таблица 4.7 Сообщения в топиках команд
Назначение команды	Топик	Ключ	Значение
Приостановка обработки запросов для модулей, которым требуется консистентность с Prostore	`adapter.command.broadcast`	backup.pause	null
Возобновление обработки запросов для модулей, которым требуется консистентность с Prostore	`adapter.command.broadcast`	backup.resume	null
Запрос персистированых данных из Zookeeper для резервной копии	`adapter.command`	backup.get	backupId
Применение данных резервной копии и запись персистированных данных в Zookeeper	`adapter.command`	backup.set	null

4.1.1.2. Статусы модулей

Статусы модулей возвращаются через компактный топик adapter.status

Формат сообщения статуса:

ключ в формате json (идентификатор вертикла и ключ шаблона присутствуют только для smev3-adapter):

{
    "group": "dev.nsud",
    "name": "smev3-adapter",
    "version": "4.0.13",
    "instance": "6f58378a-2205-42c9-80fc-c028ab12a3ba",
    "backupId": "2228378a-2205-42c9-80fc-c028ab12a222"
}

значение в формате json:

{
    "timestamp": "2023-02-17T12:10:45Z",
    "status": "started"
}

4.1.1.2.1. Значения статусов

Статус	Описание
started	работает
stopping	приостановка модуля для бекапирования
stopped	модуль приостановлен для бекапирования
restoring	модуль восстановлен из резервной копии
restored	модуль восстановлен из резервной копии
error_restoring	ошибка восстановления из резервной копии
error_stopping	ошибка приостановки модуля для бекапирования

4.2. Механизм приостановки модулей, требующих консистентности с Prostore

Все экземпляры модулей, требующих консистентности с Prostore подписаны на топик adapter.command.broadcast с уникальной groupId консьюмера: (имя модуля)_(UUID)) groupId.

4.2.1. Приостановка модулей, требующих консистентности с Prostore

Каждый экземпляр модуля считывает команду backup.pause из топика adapter.command.broadcast и отправляет статус stopping в топик adapter.status.
В каждом экземпляре модуля выполняется процесс приостановки процессов, влияющих на консистентные с Prostore данные.
После остановки всех процессов, каждый экземпляр модуля отправляет статус stopped в топик adapter.status.

4.2.2. Восстановление модулей, требующих консистентности с Prostore

Каждый экземпляр модуля считывает команду backup.resume из топика adapter.command.broadcast.
В каждом экземпляре модуля выполняется повторный запуск процессов, влияющих на консистентные с Prostore данные.
После остановки всех процессов, каждый экземпляр модуля отправляет статус started в топик adapter.status.

4.3. Механизм резервного копирования и восстановления из резервной копии в модулях слоя адаптеров

Модули, данные которых необходимы для резервного копирования:

CSV-Uploader;
REST-Uploader;
smev3-adapter;
counter-provider.

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

4.3.1. Механизм резервного копирования модулей слоя адаптеров

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

Подписаны на топик adapter.command с общей qroupId для каждого типа модулей.
Один из экземпляров модуля считывает сообщение`` backup.get`` из топика adapter.command.
Считывает метаданные, подлежащие бекапированию по пути в Zookeeper, в соответствии с путями хранения в сервисной БД.
Возвращает данные через топик adapter.backup в виде json.

В ключе сообщения формируются стандартные данные о версии и сборке:

{
    "group": "ru.itone.dtm.data.uploader"
    "name": "data-uploader",
    "version": "1.1.0-SNAPSHOT",
    "instance": "6f58378a-2205-42c9-80fc-c028ab12a3ba",
    "backupId": "2228378a-2205-42c9-80fc-c028ab12a222",
    "gitCommit": "a7c7770404ef61f62496983b783ef7b442989d74",
    "dateCommit": "2023-02-17T12:10:45Z",
    "branchCommit": "develop",
    "buildDate": "2023-02-17T12:11:36.627Z",
    "buildUnixTime": "1676635896"
}

В значении сообщения размещаются перситируемые данные, пример для модуля counter-provider.

{
"path":"/dev/counter-provider",
"value":"test_data",
"children":[
    {
        "path":"/dev/counter-provider/child2",
        "value":"",
        "children":[]
    },
    {
        "path":"/dev/counter-provider/child1",
        "value":"child1_data",
        "children":[]
    }
]
}

4.3.2. Механизм восстановления из резервной копии модулей слоя адаптеров

При выполнении резервного копирования все модули, участвующие в восстановлении из резервной копии:

Подписаны на топик adapter.command с общей qroupId для каждого типа модулей.
Один из экземпляров модуля считывает сообщение backup.set из топика adapter.command.
Отправляют статус restoring в топик adapter.status.
Удаляют данные по пути хранения метаданных в соответствии с путями хранения в сервисной БД.
Разбирают сообщения в топике adapter.backup: сначала фильтруют данные, относящиеся к модулю.
Записывают данные в сервисную БД.
Отправляют статус restored в топик adapter.status.

4.4. Поведение в случае ошибок при выполнении резервного копирования

В случае, если ошибки возникли в процессе восстановления из резервной копии, стоит обратить внимание на тот факт, что в этом случае Компонент «Витрины данных» будет находится в не консистентном состоянии, требуется оперативный разбор ошибок и повторное восстановление из резервной копии.

4.4.1. Ошибки резервного копирования и восстановления из резервной копии

Ошибки, возможные в процессе резервного копирования/восстановления из резервной копии, и пути их устранения приведены ниже (см. Таблица 4.8)

Таблица 4.8 Ошибки резервного копирования и восстановления из резервной копии
Ошибка	Описание ошибки	Действия утилиты Backup Manager	Устранение ошибки
«Observed active backupManager process, file backup.lock exists»	Не удален файл `backup.lock`	завершает процесс бекапирования/ восстановления с выводом ошибки «Observed active backupManager process, file backup.lock exists» выводит финальный статус: `BACKUP/RESTORE is failed`	Может возникать при прерванной работе утилиты, требуется ручное удаление файла
«Error stopping (module) (instanse) (verticle) (key), see modul log for detail»	Ошибка приостановки одного из инстансов модулей, требующих консистентности с Prostore	отправляет команду `backup.resume` на восстановление работы модулей в топик `adapter.command.broadcast` без ожидания статусов о восстановлении завершает процесс бекапирования/ восстановления с выводом ошибки «error stopping (module) (instanse) (verticle) (key), see modul log for detail» выводит финальный статус: `BACKUP/RESTORE is failed`	Требуется анализ логов модуля, в котором возникла ошибка, после ее устранения, повтор процесса бекапирования/восстановления
«timeout stopping (module) (instanse) (verticle) (key), see modul log for detail»	Таймаут приостановки одного из инстансов модулей, требующих консистентности с Prostore	отправляет команду backup.resume на восстановление работы модулей в топик `adapter.command.broadcast` без ожидания статусов о восстановлении завершает процесс бекапирования/ восстановления с выводом ошибки: «timeout stopping (module) (instanse) (verticle) (key), see modul log for detail» выводит финальный статус: `BACKUP/RESTORE is failed`	Требуется анализ логов модуля, в котором возникла ошибка, после ее устранения, повтор процесса бекапирования/восстановления
«timeout starting (module) (instanse), see modul log for detail»	Таймаут восстановления работоспособности одного из инстансов модулей, требующих консистентности с Prostore	завершает процесс бекапирования/ восстановления завершается с выводом ошибки : «timeout starting (module) (instanse), see modul log for detail» завершает процесс восстановления с выводом ошибки: «error restoring (module) (instanse), see modul log for detail» выводит финальный статус: `RESTORE is failed`	Требуется анализ логов модуля, в котором возникла ошибка, после ее устранения, повтор процесса бекапирования/восстановления
«timeout restoring (module) (instanse), see modul log for detail»	Таймаут восстановления из резервной копии модуля слоя адаптеров	отправляет команду `backup.resume` на восстановление работы модулей в топик `adapter.command.broadcast` без ожидания статусов о восстановлении завершает процесс восстановления с выводом ошибки: «timeout restoring (module) (instanse), see modul log for detail» выводит финальный статус: `RESTORE is failed`	Требуется анализ логов модуля, в котором возникла ошибка, после ее устранения, повтор процесса бекапирования/восстановления
Ошибки утилиты DTM-tools при создании резервной копии	Ошибки не формализованы	В случае не успеха процесса бекапирования утилиты DTM-tools: отправляет команду `backup.resume` на восстановление работы модулей в топик `adapter.command.broadcast` без ожидания статусов о восстановлении завершает процесс бекапирования с выводом ошибки, переданной DTM-tools выводит финальный статус: `BACKUP is failed`	Требуется анализ логов модуля, в котором возникла ошибка, после ее устранения, повтор процесса бекапирования/восстановления
Ошибки утилиты DTM-tools при восстановлении из резервной копии	Ошибки не формализованы	В случае не успеха процесса бекапирования утилиты DTM-tools: отправляет команду `backup.resume` на восстановление работы модулей в топик `adapter.command.broadcast` без ожидания статусов о восстановлении завершает процесс восстановления из бекапа с выводом ошибки, переданной DTM-tools выводит финальный статус: `RESTORE is failed`	Требуется анализ логов модуля, в котором возникла ошибка, после ее устранения, повтор процесса бекапирования/восстановления