Async Database Mirroring vs. Async Availability Groups: The Quorum Trap in DR Designs

For years, asynchronous database mirroring was the simplest way to keep a copy of a SQL Server database at a disaster recovery site. Mirroring is now deprecated, so most teams replace it with an asynchronous Always On availability group. On paper the two look almost identical: one primary, one remote copy, no waiting for the DR site on commit, and a forced failover with possible data loss when disaster strikes.

There’s one difference that catches teams out, though. An availability group depends on cluster quorum, and database mirroring doesn’t. Copy a mirroring design one-to-one into a two-node cluster, and taking the DR server down for maintenance can take your production databases offline with it.

This guide compares asynchronous database mirroring and asynchronous availability groups, explains the quorum trap, and shows how to design and migrate a DR setup that keeps production running when the DR site goes away.

Database Mirroring vs. Availability Groups at a Glance

What Happens When the DR Server Goes Down

The real difference between the two technologies shows up when the DR side disappears, whether for planned maintenance, a crash or a broken link between sites.

With Asynchronous Database Mirroring

Production keeps running. The principal doesn’t wait for the mirror, so users notice nothing. The only side effect is in the transaction log: log records that haven’t reached the mirror can’t be truncated, even after a log backup. The log keeps growing until the mirror comes back and catches up. As long as the log drive has enough free space, the outage on the DR side is invisible to production.

With an Asynchronous Availability Group

An availability group lives inside a cluster, and the cluster only stays online while a majority of its votes is present. Picture the typical mirroring replacement: two nodes, one in each data center, and no witness. Each node has one vote. When the DR node or the link between sites fails, the primary node can be left without a majority, and the cluster can go offline. When that happens, the availability group goes offline too. The primary SQL Server is perfectly healthy, yet the application can no longer reach its databases, and someone has to bring the cluster back by hand.

Dynamic quorum in modern Windows Server versions adjusts votes as nodes leave the cluster and makes this less likely, especially during a planned shutdown. In a two-node cluster without a witness, though, it can’t protect you against every unplanned failure or a network split between sites. Don’t rely on it as your quorum design.

Both technologies share one more behavior. While an asynchronous secondary is disconnected, the primary can’t truncate the log records it hasn’t sent yet. In sys.databases, the database’s log_reuse_wait_desc shows AVAILABILITY_REPLICA, and the log grows until the secondary catches up or is removed from the group.

How to Design an Asynchronous Availability Group for DR

Microsoft’s quorum guidance for availability groups addresses this problem directly. Three changes turn the fragile two-node design into one where production survives the loss of the DR site.

1. Don’t Give the DR Node a Vote

Microsoft’s guidance is to give votes to the node hosting the primary replica and to any automatic failover targets, and generally not to nodes at a secondary DR site. You don’t want the DR site to take part in a decision to take the cluster offline when there’s nothing wrong with the primary site. Remove its vote by setting its NodeWeight to 0.

2. Keep the Number of Votes Odd With a Witness

If the remaining voting members are even, add a witness so a tie can’t take the cluster down. A file share witness should sit outside the cluster nodes and be visible to all of them. A cloud witness uses an Azure Storage account instead and is a good fit when there’s no reliable third location.

Both changes take a few lines of PowerShell on a cluster node:

# Remove the vote from the DR-site node
(Get-ClusterNode -Name "SQLDR01").NodeWeight = 0

# Add a file share witness outside both cluster nodes
Set-ClusterQuorum -FileShareWitness "\\witness-server\SQLCluster-Witness"

# Check the result
Get-ClusterNode | Format-Table Name, State, NodeWeight, DynamicWeight
Get-ClusterQuorum

You can check the same thing from SQL Server. number_of_current_votes shows the votes after dynamic quorum has made its adjustments:

SELECT cluster_name, quorum_type_desc, quorum_state_desc
FROM sys.dm_hadr_cluster;

SELECT member_name,
       member_type_desc,
       member_state_desc,
       number_of_quorum_votes,
       number_of_current_votes
FROM sys.dm_hadr_cluster_members;

3. Write Down the Real Disaster Procedure

A DR node without a vote can’t form quorum on its own. That’s what you want day to day, but it means a real disaster needs a documented manual procedure. When the primary site is lost:

1. Force the cluster to start without quorum on the DR node.
2. Run a forced failover on the DR replica with ALTER AVAILABILITY GROUP [AG_Name] FORCE_FAILOVER_ALLOW_DATA_LOSS;
3. Resume the suspended secondary databases once the old primary comes back, and decide what to do with transactions that never reached the DR site.
4. Re-check vote assignments so the cluster has a healthy quorum in its new shape.

Keep this procedure next to your outage runbook and rehearse it. Nobody should be reading cluster documentation for the first time during a disaster.

Migrating From Mirroring to an Availability Group

• Pick the right edition path. On Enterprise, use a regular availability group. On Standard, use one basic availability group per database; basic AGs support asynchronous commit.
• Build the cluster and quorum first. Apply the vote and witness design above before any database joins the group.
• Plan the cut-over. A database can’t be in a mirroring session and an availability group at the same time. Remove mirroring, then prepare the secondary copy (a restore WITH NORECOVERY or automatic seeding) and join it to the group.
• Copy what lives outside the database. Logins, SQL Server Agent jobs, linked servers and credentials aren’t part of the group. Create them on the DR replica too.
• Change the connection strings. Applications should connect to the listener instead of using Failover Partner. With only two replicas and no readable secondary, Microsoft notes that a mirroring connection string still works temporarily, which can soften the cut-over.
• Watch the queues. In our experience, unmonitored availability group latency is one of the most common problems in environments we take over. Alert on the log send queue and on log usage on the primary; the query in our SQL Server high availability guide is a good starting point.
• Test both failovers. Test a forced failover to DR and the return to the primary site before you rely on the design.

When an Availability Group Isn’t the Answer

If you only need a DR copy and don’t want any cluster dependency, log shipping is still a solid choice. It works without a cluster, supports several secondaries and can delay restores on purpose as a buffer against accidental changes. Failover is manual, just as it is with asynchronous mirroring. Read-scale availability groups also run without a cluster, but Microsoft positions them for read scale-out rather than high availability. For a full comparison of the options, see our SQL Server high availability guide, and for availability group basics, our SQL Server Always On guide.