qhb_rewind

qhb_rewind — синхронизировать каталог данных QHB с другим каталогом данных, который был ответвлен от него

Синтаксис

qhb_rewind [параметр...] { -D | --target-pgdata } каталог { --source-pgdata=каталог | --source-server=строка_подключения }

Утилита qhb_rewind — это инструмент для синхронизации кластера QHB с другой копией того же кластера после того, как временные линии этих кластеров разошлись. Типичным сценарием является возвращение старого основного сервера после отказа к работе в качестве резервного, следующего за новым основным сервером

После успешной синхронизации состояние целевого каталога данных аналогично состоянию базовой резервной копии исходного каталога данных. В отличие от создания новой резервной копии или использования инструмента вроде rsync, qhb_rewind не требует сравнения или копирования неизмененных блоков отношений в кластер. Копируются только измененные блоки из существующих файлов отношений; все остальные файлы, включая новые файлы отношений, файлы конфигурации и сегменты WAL, копируются полностью. Поэтому операция синхронизации намного быстрее других подходов, когда база данных большая, а кластеры отличаются только небольшой частью блоков.

qhb_rewind изучает истории временной шкалы исходного и целевого кластеров, чтобы определить точку их расхождения, и ожидает найти WAL в каталоге pg_wal целевого кластера вплоть до точки расхождения. Точку расхождения можно найти либо на целевой или на исходной временной линии, либо у их общего предка. В типичном сценарии отработки отказа, где целевой кластер был отключен вскоре после расхождения, это не проблема, но если целевой кластер после расхождения работал долго, старые файлы WAL могут отсутствовать. В этом случае их можно вручную скопировать из архива WAL в каталог pg_wal или запустить qhb_rewind с параметром -c, чтобы автоматически извлечь их из архива WAL. Использование qhb_rewind не ограничивается переключением при отказе. Например, резервный сервер может быть повышен, выполнить несколько записывающих транзакций, а затем, после синхронизации, снова стать резервным.

После выполнения qhb_rewind нужно завершить воспроизведение WAL, чтобы каталог данных пришел в согласованное состояние. Когда целевой сервер снова запускается, он переходит в режим восстановления из архива и воспроизводит все WAL, сгенерированные на исходном сервере, начиная с последней контрольной точки перед точкой расхождения. Если при запуске qhb_rewind какие-то сегменты WAL больше не были доступны на исходном сервере и, следовательно, не могли быть скопированы, то их необходимо предоставить при запуске целевого сервера. Это можно сделать, создав файл recovery.signal в целевом каталоге данных и задав подходящую команду в параметре restore_command в qhb.conf.

Утилита qhb_rewind требует, чтобы на целевом сервере либо был включен параметр wal_log_hints в qhb.conf, либо при инициализации кластера с помощью qhb_bootstrap (или initdb) были включены контрольные суммы данных. Ни один из этих режимов в настоящее время не включен по умолчанию. Также должен быть включен параметр full_page_writes, но он и так включен по умолчанию.

ПРЕДУПРЕЖДЕНИЕ!
Если во время обработки происходит сбой qhb_rewind, целевой каталог данных, скорее всего, будет в состоянии, не подходящем для восстановления. В таком случае рекомендуется сделать новую резервную копию.

Поскольку qhb_rewind полностью копирует файлы конфигурации из источника, перед запуском целевого сервера может понадобиться скорректировать конфигурацию, использующуюся при восстановлении, особенно если целевой сервер становится резервным для исходного. Если перезапустить сервер по окончании синхронизации, но без настройки восстановления, целевой сервер может снова разойтись с основным.

qhb_rewind сразу прекратит работу, если найдет файлы, в которые не может записывать напрямую. Это может произойти, например, когда исходный и целевой серверы используют одинаковые пути файлов для ключей и сертификатов SSL, доступных только для чтения. Если такие файлы существуют на целевом сервере, рекомендуется удалить их перед запуском qhb_rewind. После синхронизации некоторые из этих файлов могут оказаться скопированы из источника, и в этом случае может понадобиться удалить скопированные данные и восстановить набор ссылок, использовавшихся до синхронизации.

Параметры

Утилита qhb_rewind принимает следующие аргументы командной строки:

-D каталог
--target-pgdata=каталог
Этот параметр задает целевой каталог данных, который синхронизируется с источником. Целевой сервер должен быть штатно отключен перед запуском qhb_rewind.

--source-pgdata=каталог
Задает путь файловой системы к каталогу данных исходного сервера, с которым нужно синхронизировать целевой. Этот параметр требует, чтобы исходный сервер был штатно отключен.

--source-server=строка_подключения
Задает строку подключения libpq для подключения к исходному серверу QHB, с которым нужно синхронизировать целевой. Это подключение должно быть обычным (без репликации) от имени роли, имеющей подходящие права для выполнения функций, используемых qhb_rewind на исходном сервере (подробную информацию см. ниже в параграфе Примечания), или от имени суперпользователя. Этот параметр требует, чтобы исходный сервер был запущен и принимал подключения.

-R
--write-recovery-conf
Создать standby.signal и добавить параметры подключения в qhb.auto.conf в выходном каталоге. Для этого параметра обязательно указание --source-server.

-n
--dry-run
Делать все, кроме фактического изменения целевого каталога.

-N
--no-sync
По умолчанию qhb_rewind будет ожидать успешной записи всех файлов на диск. С этим параметром qhb_rewind будет завершаться без ожидания, что быстрее, но в случае последующего сбоя операционной системы может привести к повреждению каталога данных. В целом, этот параметр полезен для тестирования, но его не следует использовать в производственной установке.

-P
--progress
Запускает вывод сообщений о прогрессе. При включении этого параметра во время копирования данных из исходного кластера выдается приблизительный отчет о ходе выполнения.

-c
--restore-target-wal
Использовать команду из restore_command, определенную в конфигурации целевого кластера, чтобы извлечь файлы WAL из архива WAL, если эти файлы стали недоступны в каталоге pg_wal.

--debug
Выводить подробную отладочную информацию, которые в основном полезны для разработчиков, отлаживающих qhb_rewind.

--no-ensure-shutdown
qhb_rewind требует, чтобы целевой сервер был штатно отключен перед синхронизацией. По умолчанию если целевой сервер не был отключен штатно, qhb_rewind запускает его в однопользовательском режиме, чтобы сначала завершилось восстановление после сбоя, а уже потом останавливает его. С этим параметром qhb_rewind не делает этого, а сразу завершается с ошибкой, если сервер не был штатно отключен. В таком случае ожидается, что пользователи сами разберутся с этой ситуацией.

-V
--version
Отобразить информацию о версии и завершиться.

-?
--help
Показать справку и завершиться.

Переменные среды

Когда используется параметр --source-server, qhb_rewind также использует переменные среды, поддерживаемые libpq (см. раздел Переменные среды).

Переменная среды PG_COLOR указывает, использовать ли цвет в диагностических сообщениях. Возможные значения: always (всегда), auto (автоматически) и never (никогда).

Примечания

Если при выполнении qhb_rewind исходным кластером является работающий сервер, вместо суперпользователя можно использовать роль, имеющую подходящие права в исходном кластере для выполнения функций, используемых qhb_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;

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

Как это работает

Основная идея — скопировать все изменения на уровне файловой системы из исходного кластера в целевой:

Сканируется журнал WAL целевого кластера, начиная с последней контрольной точки до точки, где история временной шкалы исходного кластера ответвилась от целевого. Для каждой записи WAL записывается каждый затронутый блок данных. В результате получается список всех блоков данных, которые были изменены в целевом кластере после того, как исходный кластер ответвился. Если некоторые файлы WAL стали недоступны, можно попробовать повторно запустить qhb_rewind с параметром -c, чтобы поискать отсутствующие файлы в архиве WAL.
Все эти измененные блоки копируются из исходного кластера в целевой, либо используя прямой доступ через файловую систему (--source-pgdata), либо через SQL (--source-server). Теперь файлы отношений находятся в том же состоянии, в котором они быть в момент последней завершенной контрольной точки перед точкой, где разошлись временные линии WAL исходного и целевого кластеров, с добавлением текущего состояния в исходном кластере тех блоков, которые были изменены в целевом после этого расхождения.
Копируются все остальные файлы, включая новые файлы отношений, сегменты 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 и qhbmaster.pid.
Создается файл backup_label, чтобы начать воспроизведение WAL с контрольной точки, созданной при сбое, и сконфигурировать в файле pg_control минимальный LSN согласованного состояния, определенный в результате вызова pg_current_wal_insert_lsn() при синхронизации с работающим исходным кластером или являющийся LSN последней контрольной точки при синхронизации с остановленным исходным кластером.
При запуске целевого сервера QHB воспроизводит все требуемые WAL, в результате чего каталог данных приводится в согласованное состояние.