14.3 Failover Groups

Failover Group Architecture

A failover group is a logical container that wraps one or more databases on an Azure SQL Database logical server (or a pair of SQL Managed Instances) and exposes them to clients through two stable listener endpoints. The underlying replication is active geo-replication, so each database in the group has a readable asynchronous secondary in the partner region. What the group layer adds on top is:

• A read-write listener endpoint (e.g. myfog.database.windows.net) that always points at the current primary. Clients connect to the listener, not to a server, and stay connected through failover with only a brief connection drop.
• A read-only listener endpoint (e.g. myfog.secondary.database.windows.net) that points at the secondary region, used by ApplicationIntent=ReadOnly workloads for read scale-out.
• Atomic, multi-database failover as a unit: every database in the group fails over together, so cross-database transactions within the group stay consistent.
• An automatic failover policy with a configurable grace period and manual override.

The big exam contrast to internalize: active geo-replication is per-database, manually failed over, no listener; failover groups are per-server-group, listener-backed, automatically or manually failed over as a unit. Choosing one over the other is a frequent scenario question - if the scenario needs automatic failover or multi-database consistency, the answer is a failover group; if it needs fine-grained per-database control and the application can tolerate manual redirection, active geo-replication alone suffices.

Automatic Failover Policy and Grace Period

The group's grace period (default 1 hour, configurable) is how long the platform waits after detecting a primary outage before initiating automatic failover, provided the secondary is healthy. The grace period guards against transient network blips and rolling Azure updates that would otherwise cause unnecessary failovers. You can also set manual override to disable automatic failover and retain only manual control, which is appropriate when an application prefers manual coordination over automated regional switchover.

Automatic failover triggers only when all of the group's geo-replication links are healthy at the moment of evaluation - if any database in the group is in a seeding or suspended state, the group will not fail over automatically, because failing over a partially-seeded group would break consistency. Monitoring and alerting on each link's lag is essential so an unhealthy link surfaces before an outage forces a bad automatic-failover decision.

Read-Scale Secondary

The failover group's read-only listener enables a read-scale scenario: write workloads hit the read-write listener on the primary region, and read-only workloads hit the read-only listener on the secondary region, all through stable endpoints. Because the listener endpoint is stable, you do not need to change connection strings when the primary region fails over - the listener simply resolves to the new primary. This is the central operational benefit over bare active geo-replication.

Configuring Failover Groups

Configuration paths mirror active geo-replication: Azure portal (server -> Failover groups -> Add group, select partner region, databases, grace period), PowerShell (New-AzSqlDatabaseFailoverGroup, Set-AzSqlDatabaseFailoverGroup, Add-AzSqlDatabaseToFailoverGroup), and Azure CLI (az sql failover-group create, az sql failover-group update, az sql db update --failover-group). You can also use T-SQL on the primary server to add databases to an existing group:

ALTER DATABASE [Sales] ADD TO FAILOVER GROUP [myfog];

Removing a database is symmetric (DROP FROM FAILOVER GROUP), and the group can be deleted, which severs the geo-replication links. The number of databases per group is bounded by the logical server's limits (you can add any database on the server that is in a supported tier; Basic-tier databases are not eligible).

Failover Groups on SQL Managed Instance

On SQL Managed Instance, a failover group spans two managed instances rather than two logical servers, and adds network and DNS prerequisites:

• The two MIs must reside in different Azure regions and peer their VNets (or use global virtual network peering) so the instances can communicate over the replication channel.
• The instances must be configured with a partner resource group relationship - the secondary MI is created in the partner region's resource group.
• DNS must resolve each instance's fully qualified domain name from the other instance; you typically configure a custom private DNS zone linked to both VNets, or use the auto-generated DNS resolution.
• The primary and secondary MIs must have compatible hardware generations and service tiers; the secondary's compute should match or exceed the primary to support failover without capacity loss.

The listener endpoints for an MI failover group resolve through the same ...database.windows.net style addresses, and clients connect exactly as on Azure SQL Database. The exam often tests the VNet peering and DNS prerequisites - an MI failover group simply does not work without them.

Failover Modes: Planned vs Forced

Planned failover (Invoke-AzSqlDatabaseFailoverGroupFailover, or the portal's Failover button) reverses the primary and secondary roles cleanly: the secondary catches up, the roles swap, the listener endpoints resolve to the new primary within seconds, and no committed data is lost. Use planned failover for DR drills, planned maintenance, or capacity moves.

Forced failover (-FailoverPolicy set to allow data loss, or ForceFailover flag) is used when the primary region is unreachable; the secondary is promoted without waiting for the primary to catch up, so committed transactions not yet replicated are lost. After the original primary recovers, it re-seeds from the new primary and rejoins as a secondary; you do not have to rebuild it manually, but you must verify data consistency because lost transactions can affect downstream systems.

Failback, Region Pairs, and Monitoring

After failover, failback is simply another planned failover in the reverse direction once the original region recovers and re-seeds; the listener endpoints continue to abstract the change from clients. Region pairs remain the recommended topology because paired regions offer the lowest cross-region latency, coordinated update schedules, and data-residency alignment; using a non-paired region is supported but may add latency and compliance friction.

Monitoring and alerts are critical. Set alerts on:

• Replication lag per database (from sys.dm_geo_replication_link_status) - alert if lag exceeds the RPO objective.
• Failover group state - alert on Failover events and on the group entering Degraded (one or more links unhealthy).
• Grace-period expiry - alert when the grace period starts counting down so operators can decide whether to intervene before automatic failover fires.

Application connection strings should always reference the listener endpoint (read-write listener for writes, read-only listener for read workloads). A classic exam error is hardcoding the primary server's FQDN in the connection string, which defeats the purpose of the failover group and forces manual repointing after every failover. The listener is the abstraction that makes failover transparent to clients; use it.