On 11/22/2016 3:41 AM, Subhankar Chattopadhyay wrote:
John, Can you explain the Wal Archive procedure, how it can be setup so that the slave never goes out of sync, even if master deletes the WAL files?
The WAL archive will typically be a separate file server that both the master and slave can reach... it could be accessed via NFS or via scp or whatever is appropriate for your environment. The master is configured with an archive command (cp in the case of nfs, or scp for ssh/scp, or whatever) to copy WAL segments to the archive. The slave is setup with an recovery command (cp, scp, etc) to fetch from this same archive.
The archive will continue grow without limit if you don't do some cleanup on it. one strategy is to periodically (weekly? monthly?) do a base backup of the master (possibly by using rsync or another file copy method, rather than pg_basebackup), and keep 2 of these full backups, and all wal archives since the beginning of the oldest one. with this backup + archive, you can initialize a new slave without bothering the master (rsync or scp or cp the latest backup, then let the slave recover from the wal archive).
this backup+archive will also let you do point-in-time-recovery (aka PITR). say something catastrophic happens and the data in the master is bad after some point in time (maybe a jr admin accidentally clobbers key data, but the app kept running). you can restore the last good base backup, and recover up to but not including the point in time of the transaction that clobbered your data.
-- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
