Thread: How to Straming replication chatch up from archive

Hi,
we have a doubt interpreting documentation. We have a 9.6 installation master+stand-by in streaming replication.
Master database is in archive mode and WAL archive destination (NFS) is mounted in both master and stand-by servers.

The question is regarding this part of documentation: (https://www.postgresql.org/docs/9.6/warm-standby.html)


If you use streaming replication without file-based continuous archiving, the server might recycle old WAL segments before the standby has received them.
If this occurs, the standby will need to be reinitialized from a new base backup. You can avoid this by setting wal_keep_segments to a value large enough to
ensure that WAL segments are not recycled too early, or by configuring a replication slot for the standby. If you set up a WAL archive that's accessible from the standby,
these solutions are not required, since the standby can always use the archive to catch up provided it retains enough segments.


if the master overwrite the wal BEFORE they are sent to the standby via replication, does the standby automatically start looking in WAL archive destination?
Or this step have to be made by hand?


regards and thanks in advance
MP

 > if the master overwrite the wal BEFORE they are sent to the standby via
 > replication, does the standby *automatically* start looking in WAL
 > archive destination?
 > Or this step have to be made by hand?

I understand it works this way: normally, the replica tries to stream 
from master. If it is not able to (for example, the requested WAL has 
been already rotated), then it tries to call the restore_command.

See 
https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-PITR-RECOVERY

So you just need to specify where the older WALs are. For example

     restore_command = 'cp /mnt/nfs/archivedir/%f %p'

assuming the server has a similar archive_command that stores WALs into 
that directory.

--
Filip Sedlák