On Mon, Jan 15, 2018 at 12:13:46AM +0000, Dylan Luong wrote:
> The content of the history file 00000006.history is:
Please do not top-post. This breaks the logic of the thread.
> $ more 00000006.history
> 1 2CE/8A000098 no recovery target specified
> 2 2CE/FF974EF0 no recovery target specified
> 3 2CF/51000098 no recovery target specified
> 4 2D1/C90ACD88 no recovery target specified
> 5 383/C0790E50 no recovery target specified
So indeed the timeline has forked at 0000000500000383000000C0, which is
what the .partial file also means.
> Here are the last few archive file of the old timeline (old master):
>
> 0000000500000383000000BD
> 0000000500000383000000BE
> 0000000500000383000000BF
> 0000000500000383000000C0
> 0000000500000383000000C1
>
> Here are the first few archive files of the new timeline (new master):
> 0000000500000383000000C0.partial
> 0000000600000383000000C0
> 0000000600000383000000C1
> 0000000600000383000000C2
> 0000000600000383000000C3
>
> Looks like it has folked at C0.
> But why is the new slave asking for 0000000600000383000000BE on
> timeline during the restore after the pg_rewind? And not from C0?
The rewound standby needs to recover from the point of the last
checkpoint where timeline forked. So I can guess that this record is
located in segment 0000000500000383000000BE. Now I find strange that the
standby requests for a segment on the new timeline 5, while it should
start at TLI 5. Are you sure that the standby had the means been able to
fetch segment 0000000500000383000000BE? Something looks weird from your
operational point of view with your archives..
--
Michael