On Thu, Feb 16, 2012 at 8:14 PM, Adrian Klaver
<adrian.klaver@gmail.com> wrote:
On Wednesday, February 15, 2012 10:21:02 pm Venkat Balaji wrote:
> Andrian,
>
> Thanks a lot !
>
> So in this case you are not waiting for confirmation of the commit being
>
> > flushed
> > to disk on the standby. It that case you are bypassing the primary
> > reason for
> > sync replication. The plus is transactions on the master will complete
> > faster
> > and do so in the absence of the standby. The minus is that you are in
> > sort of an
> > in between state.
>
> I understand. My worry and requirement is to ensure master is not disturbed
> for any reason.
> In sync rep, the biggest worry is if standby server is unavailable and is
> down for longer time, master hangs and will be in the same state until
> standby comes back up or replication must be broken temporarily (until
> standby comes back up) so that master runs without interruption. This is a
> costly exercise on production from downtime perspective.
So just use regular streaming replication without sync rep. You get record based
transaction shipping without having to wait for the standby. You will need to
make sure that wal_keep_segments is big enough to cover any down time on the
standby(you would need that for sync rep also).
As we already have streaming replication configured. We have rolled back the plan of setting up synchronous replication.
Thanks,
VB