SQL Server Always On: Availability Groups and Failover Cluster Instances Explained

“Always On” isn’t one feature. It’s Microsoft’s umbrella name for two different technologies: Always On availability groups (AG), which protect databases by keeping copies on other servers, and Always On failover cluster instances (FCI), which protect a whole SQL Server instance by moving it between cluster nodes. Both keep an application running when a server fails, but they fail over differently, protect different things and fail in different ways.

This guide covers how an availability group moves data, commit modes and failover types, the listener and read-only routing, backups on secondary replicas, what an AG doesn’t copy for you, how FCI works, edition and licensing limits in SQL Server 2025, and the queries to check whether a replica is really ready for failover. If you’re still choosing between high availability options in general, start with our SQL Server high availability guide. This article goes deeper into Always On itself.

Last verified: 19 October 2026. Checked against Microsoft Learn (availability group overview, availability modes, failover and failover modes, flexible failover policy, database-level health detection, readable secondaries, backups on secondary replicas, basic, contained and distributed availability groups, failover cluster instances and SQL Server 2025 editions).

Which One Do You Need? Quick Decision Table

Availability Groups and FCI at a Glance

An availability group works at the database level. A set of user databases fails over together from a primary replica to a secondary replica. Each replica is a separate SQL Server instance with its own storage and its own copy of the data, and the primary ships transaction log records to the secondaries.

A failover cluster instance works at the instance level. There is one copy of the data on shared storage and one SQL Server instance that runs on one cluster node at a time. When that node fails, Windows Server Failover Clustering (WSFC) starts the instance on another node, and the instance comes back with everything it owns: system databases, logins, Agent jobs, linked servers and certificates.

The two can also be combined: an FCI can be a replica in an availability group. A common design uses an FCI for local high availability and an asynchronous AG replica in another data center for disaster recovery.

How an Availability Group Moves Data

Understanding the data flow explains almost every AG symptom you’ll see in production.

1. A transaction on the primary writes log records. When it commits, the log block is flushed to the primary’s transaction log file.
2. The same log block is sent over the database mirroring endpoint (TCP 5022 by default) to every secondary replica.
3. Each secondary writes (“hardens”) the block to its own log file and sends an acknowledgement back.
4. A redo thread on the secondary replays the log records into the data files, so the secondary’s copy of the database catches up.

Two queues come out of this flow, and they’re the most important numbers in any AG:

• Log send queue: log on the primary that hasn’t reached a secondary yet. If the primary is lost now, this is the data you lose. It measures your real RPO.
• Redo queue: log that a secondary has hardened but not yet replayed. On failover the secondary must finish redo before the databases come online. It drives your real RTO.

A secondary with a near-zero send queue but a redo queue of several gigabytes won’t lose data, but failing over to it can take minutes instead of seconds.

Synchronous and Asynchronous Commit

Each replica has an availability mode.

In synchronous commit the primary waits for the secondary to harden the log block before it confirms the commit to the application. Committed transactions exist on both replicas, so a failover to a synchronized secondary loses nothing. The price is latency: every commit pays a network round trip plus a log write on the secondary, which you’ll see as the HADR_SYNC_COMMIT wait type on the primary.

In asynchronous commit the primary commits as soon as its own log flush finishes and sends log to the secondary in the background. Commits are fast regardless of distance, but anything still in the send queue is lost if the primary disappears.

SQL Server 2017 added REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, which forces the primary to wait until at least the given number of synchronous secondaries have hardened each commit. It closes a gap where a primary could keep committing alone after its secondaries dropped out.

Failover Types

An AG can change roles in three ways, and they have very different consequences.

A planned manual failover is always run on the secondary that will become the new primary:

-- Run on the target secondary
ALTER AVAILABILITY GROUP [AG_Sales] FAILOVER;

-- Disaster only: accepts losing whatever the target hadn't received
ALTER AVAILABILITY GROUP [AG_Sales] FORCE_FAILOVER_ALLOW_DATA_LOSS;

Never fail over an AG by moving its cluster role in Failover Cluster Manager. Use T-SQL, SSMS or PowerShell, so SQL Server checks the synchronization state before the switch. The same rule matters during patching, which we cover in our Always On rolling update guide.

What triggers an automatic failover

Automatic failover isn’t triggered by every error. Three settings decide it:

• Lease timeout (20 seconds by default): if SQL Server and the cluster resource DLL can’t renew their lease, the replica is considered unhealthy.
• HEALTH_CHECK_TIMEOUT (30,000 ms by default): how long the cluster waits for sp_server_diagnostics to answer.
• FAILURE_CONDITION_LEVEL (3 by default): which conditions count as failure, from “service is down” (1) up to “moderate server errors” (5). Level 3 covers critical server errors such as orphaned spinlocks and write access violations.

Database-level health detection (DB_FAILOVER = ON, available since SQL Server 2016) adds one more trigger: a failover when a database in the group stops being online, for example after losing a data file. It’s off by default and worth enabling on most new AGs. In SQL Server 2025 you can also set the AG resource’s RestartThreshold to 0, so the cluster fails over immediately on a persistent health issue instead of first trying to restart the resource on the same node.

The Listener and Read-Only Routing

Applications should never connect to a replica’s instance name. The availability group listener is a virtual network name with its own IP address (one per subnet) that always points to the current primary.

Three connection-string settings decide how well applications survive a failover:

• MultiSubnetFailover=True: the client tries all listener IPs in parallel instead of one after another. Use it on every modern driver, even on a single subnet. It shortens reconnect time.
• ApplicationIntent=ReadOnly: tells the listener this session only reads, so it can be routed to a readable secondary.
• Retry logic: in-flight transactions fail during any failover. The application must reconnect and retry.

Readable secondaries

In Enterprise edition a secondary can accept read-only connections (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)). With a routing list, connections that declare ApplicationIntent=ReadOnly and connect through the listener are sent to a secondary automatically.

Offloading reports to a secondary is useful, but it has side effects:

• Queries on a secondary run under snapshot isolation, whatever isolation level they ask for. Row versions are kept in the secondary’s tempdb.
• Enabling readable secondaries adds 14 bytes to modified rows on the primary for row versioning.
• Long-running reports on the secondary can hold back ghost cleanup on the primary and grow the secondary’s tempdb.
• Statistics created on a secondary used to be temporary and disappeared on restart. SQL Server 2025 adds persisted statistics for readable secondaries, and Query Store for secondary replicas is on by default.
• A readable secondary is not a passive replica. It must be fully licensed.

We cover the reporting trade-offs and licensing math in the cost of adding a reporting server.

Backups on Secondary Replicas

Moving backups off the primary is one of the most practical benefits of an AG.

• Up to SQL Server 2022: secondaries support copy-only full backups and regular log backups. Differential backups are only possible on the primary.
• SQL Server 2025: full and differential backups are now supported on any secondary replica, in addition to copy-only backups.
• Log backups taken on any replica form one log chain. Restoring needs all of them, wherever they were taken.
• The secondary must be SYNCHRONIZED or SYNCHRONIZING. A backup on a lagging asynchronous secondary is only as current as that secondary.

The AG’s AUTOMATED_BACKUP_PREFERENCE (PRIMARY, SECONDARY_ONLY, SECONDARY or NONE) and backup priority only express a preference. Your backup jobs must run on every replica and ask SQL Server whether they’re on the preferred one:

IF sys.fn_hadr_backup_is_preferred_replica(N'SalesDB') = 1
BEGIN
    BACKUP LOG [SalesDB]
    TO DISK = N'\\backupshare\sql\SalesDB\SalesDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
END

For the backup side, see our SQL Server backup plan guide.

What an Availability Group Doesn’t Copy

An AG replicates the user databases in the group, nothing else. Everything stored in master and msdb stays on the instance where it was created. After a failover, these are the usual reasons an application “works on the old primary but not on the new one”:

• Logins: SQL logins must exist on every replica with the same SID. Otherwise database users become orphaned after failover. Create them with CREATE LOGIN ... WITH SID = ....
• SQL Server Agent jobs, operators and alerts. Each job also needs to check whether it’s running on the primary, for example with sys.fn_hadr_is_primary_replica.
• Linked servers, credentials and proxies.
• Certificates and keys: a TDE-encrypted database can’t be opened on a replica that doesn’t have the certificate.
• Instance settings: max server memory, MAXDOP, cost threshold, trace flags and Database Mail.
• SSIS packages in SSISDB, unless SSISDB itself is part of the group.

-- Inside an Agent job step: do nothing on a secondary
IF sys.fn_hadr_is_primary_replica(N'SalesDB') <> 1
    RETURN;

-- Compare SQL logins and SIDs across replicas
SELECT name, sid, type_desc, is_disabled
FROM sys.server_principals
WHERE type IN ('S', 'U', 'G')
  AND name NOT LIKE '##%'
ORDER BY name;

Contained availability groups (SQL Server 2022 and later, Enterprise edition) solve most of this. A contained AG has its own master and msdb that fail over with it, so logins, permissions and Agent jobs created through the listener move together. SQL Server 2025 also allows a distributed AG between two contained AGs.

Other Availability Group Topologies

• Distributed availability groups (2016+): an AG made of two AGs, each on its own cluster. It’s used for cross-region DR without stretching one cluster across sites, and for migrations to new hardware or a new version with a short cutover window.
• Read-scale / clusterless AGs (CLUSTER_TYPE = NONE, 2017+): no cluster, no automatic failover. They’re useful for read scale-out and migrations, not for high availability.
• SQL Server on Linux: AGs are managed by Pacemaker (CLUSTER_TYPE = EXTERNAL) instead of WSFC.
• Basic availability groups: the Standard edition variant, covered in the edition section below.

How a Failover Cluster Instance Works

An FCI is a single SQL Server instance installed as a cluster role. Its data and log files live on storage that every node can reach: a SAN, Storage Spaces Direct, cluster shared volumes or an SMB 3 file share. tempdb can be on fast local disk on each node.

When the active node fails, the cluster stops the role, moves the storage and network name, and starts SQL Server on another node. Because this is a service start, every database goes through crash recovery: committed transactions are rolled forward and uncommitted ones rolled back. Failover time is therefore driven by recovery time, and long-running open transactions make it longer. Accelerated database recovery shortens this considerably.

What FCI does well is simplicity for everything above the storage. There are no logins to sync, no jobs to make AG-aware, and no second copy to license or patch differently. What it doesn’t do is protect against storage failure or corruption: there’s only one copy of the data. That’s why critical FCIs are usually paired with an AG replica, log shipping or a backup strategy that lives on separate storage.

Quorum: The Part Most Designs Get Wrong

Both AGs and FCIs on Windows depend on WSFC quorum. The cluster keeps running only while a majority of votes can see each other. This prevents split brain, where two halves of a partitioned cluster each think they own the primary.

• Use an odd number of votes, adding a witness (disk, file share or cloud witness) when the node count is even.
• Dynamic quorum and dynamic witness (Windows Server 2012 R2 and later) adjust votes as nodes go down, which keeps a cluster alive through sequential failures.
• Nodes in a DR site usually get NodeWeight = 0, so a WAN outage can’t take the production site’s cluster down.
• The witness should live in a third location, or in Azure as a cloud witness, not in the same room as one of the nodes.

The classic failure is a two-site cluster where the primary site loses its vote majority over a WAN glitch and the whole cluster, including the healthy primary, goes offline. We explain this trap in detail in async database mirroring vs. async availability groups.

Always On by Edition in SQL Server 2025

A Standard edition server can host several basic AGs, one database each, but they fail over independently. If an application uses three databases that must stay together, basic AGs can’t guarantee that, and an FCI or Enterprise edition may be the better fit. Express edition supports neither AGs nor FCIs.

Licensing Always On

With Software Assurance or subscription licensing, SQL Server 2025 gives free passive replicas for failover: one for high availability, one for disaster recovery and one in Azure for DR. A passive replica can run database consistency checks, log backups, full backups and resource monitoring, and nothing else.

Once a secondary serves reads, reports or any other production work, it’s no longer passive and needs its own licenses, in the same edition as the primary. A readable secondary used for reporting therefore costs as much as a second primary. We explain the rules and the core math in our SQL Server 2025 licensing guide.

Monitoring: Is the Secondary Really Ready?

A green dashboard in SSMS isn’t proof. Run this on the primary to see, for every database and replica, how much data you’d lose and how long recovery would take if you failed over now:

SELECT
    ag.name                              AS ag_name,
    ar.replica_server_name,
    ar.availability_mode_desc,
    DB_NAME(drs.database_id)             AS database_name,
    drs.synchronization_state_desc,
    drs.synchronization_health_desc,
    drs.log_send_queue_size              AS log_send_queue_kb,
    drs.redo_queue_size                  AS redo_queue_kb,
    drs.redo_rate                        AS redo_kb_per_sec,
    drs.last_commit_time,
    drs.is_suspended,
    drs.suspend_reason_desc
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id
JOIN sys.availability_groups   AS ag ON ag.group_id   = drs.group_id
ORDER BY ag.name, ar.replica_server_name, database_name;

What to alert on:

• Any database not SYNCHRONIZED on a synchronous replica, or suspended anywhere.
• A log send queue that keeps growing. On async DR replicas this is your data-loss exposure.
• A redo queue divided by redo rate that exceeds your RTO.
• A gap between last_commit_time on the primary and on a secondary, which is the lag in seconds.
• Cluster events: lost quorum, node down, lease timeouts in the SQL Server error log.
• The transaction log of AG databases growing because a secondary can’t keep up. The log can’t be truncated past what every replica still needs.

Test failover regularly, not only at go-live. A failover drill every quarter, including checking that logins, jobs and linked servers work on the other side, is the only reliable way to know the secondary is usable.

Common Always On Mistakes

• Treating an AG as a backup and skipping restore tests.
• Synchronous commit across a high-latency WAN, then wondering why every insert got slower.
• Applications connecting to instance names instead of the listener, or without MultiSubnetFailover and retry logic.
• Logins with different SIDs on each replica, so users are orphaned after the first failover.
• Agent jobs that run on every replica or only on the original primary.
• A two-node cluster with no witness, or a witness in the same site as one node.
• Moving the AG role in Failover Cluster Manager during patching.
• Using a readable secondary for reports without licensing it.
• Never measuring the redo queue, so a “synchronized” failover takes ten minutes.
• Choosing basic AGs for an application whose databases must fail over together.

Always On Checklist

• RPO and RTO are agreed with the business for each application.
• AG or FCI was chosen for the right level of protection, with DR planned separately.
• Synchronous replicas are on a low-latency network; DR replicas are asynchronous.
• Quorum, witness location and node weights are documented.
• The listener is in use, with MultiSubnetFailover and retry logic in the application.
• Logins (same SIDs), jobs, linked servers, certificates and instance settings exist on every replica.
• Agent jobs check whether they run on the primary.
• Backup jobs run on every replica and respect the backup preference; restores are tested.
• Send queue, redo queue, synchronization state and lag are monitored with alerts.
• Failover is tested on a schedule, including the application side.
• Licensing reflects how each secondary is actually used.

Version and Edition Notes

Official Behavior, Aryasoft Field Notes and Our Recommendation

Sources (Microsoft Learn)

Technical claims in this guide were checked against these primary sources on 19 October 2026. Microsoft can change documentation at any time, so re-check version-specific details before a production change.

• What is an Always On availability group?
• Always On failover cluster instances
• Availability modes
• Failover and failover modes
• Flexible automatic failover policy
• Database-level health detection
• Readable secondary replicas
• Backups on secondary replicas
• Basic availability groups
• Contained availability groups
• Distributed availability groups
• Editions and supported features of SQL Server 2025