Thread: wal receiver process always start after startup process recovering all WALs and need new WAL?
wal receiver process always start after startup process recovering all WALs and need new WAL?
From
Jov
Date:
I ask this problem because I meet twice recently that the wal receiver process do not start after a long time.
first time:
I change recovery_min_apply_delay from default to 3d on a standby,the standby start but there is no receiver process,and on the master,pg_stat_replication show nothing.After 3 days the standby recover to normal,and I can see it in the pg_stat_replication on the master.
second time:
I change this 3day-behind-slave point to a cascade slave of the master,and the receiver process do not start too,the startup process replay the wal slowly.
I think this behavior for recovery_min_apply_delay is not good,because if the receiver do not fetch the wal for a long time(in these cases it must replay 3d's wal before wal receiver start),the master will delete the wal,and the standby will need be re do.
Jov
blog: http:amutu.com/blog
Re: wal receiver process always start after startup process recovering all WALs and need new WAL?
From
Jim Nasby
Date:
On 12/15/15 2:49 AM, Jov wrote: > I think this behavior for recovery_min_apply_delay is not good,because > if the receiver do not fetch the wal for a long time(in these cases it > must replay 3d's wal before wal receiver start),the master will delete > the wal,and the standby will need be re do. AFAIK, if you use a replication slot (new in 9.4) that won't happen, because the master will know that the replica still hasn't applied the data. If you don't use replication slots then you need to set wal_keep_segments large enough on the master so that it doesn't delete segments that are needed. Or configure WAL archiving and let the replica replay from the archive. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com