Резервное копирование и восстановление данных активности

В системе Proceset можно настроить резервное копирование данных активности, собранной агентом мониторинга. На каждой ноде резервная копия создается сразу для всех годовых баз активности.

Как работает резервное копирование

Резервное копирование запускается каждую ночь в 00:00 на каждой ноде кластера мониторинга и создает копию всех внутренних годовых баз данных активности и данных monitoring_raw_data. Копия хранится локально на той же ноде, без архивации.

Первая резервная копия после включения функции может создаваться десятки минут. На это время сервер отвечает агентам мониторинга так же, как в сервисном режиме — агенты сохраняют собранные данные локально и повторяют отправку позже, потери данных не происходит.

Настройка резервного копирования

Функция отключена по умолчанию. Основные параметры задаются в конфигурационном файле com.infomaximum.subsystem.monitoring.json:

Чтобы включить резервное копирование:

1. В файле com.infomaximum.subsystem.monitoring.json укажите activity_backup_enabled: true. При необходимости задайте activity_backup_path и activity_backup_watchdog_seconds.
2. Перезапустите контейнер ноды. Настройки применяются на той ноде, где вы их изменили, и автоматически передаются на остальные ноды кластера мониторинга — их отдельно перезапускать не нужно.

Если на конкретной ноде копию нужно сохранять по другому пути, переопределите его локально — необязательный параметр backup_path в файле com.infomaximum.subsystem.monitoringhandler.json этой ноды. После изменения перезапустите контейнер этой ноды.

Итоговый путь для копии определяется в таком порядке:

1. Локальный параметр backup_path ноды.
2. Параметр activity_backup_path из общих настроек.
3. Каталог backup в рабочем каталоге ноды — если ни один из параметров не задан.

Чтобы отключить резервное копирование, укажите activity_backup_enabled: false и перезапустите контейнер ноды. Ночная задача останавливается, но уже созданные копии на диске не удаляются.

Ручной запуск резервного копирования

Резервное копирование и восстановление выполняются через GraphQL и требуют привилегии Параметры мониторинга: операция чтения (R) — для запросов статусов, операция изменения (W) — для запуска резервного копирования и восстановления.

Чтобы запустить резервное копирование вручную, выполните запрос:

mutation {
  monitoring_backup {
    run(shard_ids: [1, 2]) {
      shard_id
      state
      guid
    }
  }
}

Если параметр shard_ids не указан, копирование запускается на всех нодах кластера мониторинга.

Вызов неблокирующий: нода запускает копирование в фоне и сразу возвращает статус. Повторный вызов на ноде, где копирование уже идет, возвращает тот же guid — повторно копирование не запускается.

Чтобы проверить статус копирования по всем нодам, выполните запрос:

query {
  monitoring_backup {
    statuses {
      shard_id
      state
      guid
      started
      finished
      total_size_bytes
      error_message
    }
  }
}

Восстановление данных

Восстановление — операция, которую администратор запускает вручную и контролирует до конца.

1. Запустите восстановление на нужных нодах:

   mutation {
     monitoring_backup {
       restore(shard_ids: [1, 2]) {
         shard_id
         state
         error_message
       }
     }
   }
   

   Параметр shard_ids обязателен — восстановление выполняется только для указанных нод. Вызов неблокирующий.
2. Дождитесь статуса RESTORED для каждой восстанавливаемой ноды — проверьте его запросом состояния. Пока восстановление не завершено, статус — RESTORING. Статус RESTORED сохраняется даже после перезапуска ноды. После восстановления нода сразу принимает и обрабатывает новую активность. Если восстановление завершилось ошибкой, повторный запуск того же запроса restore на этой ноде доводит операцию до конца — начинать заново не нужно.
3. Перед следующим шагом рекомендуется сделать собственную копию затронутых таблиц ClickHouse (monitoring_activity, monitoring_agent_inspector_log) — например, средствами ClickHouse скопировать или переименовать таблицы. Это решение и ответственность администратора.
4. Получите команды очистки ClickHouse:

   query {
     monitoring_backup {
       clickhouse_cleanup_queries(shard_ids: [1, 2]) {
         shard_id
         queries
       }
     }
   }
   

   Для каждой восстановленной ноды запрос возвращает готовые команды удаления строк, которые в ClickHouse оказались «из будущего» относительно точки восстановления. Запрос только формирует команды — система их не выполняет.
5. Выполните полученные команды в ClickHouse самостоятельно. До этого шага строки «из будущего» видны в отчетах, а новая активность в базе Proceset накапливается без синхронизации с ClickHouse.
6. Проверьте, что синхронизация с ClickHouse догнала базу Proceset:

   query {
     monitoring_diagnostics {
       comparison_max_row_number {
         node_id
         max_rocks_id
         max_ch_id
       }
     }
   }
   

   Дождитесь, когда max_rocks_id и max_ch_id совпадут по восстановленным нодам. После выполнения команд из предыдущего шага синхронизация сама доливает недостающие данные, без дублей и пропусков.

Возможные ошибки