Перейти к основному содержимому

Объединение дочерних резервных копий

примечание

Исполнять сценарий необходимо от имени пользователя postgres.

Описание сценария​

Для сокращения количества дублей резервных копий и экономии места на диске Platform V CopyWala позволяет выполнять объединение дочерних резервных копий. Для выполнения объединения все необходимые резервные копии выстраиваются в цепочку: основная резервная копия + дочерние резервные копии (дельта от основной).

Объединение дочерних резервных копий работает только для следующих хранилищ: Local FS, S2.

к сведению

Platform V CopyWala не поддерживает операцию объединения нескольких зашифрованных копий одной и той же базы данных, созданных с использованием Transparent Data Encryption (TDE), а также копий, размещенных в хранилищах DDBoost и S3.

Последовательность выполнения​

Настройка механизма для Local FS​

Чтобы выполнить объединение дочерних резервных копий, в конфигурационном файле copywala.yaml настройте описанные ниже параметры.

Параметры производительности​

  • write_parts_workers_no: Количество одновременно работающих процессов для записи частей резервных копий. Устанавливается равным половине числа ядер CPU, но минимум один поток.
  • read_parts_workers_no: Аналогично предыдущему параметру, количество параллельно читающих потоков также равно половине количества ядер CPU, но не менее одного потока.

Эти параметры позволяют использовать многопроцессорную обработку для ускорения чтения и записи данных во время операции восстановления.

Настройки безопасности и контроля качества​

  • verify_page_checksums: Включение проверки контрольных сумм страниц PostgreSQL. Отключение параметра ускоряет восстановление, но снижает безопасность, поскольку не гарантирует отсутствие повреждений данных на уровне страниц.
  • max_allowed_page_verification_failures: Максимальное число допустимых ошибок при проверке контрольных сумм страниц. Здесь установлено значение 0, значит любая ошибка приведет к остановке процесса восстановления.
  • verify_archive_checksums: Включение проверки контрольных сумм всего архива резервной копии. Это обеспечивает дополнительную защиту от повреждения данных на уровне целых архивов.

Режимы ввода-вывода​

  • read_direct_io, write_direct_io: Прямой ввод-вывод отключен. Данные будут проходить через буферизацию операционной системы, что повышает производительность на большинстве современных дисков, особенно SSD.

Описание конфигурации по умолчанию​

Конфигурация настроена на баланс между производительностью и надежностью:

  • Используется многопоточность для повышения скорости чтения-записи.
  • Проверяются контрольные суммы архивов целиком, но проверка контрольных сумм отдельных страниц выключена ради увеличения скорости восстановления.
  • Не используются режимы прямого ввода-вывода, что подходит для большинства современных хранилищ данных.
Конфигурация по умолчанию
merge_policy:
    write_parts_workers_no: max(runtime.NumCPU()/2, 1)
    read_parts_workers_no: max(runtime.NumCPU()/2, 1)
    verify_page_checksums: false
    max_allowed_page_verification_failures: 0
    verify_archive_checksums: true
    read_direct_io: false
    write_direct_io: false

Настройка механизма для S2​

Чтобы выполнить объединение дочерних резервных копий, в конфигурационном файле storage-service.yaml настройте описанные ниже параметры.

Рабочие директории и права доступа​

  • work_dir: /var/pbr/storage-service — рабочий каталог приложения, где оно будет хранить временные файлы, журналы и другие данные.
  • work_dir_mode: 0700 — права доступа к рабочему каталогу. В восьмеричной системе счисления значение 0700 означает, что доступ к этому каталогу имеет только владелец файла (полный доступ: чтение, запись и выполнение).

Параметры производительности​

  • write_parts_workers_no: Количество одновременно работающих процессов для записи частей резервных копий. Устанавливается равным половине числа ядер CPU, но минимум один поток.
  • read_parts_workers_no: Аналогично предыдущему параметру, количество параллельно читающих потоков также равно половине количества ядер CPU, но не менее одного потока.

Режимы ввода-вывода​

  • read_direct_io, write_direct_io: Прямой ввод-вывод отключен. Данные будут проходить через буферизацию операционной системы, что повышает производительность на большинстве современных дисков, особенно SSD.

Описание конфигурации по умолчанию​

Данная конфигурация предназначена для повышения производительности операций ввода-вывода большого объема данных через использование многопоточности и стандартных механизмов буферизации операционной системы. Она подходит для приложений, работающих с большими файлами и нуждающихся в высокой пропускной способности хранилища.

Конфигурация по умолчанию
app:
    work_dir: /var/pbr/storage-service
    work_dir_mode: 0700
merge_policy:
    write_parts_workers_no: max(runtime.NumCPU()/2, 1)
    read_parts_workers_no: max(runtime.NumCPU()/2, 1)
    write_direct_io: false
    read_direct_io: false

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

Запуск объединения дочерних резервных копий​

Выполните команду copywala merge <archive-uri> --delete-merged --dry-run.

Команда copywala merge предназначена для объединения нескольких архивов резервных копий в единый архив.

Рассмотрим подробнее каждый параметр команды:

  • <archive-uri> — путь до исходного архива резервной копии, который будет объединяться с цепочкой дочерних копий.
  • --delete-merged — после успешного завершения слияния удаляет исходные архивы, участвовавшие в процессе объединения.
  • --dry-run — запускает команду в режиме тестирования («сухого прогона»). В таком режиме никакие изменения не применяются, а лишь выводится информация о том, какие действия были бы выполнены командой, если бы она выполнялась без флага --dry-run. То есть фактически ничего не изменится, никаких файлы не сотрутся и не сольются.

Таким образом, команда проверит возможность выполнения процедуры объединения архивов и покажет результат, но сама операция слияния и удаления исходников выполнена не будет.

Результат​

После завершения объединения в таблице резервных копий соответствующие копии помечаются MERGED (в статусе инвентаризации), а если был указан флаг --delete-merged, копии помечаются DELETED (в статусе инвентаризации) и удаляются из хранилища.

В Retention policy, если резервные копии не были удалены, объединенные копии также участвуют в алгоритме. То есть если было выполнено объединение от последней цепочки, а потом указан max-full-backups=2 в retention policy, то останется новый объединенный архив и вся цепь объединения. Остальные файлы будут удалены.

Если одна из резервных копий была закреплена, но был указан флаг --delete-merged, закрепление игнорируется.