Re: hot standby in Postgresql 12

Yes David - the problem here is expected data hasn't made it from the
primary to the standby even after streaming is started , and there could be
many reasons for it.

I will be interested to know -
- How user created standby (pg_basebackup etc.)
- Was there any manual cleanup done on the standby pg_xlog directory?
- Is the walreceiver process running on standby? --> ps -ef | grep postgres
- Is the walsender process running on master ? --> ps -ef | grep postgres
- postgresql.auto.conf file
- Database system identifier for both master and standby ( use utility
- pg_controldata -D <master/standby data dir> liek - pg_controldata
-D /user/app/master)

I would do below to narrow down the issue-
- Stop postgres on standby or kill the postmaster process.
- Increase logging on standby
- Restart standby.
- Check standby log for status and error.
- Check connectivity between both primary and standby server- try
connecting to primary as per credentials in primary_conninfo ( psql -h
172.31.37.228
-p 5333 -U postgres -d postgres)
- Check walreceiver process running on standby and the walsender process
running on master.
- Checkpoint and switch wal on master
- Check logs and standby status

Share how above goes and also log files from both master and standby.

Regards
Rajni

On Wed, Jan 20, 2021 at 9:04 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Tue, Jan 19, 2021 at 2:56 PM Rajni Baliyan <saan654(at)gmail(dot)com> wrote:
>
>> As David highlighted,
>> >> I took the error from the cp command to mean that this was in fact a
>> warm standby regardless of any claims by the poster. I’ll readily admit I
>> am not that familiar with this stuff though.
>> Seems your archive command is not working properly. Set it first and then
>> try again.
>>
>
> Don't think so - as Laurenz noted the last line reads:
>
> "2021-01-18 07:31:01.043 UTC [21079]LOG: started streaming WAL from
> primary at 0/35000000 on timeline 3"
>
> Which indicates that streaming is supposedly working even though the
> expected data hasn't made it from the primary to the standby.
>
> David J.
>
>
>