Postgres Pro Backup Enterprise
3.43.33.2
RUENRU EN
3.9. Клонирование и синхронизация экземпляра Postgres Pro
Пред. НаверхГлава 3. Сценарии использованияНачало След.

3.9. Клонирование и синхронизация экземпляра Postgres Pro #

3.9.1. Особенности и ограничения использования catchup
3.9.2. Использование команды catchup
3.9.3. Устранение неполадок

В pg_probackup3 реализована команда catchup, которая позволяет создать копию экземпляра сервера Postgres Pro напрямую, не используя каталог резервных копий. Эта команда может быть полезна:

  • Для добавления нового ведомого сервера.

    Если каталог данных целевого экземпляра пуст, команда catchup работает аналогично команде backup в режиме PRO, но может выполняться быстрее при запуске в параллельном режиме.

    Примечание

    В настоящее время операции catchup поддерживаются только в режимах PRO и BASE и не требуют прямого доступа к PGDATA.

  • Для синхронизации отставшего ведомого сервера с ведущим.

    При активной записи на ведущем сервере реплики могут не успевать воспроизводить WAL с достаточной скоростью и в результате отставать. Обычно в этом случае создаётся новая реплика, а для этого нужно передать и сохранить на диске большой объём данных. Команда catchup напрямую переносит различия с ведущего сервера, что позволяет намного быстрее обновить данные на уже существующей реплике.

3.9.1. Особенности и ограничения использования catchup #

Важно учитывать следующие особенности и ограничения операций catchup:

  • Для операций catchup не требуется каталог резервных копий.

  • Одновременно с catchup нельзя выполнять команды DDL CREATE TABLESPACE/DROP TABLESPACE.

  • При синхронизации catchup берёт файлы конфигурации, такие как postgresql.conf, postgresql.auto.conf или pg_hba.conf, с исходного сервера и заменяет ими соответствующие файлы на целевом сервере. Чтобы оставить файлы конфигурации без изменений, используйте параметр --exclude-path.

  • Команда catchup всегда работает в режиме доставки WAL STREAM, передавая все необходимые WAL-файлы с сервера по протоколу репликации.

  • Команда catchup не поддерживает:

    • режим источника данных DIRECT;

    • внешние каталоги;

    • удалённый режим.

  • Для режима PRO требуется, чтобы на исходном сервере был установлен и настроен модуль pgpro_bindump.

  • Режим источника данных BASE не поддерживает режим PTRACK.

  • Для выполнения команды catchup в режиме источника данных BASE пользователь должен обладать правами роли pg_read_all_settings:

    GRANT pg_read_all_settings TO backup;

  • Используйте режимы DELTA и PTRACK только при соблюдении следующих условий:

    • Целевой сервер был создан с помощью команды pg_probackup3 catchup -b FULL или pg_probackup3 restore.

    • Целевой сервер никогда не запускался в качестве ведущего (только как ведомый).

    • На целевом сервере не выполнялись команды pg_rewind, pg_resetwal или pg_upgrade.

    • Файл pg_control целевого сервера не изменялся вручную.

    За подробной информацией о возможных проблемах синхронизации и способах их устранения обратитесь к разделу Устранение неполадок.

3.9.2. Использование команды catchup #

Чтобы подготовить экземпляр Postgres Pro к клонированию/синхронизации, настройте исходный сервер следующим образом:

Перед клонированием/синхронизацией экземпляра Postgres Pro убедитесь, что исходный сервер запущен и принимает подключения. Чтобы клонировать/синхронизировать экземпляр Postgres Pro, в системе с целевым сервером выполните команду catchup:

pg_probackup3 catchup -b режим_синхронизации --destination-pgdata=путь [-s | --backup-source=источник_данных] [параметры_подключения]

Команда catchup может выполняться в одном из следующих режимов синхронизации, задаваемых параметром -b/--backup-mode:

  • FULL: создаётся полная копия экземпляра Postgres Pro. Для этого целевой каталог данных экземпляра должен быть пустым. В режиме FULL все файлы данных копируются с исходного экземпляра независимо от их состояния на целевом сервере. Этот режим следует использовать в следующих случаях:

    • При создании нового ведомого сервера.

    • После операций, изменяющих значение LSN в файле pg_control.

    • После запуска целевого сервера в качестве ведущего.

  • DELTA: считываются все файлы данных в каталоге данных и создаётся инкрементальная копия для страниц, изменённых с момента остановки целевого сервера. pg_probackup3 считывает позицию целевого экземпляра из файла pg_control и копирует с исходного экземпляра все изменённые блоки новее этой позиции по LSN.

  • PTRACK: изменения в страницах отслеживаются на лету, считываются и копируются только страницы, изменённые с точки расхождения исходного и целевого экземпляров. Режим PTRACK не требует сканирования всех файлов данных; вместо этого он использует информацию об изменённых блоках из битовой карты PTRACK.

Можно явно указать режим источника данных для синхронизации с помощью параметра -s/--backup-source. Поскольку операции catchup пока не поддерживают режим DIRECT, параметр -s может принимать либо значение pro (режим PRO), либо base (режим BASE).

Если источник_данных не указан, pg_probackup3 по умолчанию использует режим PRO.

Важно

Если используемый по умолчанию режим PRO недоступен (модуль pgpro_bindump не настроен), утилита переходит в режим BASE в качестве резервного варианта. В этом случае операция catchup в режиме FULL продолжит выполняться штатно в режиме BASE, тогда как операции в режимах DELTA и PTRACK завершатся ошибкой.

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

Если в исходном кластере баз данных есть табличные пространства, которые должны располагаться в других каталогах в целевой системе, задайте также параметр -T/--tablespace-mapping:

pg_probackup3 catchup -b режим_синхронизации --destination-pgdata=путь -T старый_каталог=новый_каталог

Примечание

Обратите внимание на синтаксис переопределения путей для нескольких табличных пространств: вместо нескольких флагов -T используйте один флаг с парами переопределения, разделёнными двоеточием. Например: 

-T старый_каталог1=новый_каталог1:старый_каталог2=новый_каталог2

Чтобы операция catchup выполнялась в несколько параллельных потоков, задайте число потоков с помощью параметра -j/--threads или --num-write-threads и --num-validate-threads:

pg_probackup3 catchup -b режим_синхронизации --destination-pgdata=путь --threads=число_потоков

3.9.3. Устранение неполадок #

Важно

Использование режимов DELTA или PTRACK после выполнения команд pg_rewind, pg_resetwal, pg_upgrade или запуска целевого сервера в роли ведущего может привести к проблемам синхронизации и некорректным результатам. В таких случаях рекомендуется использовать режим FULL.

Эти операции изменяют LSN в файле pg_control целевого сервера. pg_probackup3 автоматически проверяет, что LSN исходного сервера не меньше LSN целевого сервера, и если эта проверка не проходит, синхронизация прерывается ошибкой «Current START LSN source_lsn is lower than expected START LSN dest_lsn. It may indicate that we are trying to backup PostgreSQL instance from the past.» (Текущий START LSN lsn_исходного_сервера меньше ожидаемого START LSN lsn_целевого_сервера. Возможно, выполняется попытка создать резервную копию экземпляра PostgreSQL из прошлого.).

Однако утилита не может обнаружить нарушения, если исходный сервер увеличивает LSN после изменения файла pg_control. Например, после аварийного переключения, когда старый ведущий сервер становится ведомым с помощью pg_rewind, исходный сервер может продолжать обрабатывать транзакции до начала операции catchup. Если LSN исходного сервера превышает изменённый LSN целевого сервера, проверка проходит, и pg_probackup3 выполняет синхронизацию в режиме DELTA или PTRACK, но копирует только блоки с LSN, большим или равным новому (изменённому) значению из pg_control, что может привести к потере или расхождению данных.

Пример неправильной последовательности команд:

pg_rewind --target-pgdata=/path/to/replica --source-server='host=master'
pg_probackup3 catchup -b DELTA ...

Правильная последовательность команд:

pg_rewind --target-pgdata=/path/to/replica --source-server='host=master'
pg_probackup3 catchup -b FULL ...

Аналогично, после запуска целевого сервера в качестве ведущего следует использовать только режим FULL.

При попытке выполнить синхронизацию в режиме DELTA или PTRACK утилита проверяет отсутствие файла backup_label в каталоге данных целевого сервера. Если этот файл существует, синхронизация прерывается с ошибкой «Destination directory contains backup_label file» (Целевой каталог содержит файл backup_label).

Наличие файла backup_label означает, что целевой сервер находится в несогласованном состоянии после неполного восстановления из резервной копии. В этом случае содержимое файла pg_control не соответствует фактическому состоянию данных на диске.

Предупреждение

Ни при каких обстоятельствах не удаляйте вручную файл backup_label для обхода данной проверки. Это приведёт к использованию неверного LSN из файла pg_control и гарантированной потере данных.

Для решения проблемы выполните следующие действия:

  1. Запустите целевой сервер в качестве ведомого (WAL-файлы должны быть доступны через потоковую репликацию с ведущего сервера или из архива).

  2. Дождитесь завершения процесса запуска (startup), который применит все WAL-файлы, завершит синхронизацию данных и приведёт содержимое pg_control в соответствие с фактическим состоянием данных.

  3. Остановите сервер.

Теперь можно безопасно выполнять catchup в режиме DELTA или PTRACK.

Пред. Наверх След.
3.8. Настройка политики хранения Начало 3.10. Другие примеры
FAQ