Перейти к основному содержимому

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

Предусловия​

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

Процесс​

  1. Консоль управления получает запрос на запуск модуля process.json из UI консоли или через прямой вызов REST эндпоинт 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.
  9. Пользователь инициирует остановку графа в UI консоли.
  10. Браузер направляет DELETE-запрос на сервис консоли /process/{processID} с идентификатором графа.
  11. Консоль подключается к служебной базе данных, куда записывает информацию о графе.
  12. Консоль направляет воркеру команду на выполнение запроса на остановку процесса.
  13. Консоль возвращает ответ с кодом 200 и JSON c описанием заявки.
  14. Репликация останавливается, выполнение заявки графически отображается в UI.

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

При включенном режиме КВР:

  1. Консоль возвращает ответ с кодом 202 и создает заявку в КВР на остановку процесса.
  2. Заявка на остановку процесса отображается в UI во вкладке КВР.

Исключительные сценарии​

При неудаче старта процесса:

  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 не удаляются вне зависимости от статуса воркера.