Запуск и остановка модулей графа репликации#

Пререквизиты#

  • технические пользователи созданы и прописаны в конфигурацию (данные для подключения к БД);

  • сетевые доступы консоль-воркер, воркер-БД, воркер-Kafka открыты;

  • пользователь авторизовался под ролью APPADMIN или APPDUTY.

Процесс#

  1. Консоль управления получает запрос на запуск модуля process.json из UI консоли или через прямой вызов REST endpoint POST /process. При отсутствии доступных воркеров отправляет ответ на запрос POST /process с ошибкой создания процесса тому, от кого получила запрос.

  2. Консоль управления читает конфигурацию из БД по ID модуля, который пришел из запроса POST /process и выполняет валидацию конфигурации перед стартом процесса.

  3. Консоль управления отправляет в воркер REST запрос POST /start c JSON, описывающим конфигурацию запуска.

  4. Воркер получает рабочую конфигурацию (модуль) в запросе POST /start.

  5. Воркер открывает соединения к описанным в конфигурации ресурсам (БД, Kafka) и пытается запустить процесс репликации.

  6. При успешном запуске воркер возвращает код 204 на запрос POST /start.

  7. Консоль отправляет событие об успешном старте процесса в запросе POST /event.

  8. Статус воркера меняется на ACTIVE.

Альтернативные сценарии#

При неудаче старта процесса воркер возвращает ошибку в консоль управления.

При наличии ошибки в воркере консоль управления отправляет ответ на запрос POST /process с ошибкой создания процесса тому, от кого получила запрос.

При наступлении событий воркер отправляет консоли управления уведомления через POST /event(при остановке и ошибках во время репликации).

В процессе работы отвечает на запросы консоли на GET /status с определенным интервалом (асинхронный процесс).

  1. При ответе воркера на запрос /start об успешном запуске консоль управления помещает в таблицу grdl_process новую запись.

  2. Консоль продолжает цикл опроса состояния воркеров и запущенных на них процессов, вызывая GET /status.

  3. Консоль управления отправляет ответ на запрос POST /process с ID запущенного процесса тому, откуда она получила этот запрос.

  4. При отсутствии успешного ответа от воркера на опрос статуса, консоль переводит его в статус DETACHED и продолжает его опрос на протяжении времени, равном worker_detached_timeout (стендовый параметр).

  5. Если до истечения worker_detached_timeout успешный вызов был получен, то воркер переводится в статус READY или ACTIVE в зависимости от наличия запущенного процесса.

  6. Если успешного ответа получено не было, то воркер остается в статусе DETACHED, а связанный с ним процесс завершается.

  7. Строки в таблице grdl_worker не удаляются вне зависимости от статуса воркера.