Re: Restart replicated slave procedure

On Fri, Aug 22, 2014 at 2:21 PM, Jerry Sievers <gsievers19(at)comcast(dot)net>
wrote:

> Joseph Kregloh <jkregloh(at)sproutloud(dot)com> writes:
>
> > Hi,
> >
> > Currently I am doing asynchronous replication from master to
> > slave. Now if I restart the slave it will fall out of sync with the
> > master. Is there a correct procedure or set of steps to avoid this? I
> > am looking for best practices or suggestions. Whenever my slave fell
> > out of sync I would either issue a new pg_base_backup() or set the
> > master to pg_start_backup() do an rsync and stop using
> > pg_stop_backup(). If there is a way to avoid any of that, for example
> > pause replication to hold all the wal files until the replicated slave
> > comes back and then release them once the replicated slave is up.
> >
> > I apologize if this question has already been asked. I did some
> searching beforehand.
>
> See the manual and read up on the 2 GUCs; archive_command and
> wal_keep_segments.
>
>
Thanks, i'll read into this some more.

> wal_keep_segments lets you hold a configurable number of WAL segments
> back and buy some more time till you have to resync the stand bys.
>
> Setting archive_command to '' or something like '/bin/false' lets you
> delay archiving forever till you change them back again and/or fill
> whatever file system pg_xlog writes to :-)
>
>
So disabling the archive_command by setting it to and empty string or
/bin/false will effectively pause log shipping? When I re-enable the
archive command will it continue where it left of when the archive_command
was "disabled"?

> >
> > Thanks,
> > -Joseph Kregloh
> >
>
> --
> Jerry Sievers
> Postgres DBA/Development Consulting
> e: postgres(dot)consulting(at)comcast(dot)net
> p: 312.241.7800
>