Re: Recovery from WAL archives not advancing timeline?

Поиск
Список
Период
Сортировка
От Don Seiler
Тема Re: Recovery from WAL archives not advancing timeline?
Дата
Msg-id CAHJZqBB-TXuPS4R2M9N0mHSQUc8OjNwCkttE4q21-Cskhe+kbg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Recovery from WAL archives not advancing timeline?  (Ian Lawrence Barwick <barwick@gmail.com>)
Ответы Re: Recovery from WAL archives not advancing timeline?  (Don Seiler <don@seiler.us>)
Re: Recovery from WAL archives not advancing timeline?  (Ian Barwick <ian.barwick@2ndquadrant.com>)
Список pgsql-admin
On Sat, Aug 8, 2020 at 10:34 AM Ian Lawrence Barwick <barwick@gmail.com> wrote:
2020年8月9日(日) 0:12 Don Seiler <don@seiler.us>:
>
> There's no attempt to look for 00000002.history that I would normally expect when a replica doing WAL restore/recovery runs of out of files to restore.

In that case are you
a) absolutely sure recovery.conf contains "recovery_target_timeline = 'latest'"?
b) the standby was restarted *after* the change was made?

I ask because not attempting to fetch a history file would be a sign
that "recovery_target_timeline"
is not set (or set but not to "latest").

I'm 100% confident that it was set, as I did it via script that wrote the recovery.conf to all while the DBs were still shut down. The file still has:

recovery_target_timeline = 'latest'

Can I set that parameter to a specific timeline (eg '2')? Or does it just take 'latest'?
 
From the timestamps, 000000010000142E0000005C and later are files
which were "recycled"
for future use and as such are perfectly normal.

Do you think it would be worth trying to delete (move/rename) the 000000010000142E0000005B file and see if it changes things?

--
Don Seiler
www.seiler.us

В списке pgsql-admin по дате отправления:

Предыдущее
От: Ian Lawrence Barwick
Дата:
Сообщение: Re: Recovery from WAL archives not advancing timeline?
Следующее
От: Don Seiler
Дата:
Сообщение: Re: Recovery from WAL archives not advancing timeline?