Перейти к содержанию

Recovery сценарии

После перезапуска DataHUB

DataHUB — stateless сервис: при перезапуске он восстанавливается автоматически и переподключается к RabbitMQ и PostgreSQL.

Что нужно проверить после перезапуска:

  1. RabbitMQ и PostgreSQL доступны до запуска DataHUB (зависимость в docker-compose).
  2. Очереди в RabbitMQ не удалились: DataHUB создаёт очереди при старте, но если RabbitMQ тоже перезапускался — убедиться, что очереди с флагом durable: true сохранились.
  3. Сообщения, которые были «в полёте» в момент остановки, DataHUB повторно доставит — получатели должны быть идемпотентными.

После перезапуска RabbitMQ

RabbitMQ с персистентными очередями (durable: true) сохраняет сообщения между перезапусками.

  1. После старта RabbitMQ перезапустить DataHUB, чтобы он переподключился к брокеру.
  2. Очереди без флага durable будут удалены — перезапуск DataHUB пересоздаст их.
  3. Сообщения из non-durable очередей будут потеряны — DataHUB не хранит копию.

После перезапуска PostgreSQL

  1. PostgreSQL поднимается с данными из volume — данные сохраняются.
  2. После старта PostgreSQL перезапустить DataHUB.
  3. Если при старте DataHUB в логах password authentication failed — убедиться, что пароль в конфигурации DataHUB совпадает с актуальным паролем пользователя в БД (не переменной POSTGRES_PASSWORD, а через ALTER USER).

После перезапуска 1С-сервера

  1. Регламентное задание «ДатаХабОбменСДатаХаб» восстановится автоматически — проверить через Администрирование → Регламентные задания.
  2. Если токен истёк за время простоя — нажать «Авторизация» в форме настроек для получения нового токена.
  3. Проверить «Текущее состояние» в форме настроек — нет ли накопившихся ошибок.
  4. Входящие сообщения, которые DataHUB пытался доставить во время простоя 1С, будут повторно доставлены при возобновлении опроса.

После сбоя сети между 1С и DataHUB

  1. Соединение восстанавливается автоматически при следующем цикле регламентного задания.
  2. Сообщения, отправленные в период сбоя, остаются в очереди исходящих со статусом «Ожидание отправки» и будут отправлены при восстановлении соединения.
  3. Входящие сообщения накапливаются в RabbitMQ и будут доставлены после восстановления.
  4. При длительном простое проверить, не истёк ли refresh token — при истечении потребуется ручная повторная авторизация.

После перезапуска MinIO (S3)

MinIO хранит данные в volume — файлы сохраняются между перезапусками.

  1. После старта MinIO проверить доступность: curl http://<minio-host>:9000/minio/health/live.
  2. Если получатели получали 403 во время простоя MinIO — это нормально; presigned URL в сообщениях остаются корректными до истечения срока действия.
  3. Проверить, не истёк ли срок presigned URL для сообщений, полученных во время простоя.

Аварийный сброс зависших сообщений

Если после восстановления инфраструктуры часть сообщений осталась в нештатных статусах:

  1. Статус «В обработке» без движения — признак того, что процесс прервался. Сбросить на «Ожидание обработки».
  2. Статус «Ошибка обработки» — исправить причину ошибки, затем сбросить статус.
  3. Статус «Ожидание отправки» при восстановленном соединении — регламентное задание подберёт записи автоматически; если не подбирает — перезапустить задание вручную.