On Thu, Feb 16, 2012 at 8:14 PM, Adrian Klaver <adrian.kla...@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
