qhb_rewind
qhb_rewind - синхронизирует каталог данных QHB с другим каталогом
данных, который был ответвлён от него
Синтаксис
qhb_rewind [option...] { -D | --target-pgdata } directory { --source-pgdata=directory | --source-server=connstr }
Описание
qhb_rewind - это инструмент для синхронизации кластера QHB с
другой копией того же кластера после того, как временные линии кластеров
разошлись. Типичным сценарием является возвращение к работе после отказа бывшего главного сервера в качестве ведомого к другому серверу, ставшего новым главным.
Результат эквивалентен замене целевого каталога данных на исходный.
Копируются только измененные блоки из файлов отношений; все остальные
файлы копируются полностью, включая файлы конфигурации. Преимущество
qhb_rewind перед созданием новой базовой резервной копии или таких
инструментов, как rsync, заключается в том, что qhb_rewind не требует
чтения неизмененных блоков в кластере. Это делает синхронизацию намного быстрее,
когда база данных большая, и только небольшая часть блоков отличается
между кластерами.
qhb_rewind анализирует историю линии времени исходного и целевого
кластеров, чтобы определить точку их расхождения, и ожидает найти WAL в
каталоге pg_wal целевого кластера, pg_wal до точки расхождения. Точку
расхождения можно найти либо на целевой или на исходной
временной линии, либо у их общего предка. В типичном сценарии отработки
отказа, когда целевой кластер был отключен вскоре после расхождения, это
не проблема, но если целевой кластер работал в течение длительного
времени после расхождения, старые файлы WAL могут быть удалены. В этом случае их можно вручную скопировать из архива WAL
в каталог pg_wal или считать при запуске, настроив primary_conninfo
или restore_command. Использование qhb_rewind не ограничивается
переключением при отказе. Например, резервный сервер может быть повышен и
выполняет несколько записывающих транзакций, затем, после синхронизации, снова
становится резервным.
Когда целевой сервер запускается впервые после запуска qhb_rewind, он
переходит в режим восстановления и воспроизводит все изменения из WAL,
сгенерированные на исходном сервере, после точки расхождения. Если
какие-то сегменты WAL не доступны на исходном сервере при запуске
qhb_rewind, и, следовательно, не могли быть скопированы, то их необходимо предоставить при запуске целевого
сервера. Это можно сделать, создав файл recovery.signal в целевом
каталоге данных и настроив подходящую команду restore_command в
qhb.conf.
qhb_rewind требует, чтобы на целевом сервере был включен режим
wal_log_hints в qhb.conf, либо включены контрольные суммы данных, когда
кластер был инициализирован с помощью initdb. Ни один из этих режимов в
настоящее время не включен по умолчанию. full_page_writes также должен
быть включен (по умолчанию он включен).
Предупреждение
Если во время обработки происходит сбойqhb_rewind, вероятно, целевой каталог данных будет в таком состоянии, которое не подойдёт для восстановления. В таком случае рекомендуется сделать новую резервную копию.
qhb_rewindсразу прекратит работу, если найдет файлы, непосредственная запись в которые невозможна. Это может произойти, например, когда исходный и целевой сервер используют одинаковые пути файлов для ключей и сертификатов SSL, доступных только для чтения. Если такие файлы существуют на целевом сервере, рекомендуется их удалить перед запускомqhb_rewind. После синхронизации некоторые из этих файлов могут быть скопированы из источника, и в этом случае может потребоваться удалить скопированные данные и восстановить ссылки, использовавшиеся до синхронизации.
Параметры
qhb_rewind принимает следующие аргументы командной строки:
| Аргумент | Описание |
|---|---|
-D directory, --target-pgdata=directory | Указывает целевой каталог данных, который синхронизируется с источником. Целевой сервер должен быть штатно остановлен перед запуском qhb_rewind |
--source-pgdata=directory | Задает путь файловой системы к каталогу данных исходного сервера, с которым нужно синхронизировать целевой. Этот параметр требует, чтобы исходный сервер был штатно остановлен |
--source-server=connstr | Указывает строку подключения libpq для подключения к исходному серверу QHB, с которым нужно синхронизировать целевой. Соединение должно быть обычным (без репликации) от имени роли, имеющей достаточные разрешения для выполнения функций, используемых qhb_rewind на исходном сервере (см. Раздел «Примечания»), или от имени суперпользователя. Этот параметр требует, чтобы исходный сервер был запущен, и работал не в режиме восстановления |
-n, --dry-run | Делать все, кроме внесения изменений в целевой каталог |
-N, --no-sync | По умолчанию qhb_rewind будет ожидать записи всех файлов на диск. С этим параметром qhb_rewind будет завершаться без ожидания, что несколько быстрее, но в случае сбоя операционной системы может привести к повреждению каталога синхронизированных данных. Как правило, этот параметр полезен для тестирования, но его не следует использовать в продакшене |
-P, --progress | Выводить сообщения о прогрессе. Включение этого параметра даст приблизительный отчет о ходе выполнения при копировании данных из исходного кластера. |
--debug | Выводить отладочную информацию. (Полезно для разработчиков при отладке qhb_rewind) |
-V, --version | Показать версию qhb_rewind и выйти |
-?, --help | Показать справку об аргументах командной строки qhb_rewind и выйти |
Окружение
Когда используется параметр --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 отмечается каждый затронутый блок данных. В результате получается список всех блоков данных, которые были изменены в целевом кластере после того, как исходный кластер отделился.
-
Копируются все эти измененные блоки из исходного кластера в целевой кластер, напрямую через файловую систему (
--source-pgdata) или через SQL (--source-server). -
Копируются все остальные файлы, такие как 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. -
Применяется WAL из исходного кластера, начиная с контрольной точки, созданной при отработке отказа. (Строго говоря,
qhb_rewindне применяет WAL, он просто создает файл метки резервной копии, который запускает QHB и воспроизводит все WAL с этой контрольной точки).