Asynchronous Database Mirroring vs. Asynchronous Availability Groups

Asynchronous Database Mirroring vs. Asynchronous Availability Groups

When Database Mirroring came out in SQL Server 2005 Service Pack 1, we quickly dropped Log Shipping as our Disaster Recovery solution. Log Shipping is a good feature, but Asynchronous Database Mirroring let us fail over faster than Log Shipping.

When Always On Availability Groups (AG) came out in SQL Server 2012, we were excited to get rid of Transactional Replication, Failover Clustering, and Database Mirroring. It solved our reporting needs (this can vary for you), our High Availability needs, and our Disaster Recovery needs.

But what if you only have Disaster Recovery needs, and you want to use Availability Groups because Database Mirroring has been deprecated? Make sure you get the core setup right!

Let’s look at the big difference between Asynchronous Database Mirroring and Asynchronous Availability Groups.

ASYNCHRONOUS DATABASE MIRRORING

For Asynchronous Database Mirroring, all we need is two servers: the principal in the primary site, and the mirror as the secondary in the DR site. Set up async mirroring between the two, and you’re done. If the secondary server goes down, production keeps running. The transaction log doesn’t get cleared out when transaction log backups happen, because the primary server needs to send those log records to the secondary server. Production keeps running as long as you have enough disk space where the log files live to support this until the secondary server comes back online. Of course, if you run out of disk space, users will start getting errors. But that can take a while, and it’s often enough time for the secondary server to come back online.

ASYNCHRONOUS AVAILABILITY GROUPS

For Asynchronous AG, we still need two servers: the primary replica on the primary server, and the secondary replica in the DR site. Once the two servers are part of the same Windows Server Failover Cluster (WSFC), set up the Availability Group with both replicas, and specify asynchronous-commit for the availability mode. Now shut down the secondary replica and see what happens. Did the primary replica go down too? We’ve heard from a lot of people that their primary replica went down when they did maintenance on their secondary replica, and they weren’t sure why. This happens because quorum and/or voting weren’t configured correctly. Availability Groups rely on WSFC, which requires quorum. You’ll need another resource on the primary server to reach quorum. Once those are set up, change the WSFC’s quorum configuration to whichever option you choose. For example, “Node and File Share Majority” or “Node and Disk Majority.” Now, when the secondary copy goes down, production keeps running on the primary copy, since the cluster still has quorum (2 up, 1 down).

If you’re running Windows 2012 R2, you have Dynamic Quorum! Votes can be adjusted dynamically by the cluster when needed. Dynamic Quorum could have been useful for the setup we just described, but this was before Windows 2012 R2 was released.