pg_rewind
pg_rewind — синхронизировать каталог данных Postgres Pro с другим каталогом, ответвлённым от него
Синтаксис
pg_rewind
[параметр
...] { -D
| --target-pgdata
}каталог
{ --source-pgdata=
| каталог
--source-server=
} строка_подключения
Описание
Утилита pg_rewind представляет собой средство синхронизации кластера Postgres Pro с другой копией того же кластера после расхождения линий времени этих кластеров. Обычный сценарий её использования — вернуть в работу старый ведущий сервер после переключения на ведомый, в качестве ведомого для сервера, ставшего ведущим.
После успешной синхронизации состояние целевого каталога данных будет аналогично состоянию базовой копии исходного каталога. В отличие от создания новой копии или использования такого средства, как rsync, синхронизация pg_rewind не требует сравнения или копирования неизменённых блоков в кластере. Из существующих файлов отношений копируются только изменённые блоки, а все остальные файлы, включая новые файлы отношений, файлы конфигурации и сегменты WAL переносятся полностью. Благодаря этому такая синхронизация гораздо быстрее других методов, когда база данных большая, а различия между кластерами ограничиваются лишь небольшим количеством блоков.
Утилита pg_rewind изучает истории линий времени исходного и целевого кластеров с целью найти точку, в которой они разошлись, и ожидает найти журналы WAL в каталоге pg_wal
целевого кластера вплоть до точки расхождения. Точка расхождения может быть найдена на целевой или исходной линии времени либо в их общем предке. В типичном сценарии отработки отказа, когда целевой кластер отключается вскоре после расхождения, это не проблема, но если целевой кластер проработал долгое время после расхождения, старые файлы WAL могут быть уже удалены. В этом случае их можно вручную скопировать из архива WAL в каталог pg_wal
или запустить pg_rewind с ключом -c
, чтобы они были автоматически получены из архива WAL. Варианты использования pg_rewind не ограничиваются отработкой отказа; например, резервный сервер может быть повышен, выполнить несколько пишущих транзакций, а затем, после восстановления синхронизации, вновь стать резервным.
После выполнения pg_rewind для приведения каталога данных в согласованное состояние должна завершиться процедура воспроизведения WAL. Когда целевой сервер запускается, он переходит в режим восстановления из архива и воспроизводит все изменения из WAL с исходного сервера, накопившиеся после последней контрольной точки с момента расхождения. Если какие-то сегменты WAL оказались недоступны на исходном сервере, когда выполнялась pg_rewind, и поэтому не могли быть скопированы в ходе работы pg_rewind, их необходимо предоставить, когда сервер будет запускаться. Это можно сделать, создав файл recovery.signal
в целевом каталоге данных и определив подходящую команду restore_command в postgresql.conf
.
Утилита pg_rewind требует, чтобы на целевом сервере был либо включён режим wal_log_hints в postgresql.conf
, либо включены контрольные суммы, когда кластер был инициализирован командой initdb. По умолчанию режим wal_log_hints
отключён, а контрольные суммы включены. Также должен быть включён режим full_page_writes (по умолчанию он включён).
Предупреждение: ошибки при синхронизации
Если во время работы pg_rewind происходит ошибка, вероятнее всего, целевой каталог данных будет в состоянии, не подходящем для восстановления. В этом случае рекомендуется сделать новую резервную копию.
Так как pg_rewind копирует файлы конфигурации с исходного сервера без изменений, в полученную конфигурацию может потребоваться внести коррективы до перезапуска целевого сервера, особенно если целевой сервер становится ведомым для исходного. Если вы перезапустите сервер после окончания операции синхронизации, но не настроите команду восстановления WAL, целевой сервер может снова разойтись с ведущим.
Программа pg_rewind немедленно прекращает работу, если обнаруживает файлы, непосредственная запись в которые невозможна. Это может иметь место, например, когда на исходном и целевом серверах совпадают пути файлов сертификатов и ключей SSL, доступных только для чтения. Если такие файлы существуют на целевом сервере, их рекомендуется удалить до запуска pg_rewind. После выполнения синхронизации некоторые из таких файлов могут быть скопированы из источника и тогда может потребоваться удалить скопированные данные и восстановить ссылки/файлы, существовавшие до синхронизации.
Параметры
pg_rewind принимает следующие аргументы командной строки:
-D
каталог
--target-pgdata=
каталог
Этот параметр задаёт целевой каталог данных, который будет синхронизирован с источником. Целевой сервер должен быть отключён штатным образом до запуска pg_rewind
--source-pgdata=
каталог
Задаёт путь в файловой системе к каталогу данных исходного сервера, с которым будет синхронизироваться целевой. Для применения этого ключа исходный сервер должен быть остановлен штатным образом.
--source-server=
строка_подключения
Задаёт строку подключения libpq для подключения к исходному серверу Postgres Pro, с которым будет синхронизирован целевой. Подключение должно устанавливаться как обычное (не реплицирующее) от имени роли, имеющей необходимые права для выполнения функций pg_rewind на исходном сервере (подробнее об этом говорится в Замечаниях), или от имени суперпользователя. Для применения этого параметра исходный сервер должен быть запущен и принимать подключения.
-R
--write-recovery-conf
Создать
standby.signal
и добавить параметры подключения вpostgresql.auto.conf
в выходном каталоге. Этот ключ требует указания--source-server
.-n
--dry-run
Делать всё, кроме внесения изменений в целевой каталог.
-N
--no-sync
По умолчанию
pg_rewind
ждёт, пока все файлы не будут надёжно записаны на диск. С данным параметромpg_rewind
завершается быстрее, без ожидания, но в случае неожиданного сбоя операционной системы целевой каталог данных может оказаться испорченным. Этот параметр может быть полезен при тестировании; в производственной среде применять его не следует.-P
--progress
Включает вывод сообщений о прогрессе. При этом в процессе копирования данных из исходного кластера будет выдаваться приблизительный процент выполнения.
-c
--restore-target-wal
Использовать команду
restore_command
, определённую в конфигурации целевого кластера, для получения файлов WAL из архива в случае отсутствия их в каталогеpg_wal
.--config-file=
имя_файла
Использовать указанный основной файл конфигурации сервера для целевого кластера. Это влияет на поведение программы postgres, которую вызывает pg_rewind в процессе операции синхронизации в данном кластере (для получения
restore_command
при вызове с параметром-c/--restore-target-wal
и для выполнения процедуры восстановления после сбоя).--debug
Выводить подробные отладочные сообщения, полезные в основном для разработчиков, отлаживающих pg_rewind.
--no-ensure-shutdown
Для pg_rewind необходимо, чтобы целевой сервер был остановлен штатным образом до синхронизации. По умолчанию, если целевой сервер не был остановлен штатно, pg_rewind запускает его в однопользовательском режиме, чтобы он выполнил процедуру восстановления после сбоя, а затем останавливает его. Когда передаётся данный ключ, pg_rewind не делает этого, а завершается с ошибкой немедленно, если сервер не был остановлен корректно. Ожидается, что в этом случае пользователи сами исправят сложившуюся ситуацию.
--sync-method=
метод
Со значением
fsync
(по умолчанию)pg_rewind
будет рекурсивно открывать и синхронизировать все файлы в каталоге данных. Поиск файлов будет осуществляться по символическим ссылкам для каталога WAL и каждого настроенного табличного пространства.В Linux возможен вариант
syncfs
, когда от ОС требуется синхронизировать целиком каждую из файловых систем, содержащих каталог данных, файлы WAL и табличные пространства. Более подробно особенности использованияsyncfs
описаны в recovery_init_sync_method.В режиме
--no-sync
этот параметр не оказывает никакого влияния.--biha
Перевести узел biha в состояние
CSTATE_FORMING
, чтобы последующий статус узла мог устанавливаться автоматически в зависимости от текущего состояния кластера. Этот параметр используется при восстановлении узла встроенного отказоустойчивого кластера в состоянииNODE_ERROR
. За подробностями обратитесь к Подразделу F.7.3.5.-V
--version
Показать версию, а затем завершиться.
-?
--help
Показать справку, а затем завершиться.
Переменные окружения
Когда используется --source-server
, pg_rewind также использует переменные среды, поддерживаемые libpq (см. Раздел 34.15).
Переменная окружения PG_COLOR
выбирает вариант использования цвета в диагностических сообщениях. Возможные значения: always
(всегда), auto
(автоматически) и never
(никогда).
Примечания
Когда исходным кластером для pg_rewind является работающий сервер, вместо суперпользователя может применяться роль, имеющая в этом кластере достаточные права для выполнения функций, которые использует pg_rewind. Такую роль (rewind_user
) можно создать так:
CREATE USER rewind_user LOGIN; GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind_user; GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user; GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user; GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;
Как это работает
Основная идея состоит в том, чтобы перенести все изменения на уровне файловой системы из исходного кластера в целевой:
Просканировать журнал WAL в целевом кластере, начиная с последней контрольной точки перед моментом, когда история линии времени исходного кластера разошлась с целевым кластером. Для каждой записи WAL отметить, какие блоки данных были затронуты. В результате будет получен список всех блоков данных, которые были изменены в целевом кластере после отделения исходного. Если какие-либо файлы WAL уже удалены, можно запустить pg_rewind с ключом
-c
, чтобы целевой сервер обратился за ними к архиву WAL.Скопировать все эти изменённые блоки из исходного кластера в целевой либо на уровне файловой системы (
--source-pgdata
), либо на уровне SQL (--source-server
). После этого файлы отношений оказываются в том же состоянии, в котором они были в момент последней контрольной точки, предшествующей моменту расхождения линий времени исходного и целевого кластера, с добавлением текущего состояния, полученного из исходного кластера, тех блоков, которые были изменены в целевом кластере после расхождения.Скопировать все остальные файлы, включая новые файлы отношений, сегменты WAL,
pg_xact
и файлы конфигурации, из исходного кластера в целевой. Как и при базовом копировании, содержимое каталоговpg_dynshmem/
,pg_notify/
,pg_replslot/
,pg_serial/
,pg_snapshots/
,pg_stat_tmp/
иpg_subtrans/
исключается из данных, копируемых из исходного кластера. Кроме того, исключаются файлы или каталоги с именами, начинающимися сpgsql_tmp
, а также файлыbackup_label
,tablespace_map
,pg_internal.init
,postmaster.opts
,postmaster.pid
и.DS_Store
.Создать файл
backup_label
для перехода к воспроизведению WAL в контрольной точке, произведённой при переключении, и установить в файлеpg_control
минимальный LSN согласованного состояния, определённый в результате вызоваpg_current_wal_insert_lsn()
при синхронизации с работающим источником или равный LSN последней контрольной точке при синхронизации с остановленным.При запуске целевого сервера Postgres Pro воспроизводятся все требуемые записи WAL, в результате чего каталог данных приводится в согласованное состояние.