Datacenter Activation Coordination mode (DAC) is a property in a Database Availability Group (DAG). This mode is used to control the database mount on the start-up behavior of the Database Availability Group (DAG). The feature is designed to prevent the split brain from occurring at a database level when a switchback occurs.
So, what is a split brain? A split brain, which is also known as the split-brain syndrome, is a condition where a mailbox database is set as the active copy of two members of the Database Availability Group. This results in communication issues between the two servers and databases.
To prevent a split brain, you can enable the Datacenter Activation Coordination mode (DAC) as it requires permission to mount the database from the Database Availability Group (DAG) members before activation. Think of it as a failsafe option.
How to Check and Enable DAC Mode?
When Datacenter Activation Coordination mode (DAC) is enabled, apart from preventing your cluster to have a split-brain situation, it also enables new cmdlets, including Stop-DatabaseAvailabilityGroup, Start-DatabaseAvailabilityGroup, and Restore-DatabaseAvailabilityGroup. These commands come in handy during datacenter switchover.
To confirm whether the DAC mode is active or not, you can use the Get-DatabaseAvailabilityGroup command with the following parameters to get the information.
Get-DatabaseAvailabilityGroup | Select Name,Servers,DatacenterActivationMode
If it has not been enabled, the output will show as ‘off’.
To enable the DAC mode, you need to use the Set-DatabaseAvailabilitGroup cmdlet as given below.
Set-DatabaseAvailabilityGroup servername -DatacenterActivationMode DagOnly /servername
Once this is complete, the DataCenterActivationMode will change to DagOnly.
Things to Consider Before Enabling DAC Mode
The DAC mode is by default disabled when a high availability Exchange Server is configured. It should be enabled for all Database Availability Groups having two or more members that are configured to use continuous replication.
If you have third-party replication software or hardware installed, it is suggested not to enable the feature. This also goes for third-party replication mode. It is also not supported if your DAG has only one member in the cluster.
Another thing to consider is that the DAC mode can be enabled on any Database Availability Group that exists within a single datacenter location, although it is not likely for a split-brain to happen. It is recommended to enable it as there is still a possibility that this can happen. The split brain can easily happen when having a multi-site setup where one Exchange Server is at the main site and the others at a different geo-location for disaster recovery and business continuity. This can happen due to latency, disconnections, or even misconfiguration between the sites.
It is important to know these things as there could be issues if it is not configured well or configured with an unsupported setup. You will not like to face a setup down with corrupted Exchange transaction logs or database mismatch between the site and data loss. If two databases are active, you will have issues with replication and even data integrity.
What to Do if Split Brain Happens?
If the process of split-brain occurs, both servers will think they are active servers. This will cause havoc in the data on the site and would result in the Exchange database corruption or even damage to the databases or logs.
In such cases, you would end up restoring the servers from backup as resolving the matter can take a good number of hours. Restoring from backup would result in data loss, depending on the time of the day this happens. Having corrupted databases or transaction logs is not nice because the databases will not mount.
You can use ESEUtil to perform a quick recovery or hard recovery to fix the problem. However, hard recovery is not recommended as it will delete any data that is deemed corrupted. After all this ordeal, there is no guarantee that the database will mount.
An Alternative Solution
Third-party Exchange recovery applications, such as Stellar Repair for Exchange can be handy in such situations. Stellar Repair for Exchange can open multiple Exchange Server databases from any version and in any state. You can browse through the data store and export to PST and other file formats. In case the Exchange database is not mounting, you can easily create a new database and export directly from the corrupted database to the new one. You can also directly export to an Office 365 tenant. It features automatic or manual mailbox mapping, parallel mailbox recovery, VIP priority exports, and continuation in case the process is interrupted. This will reduce the cost and time of recovery to a minimum.
5 min read
