AlwaysOn Availability Group DR architecture - Commit mode Confusion
-
In my current role I've inherited an AlwaysOn Availability Group setup of 2 nodes within 2 different data centers. For the sake of anonymity I shall refer to these 2 as Server A & Server B. In normal running Server A has the primary replica & Server B has the DR secondary replica. If you look at the AAG properties, Availablity Commit mode for the Primary replica is set synchronous (to itself) & for the DR replica it set Asynchronous. Architecturally speaking this seems fine, given the distance between the DCs. Failover mode is configured manual
Am I missing a trick here? - I don't understand why the primary replica has a commit mode to itself at all.
Everything I have read tells me about the effect commit mode has with regard to log hardening on the secondary replicas & I get that.2nd thing that really pickled my noodle was last week there was a DR test/failover & now the situation (see pic below) where the primary & secondary replica roles are reversed, but the commit modes did not follow that failover & the situation is now that the Primary replica shows Asynch. commit to itself & the Secondary replica shows Synch. commit & the AG dashboard has synchronization warnings,
For a DR scenario should the architectural pattern be set such that both Availability modes are set Asynch to start with OR should DR instructions include a swap around of the commit modes?
Bottom line: what effect does the commit mode setting on the primary replica have? - iamdavep@hotmail.com - Tuesday, June 19, 2018 4:57 AMIn my current role I've inherited an AlwaysOn Availability Group setup of 2 nodes within 2 different data centers. For the sake of anonymity I shall refer to these 2 as Server A & Server B. In normal running Server A has the primary replica & Server B has the DR secondary replica. If you look at the AAG properties, Availablity Commit mode for the Primary replica is set synchronous (to itself) & for the DR replica it set Asynchronous. Architecturally speaking this seems fine, given the distance between the DCs. Failover mode is configured manual
Am I missing a trick here? - I don't understand why the primary replica has a commit mode to itself at all.
Everything I have read tells me about the effect commit mode has with regard to log hardening on the secondary replicas & I get that.2nd thing that really pickled my noodle was last week there was a DR test/failover & now the situation (see pic below) where the primary & secondary replica roles are reversed, but the commit modes did not follow that failover & the situation is now that the Primary replica shows Asynch. commit to itself & the Secondary replica shows Synch. commit & the AG dashboard has synchronization warnings,
For a DR scenario should the architectural pattern be set such that both Availability modes are set Asynch to start with OR should DR instructions include a swap around of the commit modes?
Bottom line: what effect does the commit mode setting on the primary replica have?Hope this helps you
https://www.microsoftpressstore.com/articles/article.aspx?p=2832586&seqNum=4
Availability groups support two different synchronization modes:
Synchronous commit With synchronous commit mode the secondary replica is kept synchronized synchronously, in real-time. The secondary database is an exact binary match of the primary database. Because the databases are kept in sync, this implies a performance overhead on primary, which can effect performance; both databases wait to be in sync before the commit. Synchronous mode facilitates the failover capability of Availability Groups. Ideally, with synchronous mode you have very low network latency between the primary replica and secondary replica. If there is a network issue between the primary replica and the secondary replica the Availability Group will automatically switch over to asynchronous mode. This allows transactions to still be completed on the synchronous replica if the secondary replica is offline or there is a network issue.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply