Переменные PITR-резервирования
В этом разделе приведены переменные окружения сценария PITR-резервирования playbooks/backup_pitr.yml.
Сценарий выполняет резервное копирование кластера Tarantool 3.x на основе утилиты tt backup
(полное и инкрементальное копирование с возможностью восстановления на момент времени).
Все переменные имеют префикс tarantool_pitr_ и задаются глобально, например через --extra-vars
или в файле инвентаря. Сценарий также использует переменные роли tt (см. раздел
LINK_NOT_DEFINED(/ru/variable-reference/tt-variables)): tt_connect_username,
tt_connect_password, а также переменные подключения к централизованному
хранилищу конфигурации tt_config_storage_*.
Переменная | Описание |
|---|---|
| Значение, передаваемое в |
| Хост сбора резервных копий (для управляющего узла Ansible — |
Переменные tarantool_pitr_cluster_name и tarantool_pitr_environment необязательны. Они
выбирают поддерево хранилища <root>/<prefix>/<cluster-name>/<environment>/ и должны задаваться
одинаково во всех командах сценария (plan, upload, verify, gc, last). Если обе
переменные пусты, резервные копии пишутся непосредственно в корень хранилища (или в его
prefix). Если в одном хранилище лежит несколько кластеров, переменные нужно задать: команды,
вызванные без них, увидят пустое хранилище, а не ошибку.
Переменная | Описание |
|---|---|
| Имя кластера — первый компонент поддерева хранилища
( |
| Окружение (например |
Переменная | Описание |
|---|---|
| Корневой каталог локальной файловой системы для хранилища |
Если tarantool_pitr_storage пуста, а tarantool_pitr_s3_endpoint задана, сценарий собирает
файл конфигурации хранилища type: s3 (в рабочем каталоге tarantool_pitr_backup_dir для
резервирования, tarantool_pitr_restore_dir для восстановления) из переменных ниже и
передаёт его в tt backup/tt restore флагом --backup-storage (@<рабочий-каталог>/s3-storage.yaml).
Переменные общие для резервирования и восстановления; применяются только когда tarantool_pitr_storage пуста.
Переменная | Описание |
|---|---|
| URL конечной точки S3 (например |
| Имя бакета S3. Тип: |
| Префикс (подпуть) внутри бакета, изолирующий резервные копии кластера/окружения.
Тип: |
| Ключ доступа S3 (access key id). Тип: |
| Секретный ключ S3 (secret access key). Тип: |
Переменная | Описание |
|---|---|
| Директория, содержащая бинарный файл |
Переменная | Описание |
|---|---|
| Тип резервной копии, передаваемый в |
| Для полной резервной копии выполнять |
| Явный идентификатор резервной копии. Если пусто, сценарий генерирует его сам как
лексикографически сортируемый UTC-таймстемп |
| Время жизни незавершённой резервной копии, передаваемое в |
Сценарий 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_backupprivileges:- permissions: [execute]lua_call: ['box.backup.recovery_point.create']roles: [roles.recovery-point-manager]roles_cfg:roles.recovery-point-manager:backend: net-replicasetcreate:by: {interval: 300}timeout: 60backends_cfg:net-replicaset:login: backup_usermanagers: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 равны нулю.
Переменные ниже управляют этим поведением.
Переменная | Описание |
|---|---|
| Количество последних полных резервных копий, которые нужно сохранить (флаг |
| Срок хранения резервных копий в днях (флаг |
| Выполнять очистку в режиме «dry-run» (без фактического удаления, флаг |