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. 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
