Re: Restart replicated slave procedure - Mailing list pgsql-general

From Jerry Sievers
Subject Re: Restart replicated slave procedure
Date
Msg-id 86egw8fkqu.fsf@jerry.enova.com
Whole thread Raw
In response to Restart replicated slave procedure  (Joseph Kregloh <jkregloh@sproutloud.com>)
Responses Re: Restart replicated slave procedure  (Joseph Kregloh <jkregloh@sproutloud.com>)
List pgsql-general
Joseph Kregloh <jkregloh@sproutloud.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.

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 :-)

>
> Thanks,
> -Joseph Kregloh
>

--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 312.241.7800


pgsql-general by date:

Previous
From: hubert depesz lubaczewski
Date:
Subject: Re: deadlock in single-row select-for-update + update scenario? How could it happen?
Next
From: Adrian Klaver
Date:
Subject: Re: deadlock in single-row select-for-update + update scenario? How could it happen?