Переменные PITR-резервирования

В этом разделе приведены переменные окружения сценария PITR-резервирования playbooks/backup_pitr.yml. Сценарий выполняет резервное копирование кластера Tarantool 3.x на основе утилиты tt backup (полное и инкрементальное копирование с возможностью восстановления на момент времени).

Все переменные имеют префикс tarantool_pitr_ и задаются глобально, например через --extra-vars или в файле инвентаря. Сценарий также использует переменные роли tt (см. раздел Переменные tt CLI): tt_connect_username, tt_connect_password, а также переменные подключения к централизованному хранилищу конфигурации tt_config_storage_*.

Переменные tarantool_pitr_cluster_name и tarantool_pitr_environment необязательны. Они выбирают поддерево хранилища <root>/<prefix>/<cluster-name>/<environment>/ и должны задаваться одинаково во всех командах сценария (plan, upload, verify, gc, last). Если обе переменные пусты, резервные копии пишутся непосредственно в корень хранилища (или в его prefix). Если в одном хранилище лежит несколько кластеров, переменные нужно задать: команды, вызванные без них, увидят пустое хранилище, а не ошибку.

Сценарий backup_pitr.yml не создаёт точек восстановления. tt backup сам их не пишет, а tt restore plan выбирает момент восстановления исключительно по точкам восстановления. Поэтому в конфигурации кластера должна быть включена встроенная роль roles.recovery-point-manager: она периодически создаёт точки в каждом наборе реплик. Для подключения к наборам реплик роли нужен отдельный пользователь (например backup_user) с правом execute на box.backup.recovery_point.create.

Пример фрагмента конфигурации кластера:

 
credentials:  users:    backup_user:      password: secret_backup      privileges:        - permissions: [execute]          lua_call: ['box.backup.recovery_point.create']roles: [roles.recovery-point-manager]roles_cfg:  roles.recovery-point-manager:    backend: net-replicaset    create:      by: {interval: 300}      timeout: 60    backends_cfg:      net-replicaset:        login: backup_user    managers:      rs_001:        backend_cfg:          target: replicaset-001

По умолчанию артефакты проходят через управляющий узел Ansible: tt backup start пишет архив (.tar.zst) и манифест фрагмента (.json) каждого мастера в его рабочий каталог tarantool_pitr_backup_dir, затем сценарий забирает их на управляющий узел (модуль fetch), при выделенном хосте сбора — дополнительно копирует на него, и передаёт в хранилище командой tt backup upload. Схема одинакова для файлового хранилища и S3: tt backup upload читает локальные файлы, поэтому до загрузки архивы целиком лежат на управляющем узле (а при выделенном хосте сбора — ещё и на нём).

Такой маршрут намеренно идёт через управляющий узел: Ansible и без того соединяется с мастерами и хостом сбора, поэтому мастерам и хосту сбора не требуется прямая сетевая связность друг с другом. Это работает везде, где работает сам Ansible; однако, это требует достаточного места на диске:

• на управляющем узле Ansible должно быть достаточно места под архив одной резервной копии (сумма архивов всех мастеров); локальная копия после загрузки автоматически не удаляется;
• при выделенном хосте сбора (tarantool_pitr_backup_host ≠ localhost) тот же объём потребуется и на нём.

Чтобы исключить управляющий узел из цепочки и не пересылать данные между мастерами и хостом сбора, используйте общую файловую систему: tarantool_pitr_backup_shared_fs: true. Тогда tt backup start пишет архивы в каталог, смонтированный одновременно на мастерах и хосте сбора (общий том или NFS), а сценарий читает их напрямую и не выполняет fetch/copy. Мастера и хост сбора обращаются к общему тому, а не друг к другу напрямую.

tt backup gc не удаляет ничего, пока --keep-full или --keep-days равны нулю. Переменные ниже управляют этим поведением.