Re: WAL File Recovery on Standby Server Stops Before End of WAL Files

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: Les(dot)Ryan(at)wsp(dot)com
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: WAL File Recovery on Standby Server Stops Before End of WAL Files
Date: 2021-10-28 01:58:31
Message-ID: 20211028.105831.1248025594517640647.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

At Wed, 27 Oct 2021 16:42:52 +0000, "Ryan, Les" <Les(dot)Ryan(at)wsp(dot)com> wrote in
> 2021-10-27 10:26:31.467 MDT [2012] LOG: redo starts at 419/5229A858
...
> 2021-10-27 10:26:36.188 MDT [2012] LOG: restored log file "00000001000004190000005A" from archive
> 2021-10-27 10:26:36.750 MDT [2012] LOG: consistent recovery state reached at 419/5ABFFFF8
> 2021-10-27 10:26:36.752 MDT [6204] LOG: database system is ready to accept read only connections
> 2021-10-27 10:26:36.823 MDT [6040] LOG: started streaming WAL from primary at 419/5A000000 on timeline 1
>
> * There are many more WAL files available starting with 00000001000004190000005B but the restore process always stops at 00000001000004190000005A.
>
> I have two questions:
>
> * Why does the WAL file recovery process now stop after it reads 00000001000004190000005A?
> * What do I need to do to get PostgreSQL to recover the rest of the available WAL files.

The info above alone donesn't clearly suggest anything about the
reason. Could you show the result of "pg_waldump
00000001000004190000005A 2>&1 | tail -5"? What I'm expecting to see
is an error message from pg_waldump before the end of the file. It
would be the immediate cause of the problem.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dilip Kumar 2021-10-28 04:29:11 Re: WAL File Recovery on Standby Server Stops Before End of WAL Files
Previous Message David G. Johnston 2021-10-27 23:18:20 Re: jsonb: unwrapping text