On Wed, 2024-02-07 at 12:07 +0100, Alpaslan AKDAĞ wrote:
> We have a primary, a hot standby and 2 warm standby servers with 2 days delay.
>
> After switchover since 01.02.2024 hot standby server does not archive wal files. I couldn't find the problem.
>
> related postgresql.conf lines:
> archive_mode = on
> archive_command = 'cp %p /archive/archived_wal/%f && cp %p /opt/postgres/backup/archived_wal/%f'
>
> and in log files there are lines like below but no error or failure lines:
>
> postgresql-2024-02-05_000000.log:2024-02-05 06:25:50.272 CET [979081] LOG: restartpoint complete: wrote 477
buffers(0.0%); 0 WAL file(s) added, 0
> removed, 4 recycled; write=47.946 s, sync=0.005 s, total=47.964 s; sync files=85, longest=0.001 s, average=0.001 s;
distance=65484kB, estimate=413488
> kB
> postgresql-2024-02-05_000000.log-2024-02-05 06:25:50.272 CET [979081] LOG: recovery restart point at 25C/74083E58
> postgresql-2024-02-05_000000.log-2024-02-05 06:25:50.272 CET [979081] DETAIL: Last completed transaction was at
logtime 2024-02-05 06:25:50.223799
> +01.
That looks like the standby wasn't promoted and is still in recovery,
so it won't generate WAL.
Restartpoints are only written on servers in recovery mode. Moreover,
a promote request would generate a log entry.
Another option would be that the promote request is further up in the log,
and the server takes a long time to replay all the changes
(if the "2 days delay" you mention are set in "recovery_min_apply_delay").
What do you get for
SELECT pg_is_in_recovery();
Yours,
Laurenz Albe