Догоняет ли PostgreSQL 9.1 потоковая репликация после задержки без архивации WAL?

16

Контекст:

Предположим, что при использовании потоковой репликации / горячего резервирования в кластере Postgres 9.1 резервный узел отключается. Он не работает в течение дня, в течение которого на мастере происходит много DML. Резервный файл recovery.conf не содержит запись 'restore_command' (для восстановления из файлов журнала WAL), но содержит строку 'primary_conninfo' (для потоковой репликации).

Вопрос:

Если я снова запускаю режим ожидания после дня изменений на мастере. Будет ли он «догонять» (в конечном итоге переходить в состояние, которое отражает мастер), используя только потоковую репликацию? Или мне нужно включить архивирование файлов WAL и разрешить ему применять файлы, заархивированные во время простоя, для обеспечения валюты?

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

Благодарность!

postgresql replication Зак Б
источник

Ответы:

9

Да, он будет догонять, используя только потоковую передачу, если (и только если) , количество сегментов WAL, сгенерированных с момента последнего обновления в режиме ожидания, меньше значения wal_keep_segments в postgresql.conf. Это описано в этом разделе документации: Репликация

Мэтью Вуд
источник
2
Этот ответ правильный, но он подчеркивает проблему. Если вы когда-нибудь передадите wal_keep_segments, ваша репликация не работает. Настройка репликации на основе файлов не является обязательной, если вы хотите, чтобы система переживала длительное отключение от мастера и перезагружалась.
Грег Смит
0

на резервном узле вы можете установить restore_command на recovery.conf, а затем скопировать файлы мастера pg_xlog (которые отсутствуют в режиме ожидания) в папку, на которую указывает restore_command. Вы можете легко найти, какие xlog-файлы отсутствуют, запустив узел запуска и набрав

ps aux | grep postgres

там вы увидите «ожидание 000000020000005200000025» или что-то в этом роде, которое говорит вам, какой файл pg_xlog вы должны начать копировать с главного устройства на путь restore_command в режиме ожидания.

если вы включите wal_archiving, он запустит архив с момента установки.

sftsz
источник
Я понимаю, что, используя файловое WAL-архивирование и предоставляя резервной команде restore_command для загрузки WAL-файлов, я могу убедиться, что она перехватывает. Это не мой вопрос, хотя; Я хочу знать, догонит ли резервный сервер, если я использую только потоковую репликацию (без доставки файлов WAL, только поток репликации, как указано в 'primary_conninfo').
Зак Б
нет. Postgres этого не делает. Вы должны скопировать файлы журнала, если есть задержка на вашей репликации.
sftsz
0

Нет, я настроил экземпляр потоковой репликации, и он как-то не синхронизировался, я не мог заставить его работать снова, пока не сделал руководство rsyncпо архивам WAL.

xenoterracide
источник