Postgres восстановление репликации, конфликт сроков

Question

У меня есть база данных postgres (версия 9.4) с потоковой репликацией (главная, подчиненная конфигурация). Позволяет вызывать master db A и slab db B.

На сервере, на котором работает A, произошел сбой, и нам пришлось переключиться, где мы выдвинули B новым мастером. До сих пор все хорошо и работает нормально.

Теперь я восстановил сломанный сервер и хочу снова настроить репликацию, чтобы А мог быть новым ведомым. Итак, я беру резервную копию с B, помещаю ее на сервер A, настраиваю файл восстановления и запускаю его. Проблема здесь в том, что он больше не работает, так как говорит, что они находятся в двух разных временных рамках.

Вот сообщения от A (нового раба):

2015-10-30 14:28:04 LOG:  database system was shut down in recovery at 2015-10-30 14:27:28 CET 
2015-10-30 14:28:04 LOG:  entering standby mode 
2015-10-30 14:28:04 LOG:  redo starts at 1A/5802B1A8 
2015-10-30 14:28:04 LOG:  consistent recovery state reached at 1A/581FA248 
2015-10-30 14:28:04 LOG:  record with zero length at 1A/581FA248 
2015-10-30 14:28:04 LOG:  database system is ready to accept read only connections 
2015-10-30 14:28:05 LOG:  started streaming WAL from primary at 1A/58000000 on timeline 2 
2015-10-30 14:28:07 ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history 
2015-10-30 14:28:07 DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0. 
2015-10-30 14:28:12 ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history 
2015-10-30 14:28:12 DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0.

мой файл восстановления выглядит так:

standby_mode = 'on'
primary_conninfo = 'host=serverB port=5432 user=replication-user'
restore_command = 'copy "Z:\\pg_xlog\\%f" "%p"'
archive_cleanup_command = '"C:\\Program Files\\PostgreSQL\\9.4\\bin\\pg_archivecleanup" "Z:\\pg_xlog" "%r"'
trigger_file = 'Z:\\trigger\\pgsql.trigger.sekasto021'
recovery_target_timeline = 'latest'

Погуглить я нашел почти тот же вопрос здесь , но без ответов. Нашел страницу от Майкла Пакье, который описывает, что со мной происходит (хотя он говорит, что это не проблема в версии 9.3). Он говорит:

FATAL:  timeline 2 of the primary does not match recovery target timeline 1

Эту проблему можно решить только путем копирования сегментов WAL из главного узла или использования архива WAL.

Но, к сожалению, я не знаю, что он имеет в виду, копируя сегменты wal из мастера, используя настенный архив.

Любая помощь / руководство приветствуется. Спасибо

Обновление: я разместил этот вопрос на stackoverflow и меня попросили разместить его здесь

Answer 1

Теперь я восстановил сломанный сервер и хочу снова настроить репликацию, чтобы А мог быть новым ведомым. Итак, я беру резервную копию с B, помещаю ее на сервер A, настраиваю файл восстановления и запускаю его. Проблема здесь в том, что он больше не работает, так как говорит, что они находятся в двух разных временных рамках.

Тогда вы не сделали резервную копию из B правильно. Из журналов видно, что вы пытаетесь запустить старую копию A как копию B. Это не сработает.

Вы должны удалить / переименовать старый каталог данных из A. Затем использовать pg_basebackup чтобы сделать новую резервную копию B.

(Существуют и другие способы - см. Руководство - но это самый простой и легкий способ получить право).

Проблема с потоковой репликацией после переключения временной шкалы не связана с вашей текущей проблемой.

Answer 2

Как упомянул Крейг Рингер, я сделал новую резервную копию и проверил, и после настройки подчиненного сервера все заработало.

Но когда я делал все это, я также вспомнил, что был старый сервер, который также был ведомым от старого главного db (A) (этот сервер не должен был работать, и поэтому я изначально не думал об этом) , Как бы то ни было, после того, как старый раб забрал и снова сделал резервное копирование и восстановление, все заработало.

Как я уже сказал, я изначально думал, что это из-за плохой резервной копии, но в итоге это было сообщение об ошибке, создаваемое третьим сервером (второй ведомый db). Просто чтобы доказать свою точку зрения, я запустил старый сервер и снова получил сообщения об ошибках.

2015-10-31 10:26:37 CET ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history
2015-10-31 10:26:37 CET DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0.

Таким образом, кажется, что репликация работала в одиночку, но сообщения об ошибках, сделанные во время второй репликации, оттолкнули меня.

Еще раз спасибо Крейг за помощь.