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

4490
Keyjote

У меня есть база данных 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 и меня попросили разместить его здесь

1
опубликовано на http://stackoverflow.com/q/33437732/398670 Craig Ringer 9 лет назад 0

2 ответа на вопрос

0
Craig Ringer

Now I have recovered the broken server and want to set up again the replication so A can be the new slave. So, I take a backup from B, put it in server A, set up the recovery file and start it. The problem here is that it doesn't really work any more, as it says they are in two different time lines.

Then you didn't make the backup from B correctly. It looks from the logs like you are trying to start the old copy of A as a replica of B. That will not work.

You must remove/rename the old data directory from A. Then use pg_basebackup to make a new backup of B.

(There are other ways - see the manual - but this is the simplest and easiest to get right).

The issue with streaming replication following timeline switches is not related to your current issue.

Спасибо Спасибо спасибо. Моя резервная копия была неверной. Я правильно выполнял резервное копирование B-сервера, но с другого сервера я перепутал расположение и копировал резервную копию из другой реплицированной базы данных, поэтому сроки не совпадали. Keyjote 9 лет назад 0
0
Keyjote

As mentioned by Craig Ringer, I did a new backup and checked and after setting up the slave server it worked.

But while I was doing all that I also remembered that there was an old server which was also being a slave from the old master db (A) (that server should have not been running and that is why I did not initially think of it). Anyway, after taking the old slave down, and did back up and restore again, it simply worked.

As I said, I initially thought it was because of a bad backup, but it ended up being an error message being produce by a third server (second slave db). Just to prove my point I started the old server and got the error messages again.

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.

So, it seems that the replication was working all alone but this error messages done by a second replication were throwing me off.

Again, thanks Craig for the help.

Похожие вопросы