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

у меня есть база данных postgres (версия 9.4) с потоковой репликацией (master, slave configuration). Вызовем master db A и slave db B.

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

Теперь я восстановил сломанный сервер и хочу снова настроить репликацию, чтобы быть новым ведомым.
Итак, я беру резервную копию из B, помещаю ее в сервер 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 FilesPostgreSQL9.4binpg_archivecleanup" "Z:pg_xlog" "%r"'
trigger_file = 'Z:triggerpgsql.trigger.sekasto021'
recovery_target_timeline = 'latest'

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

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

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

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

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

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

25
задан Community
02.05.2023 20:57 Количество просмотров материала 2455
Распечатать страницу

2 ответа

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

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

вы должны удалить/переименовать старый каталог данных из А. затем использовать pg_basebackup сделать новую резервную копию Б.

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

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

0
отвечен Craig Ringer 2023-05-04 04:45

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

но в то время как я делал все это, я также вспомнил, что был старый сервер, который также был рабом от старого главного 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.

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

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

0
отвечен Keyjote 2023-05-04 07:02

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх