Multiple secondaries for failover groups is now in public preview

Microsoft

Jan 30, 2026

Failover groups for Azure SQL Database is a business continuity solution that lets you manage the replication and failover of databases to another Azure SQL logical server. With failover groups, you get automatic endpoint redirection, so you don't have to change the connection string for your application after a geo-failover—connections are automatically routed to the current primary. Until now, Azure SQL failover groups have only supported one secondary.

We're excited to announce that Azure SQL Database failover groups support for up to four secondaries is now available in public preview. This enhancement gives you greater flexibility for disaster recovery, regional read scale-out, and complex high-availability scenarios.

What's New?

Create up to four secondaries for each failover group, deployed across the same or different Azure regions.
Use the additional secondaries to add read scale-out capabilities to additional regions, adding flexibility for read-only workloads.
Greater flexibility for disaster recovery planning with multiple failover targets.
Improved resilience by distributing secondaries across multiple geographic regions.
Facilitate migration to another region without sacrificing existing disaster recovery protection.

How to Get Started

Getting started with multiple secondaries in Azure SQL failover groups is straightforward.

In the Azure Portal, the process to create a failover group remains the same. You can add additional secondaries using the process below.

Adding Additional Secondary Servers to a Failover Group in the Portal

Go to your Azure SQL Database logical server in the Azure portal.
Open the "Failover groups" blade under "Data management".
Select an existing failover group.
Click the "Add server" menu item to add additional secondary servers.
A side panel opens displaying the list of secondary servers and a dropdown to select which server should operate as the read-only listener endpoint target. The additional secondary server can be in the same or different Azure region as the primary.

NOTE: The read-only listener endpoint dropdown lists all existing secondary servers as well as the secondary server being added. This allows you to designate which secondary server should receive read-only traffic routed through the `<fog-name>.secondary.database.windows.net` endpoint. However, the server selected as the read-only listener endpoint target should not be in the same region as the primary server if you intend to serve read workloads with that endpoint.

Adding an additional secondary to your failover group and specifying the read-only listener endpoint target

After selecting the additional secondary and specifying your read-only listener endpoint target, click "Select" on the side panel and click "Save" in the main menu to apply your failover group configuration. The additional secondary will be added and seeding of databases in the failover group will begin to that additional secondary. You can modify your read-only listener endpoint target with the "Edit configuration" menu option.

Save the configuration for the failover group with the newly added secondaryDatabases in the failover group will begin seeding to the newly added secondary

TIP: If you want zone redundancy enabled for the secondary databases, ensure that the secondary servers are in regions that support availability zones and configure the zone redundancy setting appropriately.

Using PowerShell

Creating a failover group with multiple secondaries can also be done with PowerShell.

Example - Create a failover group with multiple secondaries:

New-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName "myrg" `
   -ServerName "primaryserver" `
   -PartnerServerName "secondaryserver1" `
   -FailoverGroupName "myfailovergroup" `
   -FailoverPolicy "Manual" `
   -PartnerServerList @("secondary_uri_1", "secondary_uri_2", "secondary_uri_3", "secondary_uri_4") `
   -ReadOnlyEndpointTargetServer "secondary_uri_1"

where "secondary_uri_n" is in the form below and secondaryserver1 is also included in the list
"/subscriptions/your_sub_guid/resourceGroups/your_resource_group/providers/Microsoft.Sql/servers/your_server_name"

Example - Add additional secondary servers to an existing failover group:

Set-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName "myrg" `
   -ServerName "primaryserver" `
   -FailoverGroupName "myfailovergroup" `
   -FailoverPolicy "Manual" `
   -PartnerServerList @("secondary_uri_1", "secondary_uri_2", "secondary_uri_3", "secondary_uri_4") `
   -ReadOnlyEndpointTargetServer "secondary_uri_1"

where "secondary_uri_n" is in the form below and secondaryserver1 is also included in the list
"/subscriptions/your_sub_guid/resourceGroups/your_resource_group/providers/Microsoft.Sql/servers/your_server_name"

Performing a Failover

With multiple secondaries, you can choose which secondary to promote to primary during a failover.

Using the Portal

Navigate to your SQL server's Failover groups blade.
Select the failover group you want to fail over.
In the servers list, locate the secondary server you want to promote.
Click the ellipsis menu (...) next to the server.

Use the ellipsis menu for failover options and to remove a server from the failover group

Select Failover for a planned failover (with full data synchronization) or Forced failover for an unplanned failover (potential data loss).

TIP: The ellipsis menu also includes a Remove server option, allowing you to remove a secondary server from the failover group.

Using PowerShell

For PowerShell, use the `Switch-AzSqlDatabaseFailoverGroup` cmdlet to perform a failover.

Example:

Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName "myrg" `
   -ServerName "secondaryserver1" `
   -FailoverGroupName "myfailovergroup"

Key Benefits

Enhanced Disaster Recovery - Multiple geo-secondaries provide additional failover targets, reducing the risk of total service disruption.
Regional Read Scale-Out - Distribute read-only workloads across multiple regions.
Flexible HA/DR Architecture - Design your high-availability architecture based on your specific business requirements.
Ease migrations to another region - Leverage the additional secondary to migrate to a different Azure region while maintaining DR protection.

Limitations & Notes

You can create up to four secondaries per failover group.
Each secondary must be hosted on a different logical server from the primary.
Secondary servers can be in the same region as the primary or in different regions.
The read-only listener endpoint target must be in a different region from the primary if you want to make use of the read-only listener for read workloads.
The failover group name must be globally unique within the `.database.windows.net` domain.
Chaining (creating a geo-replica of a geo-replica) is not supported.
Secondary databases in a failover group inherit the backup storage redundancy and zone redundancy configuration from the primary, depending on the service tier.
For non-Hyperscale databases: Secondary databases will not have high availability (zone redundancy) enabled by default. Enable it after the failover group is created.
For Hyperscale databases: Secondary databases inherit the high availability settings from their respective primary databases.

Best Practices

Use paired regions when possible—failover groups in paired regions have better performance compared to unpaired regions.
Test your failover procedures regularly using planned failovers to ensure your disaster recovery plan works as expected.
Monitor replication lag using `sys.dm_geo_replication_link_status` or the Replication Lag metric in Azure Monitor to ensure your secondaries are synchronized.
Consider your RTO and RPO requirements when designing your failover group architecture.
Use the read-write listener (`<fog-name>.database.windows.net`) for write workloads and the read-only listener (`<fog-name>.secondary.database.windows.net`) for read workloads to take advantage of the automatic endpoint redirection after failovers.
Use customer-managed failover group policy to ensure your RTO and RPO are in your control.

Frequently Asked Questions

What services tiers are supported for multiple secondaries in failover group?

The following service tiers are supported:
- Standard
- General Purpose
- Premium
- Business Critical
- Hyperscale
When there is more than one secondary, how does read only endpoint work?

While creating a failover group with more than one secondary you must designate one of the secondaries as the read only endpoint target. All read only connections will be routed to the designated secondary.

If a failover group is created with just one secondary, then the read only endpoint will default to the only available secondary.
If I have created multiple secondaries for failover group, can I update the read only endpoint at any time?

Yes, you can "Edit configuration" in the portal or use PowerShell to change the read-only listener endpoint target.
How does Auto DR work when multiple secondaries exist for a failover group?

The primary server (read write endpoint) and secondary server (designated as read only endpoint) will be used as a pair for Auto DR failover and endpoints will be swapped upon failover.