Thank you for your response Ron and apologies for delayed response.
"The guarantee that all transactions committed on the primary have been written to the secondary just before shutting down Primary." -> Is this for SYNC or ASYNC?
Thanks for clarifying that the transactions would be blocked if the network/WAN link is down.
"Thus... you leave replication to the remote DR site in asynchronous mode until that very specific point when you need to guarantee remote consistency: just before you shut down the Primary for patching.
Once the Primary is patched, and replication is restored, then you can change back to async mode." -- Makes sense now. Thanks a lot for clarifying.
On Fri, May 3, 2024 at 8:55 AM Ron Johnson <ronljohnsonjr@xxxxxxxxx> wrote:
On Tue, Apr 30, 2024 at 12:30 PM akshay polji <akshay.polji@xxxxxxxxx> wrote:---- Point - 3"You can switch from async to sync replication just before patching, and then switch back to async when it's completed." --> I am a little confused here. What benefit do we get by switching from async to sync replication before patching?The guarantee that all transactions committed on the primary have been written to the secondary just before shutting down Primary.I mean that would block the transactions on the primary DB right?Wrong 99.99% of the time. It blocks the transaction IFF the network/WAN link is down.When the WAN link is up, you "just" get cascading transaction slowness because of WAN latency.Thus... you leave replication to the remote DR site in asynchronous mode until that very specific point when you need to guarantee remote consistency: just before you shut down the Primary for patching.Once the Primary is patched, and replication is restored, then you can change back to async mode.
