Azure SQL Database Failover Groups with Multiple Secondaries Public Preview

What’s New, Why It Matters, and How to Use It

---

Failover Groups in Azure SQL

Azure SQL failover groups are Microsoft’s managed solution for replicating and automatically failing over databases to another Azure region. They operate at the logical server level and provide two key benefits: automatic geo-replication of all databases in the group, and automatic endpoint redirection after failover so applications do not need connection string changes.

Until recently, each failover group supported only one secondary server. That limitation restricted both regional read scale-out and flexible disaster recovery planning. Multiple secondaries — now in public preview — changes that significantly.

What Changed: Up to Four Secondaries

Each secondary server maintains its own independent geo-replication link to the primary. Secondaries can be in the same region as the primary or in different regions. This enables more resilient DR architectures, compliance-driven geo-distribution, and complex migration patterns where existing DR protection needs to remain in place while moving to a new primary region.

Architecture and Listener Endpoints

Failover groups expose two stable DNS-based listener endpoints. These CNAME records are created when the failover group is created and automatically redirect after failover without any connection string changes in your application.

With multiple secondaries, you designate exactly one secondary as the read-only listener target. All read-only listener traffic routes to that one server. To use the read-only listener for actual read workloads, always include ApplicationIntent=ReadOnly in your connection string — Azure SQL uses this hint to route connections correctly.

-- Connection string for read-only workloads via the read-only listener
-- Always include ApplicationIntent=ReadOnly
Server=tcp:myfailovergroup.secondary.database.windows.net,1433;
Database=myDatabase;
Authentication=Active Directory Default;
ApplicationIntent=ReadOnly;

Prerequisites and Tier Requirements

Not all Azure SQL Database configurations support failover groups with multiple secondaries. Confirm these requirements before configuring:

Requirement	Detail
Service tier	Standard S3 or above, General Purpose, Premium, Business Critical, or Hyperscale
Failover group name	Must be globally unique within .database.windows.net
Secondary servers	Each secondary must be on a different logical server than the primary
Same tenant	Failover groups can only be created between logical servers in the same Microsoft Entra tenant
Different regions for standard FG	Traditional single-secondary failover groups require different regions. Multiple secondaries can be same or different region.
Zone redundancy (non-Hyperscale)	Not enabled by default on secondaries — must be enabled after creation if required
Zone redundancy (Hyperscale)	Secondaries inherit HA settings from their respective primaries
Preview status	Not recommended for production workloads as of April 2026

Portal Setup: Adding Multiple Secondaries

The initial failover group creation process is unchanged. To add additional secondaries to an existing group:

PowerShell Setup

Use Azure PowerShell to manage failover groups programmatically — useful for automation, infrastructure-as-code, and CI/CD pipelines.

Create a New Failover Group with Multiple Secondaries

# Create a new failover group and specify all secondaries at creation time
# Replace resource paths with your actual subscription, resource group, and server names
$primaryServer    = "primary-sql-server"
$resourceGroup    = "my-resource-group"
$fogName          = "my-failover-group"

# Full Azure resource paths for each secondary server
$secondary1 = "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Sql/servers/secondary-server-1"
$secondary2 = "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Sql/servers/secondary-server-2"
$secondary3 = "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Sql/servers/secondary-server-3"

New-AzSqlDatabaseFailoverGroup `
    -ResourceGroupName    $resourceGroup `
    -ServerName           $primaryServer `
    -FailoverGroupName    $fogName `
    -FailoverPolicy       "Automatic" `
    -GracePeriodWithDataLossHours 1 `
    -PartnerServerList    @($secondary1, $secondary2, $secondary3) `
    -ReadOnlyEndpointTargetServer $secondary1

Add Secondaries to an Existing Group

# Update an existing failover group with additional secondaries
Set-AzSqlDatabaseFailoverGroup `
    -ResourceGroupName    $resourceGroup `
    -ServerName           $primaryServer `
    -FailoverGroupName    $fogName `
    -FailoverPolicy       "Automatic" `
    -GracePeriodWithDataLossHours 1 `
    -PartnerServerList    @($secondary1, $secondary2, $secondary3) `
    -ReadOnlyEndpointTargetServer $secondary1

Verify the Failover Group Configuration

# View current failover group configuration including all secondaries
Get-AzSqlDatabaseFailoverGroup `
    -ResourceGroupName $resourceGroup `
    -ServerName        $primaryServer `
    -FailoverGroupName $fogName |
Select-Object FailoverGroupName, ReplicationRole, PartnerServers, ReadOnlyEndpoint

Performing a Failover

With multiple secondaries, you choose which one becomes the new primary when a failover is performed. Both planned and forced failovers are supported.

Planned Failover (Portal)

Go to the Failover groups blade, select your group, locate the secondary server you want to promote, and use the ellipsis menu to choose Failover. A planned failover ensures all committed transactions are synchronized before the switch — zero data loss.

Forced Failover (Portal)

Use Forced failover when the primary is unavailable and you need to promote a secondary immediately. Forced failovers may result in data loss for transactions not yet replicated to the target secondary.

Failover via PowerShell

# Planned failover — promote secondary-server-1 to primary
# Run this command from the secondary server you want to promote
Switch-AzSqlDatabaseFailoverGroup `
    -ResourceGroupName $resourceGroup `
    -ServerName        "secondary-server-1" `
    -FailoverGroupName $fogName

# Verify the role has changed
Get-AzSqlDatabaseFailoverGroup `
    -ResourceGroupName $resourceGroup `
    -ServerName        "secondary-server-1" `
    -FailoverGroupName $fogName |
Select-Object FailoverGroupName, ReplicationRole

Monitoring Replication Health

Monitor geo-replication status across all secondaries to ensure your DR protection is healthy before a real incident occurs.

-- Check geo-replication link status for all secondaries
-- Run on the primary server
SELECT
    link_guid,
    partner_server,
    partner_database,
    replication_state_desc,
    role_desc,
    replication_lag_sec,
    last_replication
FROM sys.dm_geo_replication_link_status
ORDER BY partner_server;

-- Healthy state: replication_state_desc = 'CATCH_UP' or 'SEEDING'
-- replication_lag_sec should be low (seconds to low minutes)

-- Monitor active seeding progress (when adding a new secondary)
SELECT
    link_guid,
    partner_server,
    seeding_state_desc,
    transfer_rate_bytes_per_second,
    transferred_size_bytes,
    database_size_bytes,
    CAST(transferred_size_bytes * 100.0 / NULLIF(database_size_bytes,0) AS DECIMAL(5,1))
        AS pct_complete
FROM sys.dm_database_replication_links
WHERE seeding_state_desc != 'COMPLETE'
ORDER BY partner_server;

Limitations

• Maximum of four secondary servers per failover group
• Each secondary must be on a different logical server than the primary
• The read-only listener target must be in a different region from the primary to properly serve read-only workloads
• Chaining geo-replicas is not supported — you cannot create a geo-replica of a geo-replica
• Zone redundancy is not enabled by default on non-Hyperscale secondaries — must be configured after creation if required
• Failover groups cannot be renamed after creation
• Failover groups can only be created between servers in the same Microsoft Entra tenant
• Databases must be at Standard S3 tier or above, or General Purpose tier or above
• Multiple secondaries feature is in Public Preview — not recommended for production workloads

Best Practices

• Use Azure paired regions for your DR secondary — failover groups in paired regions have better replication performance than unpaired regions
• Always use the listener endpoints in connection strings, never the server names directly — endpoints auto-redirect after failover
• Include ApplicationIntent=ReadOnly in connection strings for any workload using the read-only listener endpoint
• Test planned failovers regularly in non-production — failovers should be practiced before you need them in an emergency
• Monitor sys.dm_geo_replication_link_status or Azure Monitor alerts for replication lag across all secondaries
• Design your RTO and RPO requirements before choosing which secondaries to designate for DR vs read scale-out
• Enable zone redundancy on secondaries explicitly after creation for non-Hyperscale tiers — it is not inherited automatically
• Scale geo-secondaries up before scaling the primary, and scale the primary down first when scaling down — this prevents reseeding
• Use paired regions and different maintenance window schedules for primary and secondary when in unpaired regions

Final Thoughts

Support for multiple secondaries in Azure SQL Database failover groups is a meaningful architectural improvement for cloud disaster recovery and global read scale-out. It gives database administrators and solution architects more flexibility to match failover group topology to real business requirements — multiple failover targets, regional read distribution, and complex migration patterns are all now possible within a single failover group.

References

• Azure SQL Blog – Multiple Secondaries for Failover Groups Now in Public Preview
• Microsoft Learn – Failover Groups Overview and Best Practices
• Microsoft Learn – Configure a Failover Group for Azure SQL Database
• Microsoft Learn – Business Continuity in Azure SQL Database
• Microsoft Learn – Read Scale-Out in Azure SQL Database
• Microsoft Learn – New-AzSqlDatabaseFailoverGroup
• Microsoft Learn – Switch-AzSqlDatabaseFailoverGroup
• Microsoft Learn – Azure Cross-Region Replication and Paired Regions