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).
>
> Personally, I take sync replication to be basically an all or nothing
>
> > proposition. By setting it up you are saying you want, at minimum, two
> > database
> > clusters to be in sync at any point in time all the time (except for
> > start up).
> > If that is not possible then you are really looking for async
> > replication.
>
> Yeah. We will need to make a decision accordingly.
>
> Thanks again,
> VB
--
Adrian Klaver
adrian.klaver@gmail.com