Skip to content

MirvMon v0.6.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 02 Sep 04:22
· 17 commits to master since this release
v0.6.0
be07e8f

MirvMon v0.6.0

Backup & Disaster Recovery

  • Добавлен полный password-protected backup MirvMon из web UI: PostgreSQL/TimescaleDB, история метрик и сайтов, настройки, инциденты, audit log и остальные постоянные данные.
  • Backup имеет собственный версионированный формат, manifest, checksums и потоковое шифрование; APP_KEY в архив не записывается.
  • Backup создаётся асинхронно отдельным dr-worker из согласованного PostgreSQL snapshot, поэтому длительный pg_dump не держит HTTP-запрос открытым.
  • Restore начинается с read-only preflight: пароль, целостность архива, manifest, dump, миграции и версии PostgreSQL/TimescaleDB проверяются до изменения рабочей БД.
  • Восстановление выполняется в отдельную staging database. Только после restore, forward migrations, re-encryption секретов, normalization и integrity checks выполняется cutover.
  • Cutover защищён maintenance lock и crash-recovery journal: ingestion и фоновые workers получают контролируемую паузу, а прерванный процесс может безопасно завершить или откатить переключение БД.
  • Restore поддерживает новый APP_KEY: application secrets расшифровываются из backup и заново шифруются текущим ключом установки.
  • Permanent credentials и server IDs уже установленных агентов сохраняются. Существующий агент с прежним token продолжает отправлять метрики после восстановления.
  • Если после DR с другим APP_KEY требуется новый installer для такого сервера, MirvMon не выдаёт заведомо нерабочий installer: сначала требуется явная регенерация token, которая инвалидирует старый агент.
  • После неудачного restore UI сохраняет исходные версии MirvMon, PostgreSQL и TimescaleDB из backup для восстановления на matching stack.

Проверенный disaster-recovery сценарий

CI воспроизводит полный сценарий A(APP_KEY=A) -> encrypted backup -> fresh B(APP_KEY=B) -> restore -> unchanged real Go agent -> metrics accepted на production amd64 image и настоящем TimescaleDB.

Acceptance также проверяет:

  • неверный пароль и повреждённый archive не изменяют B;
  • restore backup с предыдущей поддерживаемой схемой применяет обычные forward migrations;
  • application secrets после restore читаются новым APP_KEY;
  • временный administrator/session установки B исчезает после cutover;
  • maintenance 503 заставляет настоящий агент сохранить метрики в durable queue и отправить их после окончания maintenance.

Обновление

  • Для Docker/Portainer используйте ghcr.io/mirivlad/mirvmon:0.6.0 и выполните обычный re-pull/redeploy stack.
  • Новых миграций схемы БД в v0.6.0 нет.
  • Agent protocol не изменён; переустанавливать агенты для обновления MirvMon не требуется.
  • Для backup upload доступны BACKUP_MAX_UPLOAD_BYTES (по умолчанию 8 GiB) и DR_WORKER_INTERVAL (по умолчанию 2 секунды). Значения уже есть в актуальных .env.example.

Важно перед Disaster Recovery

Чтобы уже установленные агенты продолжили работу без изменения конфигурации, новая установка B должна быть доступна по тому же публичному MirvMon endpoint (тот же URL/домен/IP), который записан у агентов. Автоматическая миграция endpoint/discovery в v0.6.0 не реализуется.

Assets 2
Loading