What is DAC?
First introduced in Exchange 2010 SP1, Datacenter Activation Coordination (DAC) it is a new property of the Database Availability Group (DAG) that will help solving a specific problem which is (Split brain in case of datacenter switch over, that is when you have your DAG stretched between two or more sites and you are performing manual switch over).
When shall I use it?
As per my understanding, when you have DAG stretched between two sites. Enabling DAG will help prevent split brain when you perform Datacenter switch over. Split brain in this case is when different copies of the same database get mounted in the primary and secondary datacenters causing divergence.
Where is DAC configured?
DAC is a property of the DAG (Database Availability Group) and it is disabled by default.
Who controls DAC?
The Active Manager by maintaining a bit in memory that can be set to 0 or 1.
The first thing to understand is that DAC solves certain scenarios and it will not add anything if you have single Exchange installation in one site or if you don’t have DAG stretch between two sites.
Saying that, I will quote from TechNet the following example about the DAC usage:
“Consider the two-datacenter scenario. Suppose there is a complete power failure in the primary datacenter. In this event, all of the servers and the WAN are down, so the organization makes the decision to activate the standby datacenter. In almost all such recovery scenarios, when power is restored to the primary datacenter, WAN connectivity is typically not immediately restored. This means that the DAG members in the primary datacenter will power up, but they won’t be able to communicate with the DAG members in the activated standby datacenter. The primary datacenter should always contain the majority of the DAG quorum voters, which means that when power is restored, even in the absence of WAN connectivity to the DAG members in the standby datacenter, the DAG members in the primary datacenter have a majority and therefore have quorum. This is a problem because with quorum, these servers may be able to mount their databases, which in turn would cause divergence from the actual active databases that are now mounted in the activated standby datacenter.”
In summary, DAC prevent split brain scenario in case disconnected stretch DAG between two sites.
Interested in more theory?
Suppose we have DAG stretched between two datacenters JFK and LON. DAG has four mailbox servers, two at JFK site, and two at LON site, and a witness share in JFK site. Our database has two copies, one on JFK mailbox server and one on LON mailbox server.
JFK site is down and the administrator decided to bring LON datacenter up by forcing the quorum (LON contains two servers which are two votes out of five. So forcing the quorum is necessary). Now out database is mounted on LON datacenter and everything is fine.
Suddenly, JFK is back again and the mailbox servers at JFK site are booting. The WAN link is still down. JFK servers are all up now, and they still cannot communicate with LON site, so they only have three votes ( two mailbox server and a witness share), so JFK servers believe they have the majority and they have quorum state, so our database get mounted on JFK server.
At this moment, we have the same database mounted in two different datacenter.
DAC is invented to solve this scenario.