Azure SQL Database Failover Groups with Multiple Secondaries

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

Azure SQL failover groups are Microsoft’s managed solution for replicating and failing over databases to another Azure region for disaster recovery and high availability.
https://learn.microsoft.com/azure/azure-sql/database/failover-group-sql-db

Until recently, each failover group could have only one secondary server. That limitation restricted regional read scale-out and flexible disaster recovery planning. Now, though still in public preview, Azure SQL Database failover groups support up to four secondary servers, letting you scale reads across regions and build more resilient architectures.
https://techcommunity.microsoft.com/blog/azuresqlblog/multiple-secondaries-for-failover-groups-is-now-in-public-preview/4489005

This post breaks down what’s new, how to set it up using Azure Portal and PowerShell, how to perform failovers, and best practices from beginner to advanced users.


Introduction: Failover Groups in Azure SQL

When running mission-critical applications in the cloud, you need both failover protection and the ability to offload read workloads. Azure SQL failover groups accomplish both at the logical server level.
https://learn.microsoft.com/azure/azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview

They automatically:

  • Replicate databases from a primary to one or more secondary servers
  • Provide automatic endpoint redirection when a failover occurs, so connections don’t break

With multiple secondaries, you get greater flexibility for disaster recovery (DR), regional read scale-out, and cloud-native migration patterns.
https://learn.microsoft.com/azure/azure-sql/database/failover-group-sql-db


What’s Changed: Support for Up to Four Secondaries

This preview feature introduces several enhancements.

Multiple Secondaries per Failover Group

You can now add up to four secondary logical servers to each failover group. Those secondaries can live in the same region as the primary or in different regions. Each has its own geo-replication link to the primary.
https://learn.microsoft.com/azure/azure-sql/database/failover-group-sql-db

Read Scale-Out Across Regions

By designating one of the secondaries as the read-only listener endpoint target, you can route read-only traffic to that server. That gives you global read scale-out and helps isolate read workloads from write workloads.
https://learn.microsoft.com/azure/azure-sql/database/read-scale-out

Better DR and Migration Flexibility

Multiple secondaries let you plan failovers to different regions and maintain disaster recovery protection while migrating workloads.
https://techcommunity.microsoft.com/blog/azuresqlblog/multiple-secondaries-for-failover-groups-is-now-in-public-preview/4489005

Improved Geographic Resilience

You can distribute replicas across geographic pairs to reduce risk of regional outages affecting all nodes.
https://learn.microsoft.com/azure/azure-sql/database/failover-group-sql-db

Important Preview Note

Because this support is still a public preview, it’s not recommended for production workloads yet.
https://learn.microsoft.com/azure/azure-sql/database/failover-group-sql-db


Getting Started: Portal and PowerShell Deep Dive

Beginner: Azure Portal Steps

This section walks you through adding additional secondaries in the Azure Portal.

  1. Open the Azure Portal and navigate to your Azure SQL logical server.
  2. Select Failover groups under Data management.
  3. Pick the failover group you want to enhance.
  4. Click Add server to include an additional secondary.
  5. In the side panel, pick the secondary server and choose which should be the read-only listener endpoint target. For read workloads, this should be in a different region than the primary.
    https://techcommunity.microsoft.com/blog/azuresqlblog/multiple-secondaries-for-failover-groups-is-now-in-public-preview/4489005
  6. Save your configuration. Azure begins seeding the databases to the new secondary.

Beginner Tip
If you want zone redundancy, make sure the target regions support availability zones and configure that in your server settings.
https://learn.microsoft.com/azure/azure-sql/database/high-availability-sla


Intermediate: PowerShell Examples

Here’s how you can manage failover groups programmatically.

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"

Replace secondary_uri_n with the full Azure resource path of each secondary server.
https://learn.microsoft.com/powershell/module/az.sql/new-azsqldatabasefailovergroup


Add secondaries to an existing 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"

This command updates the failover group with additional secondaries and reconfigures the read-only endpoint target just like the portal UI.
https://learn.microsoft.com/powershell/module/az.sql/set-azsqldatabasefailovergroup


Performing a Failover

With multiple secondaries, you can pick which one becomes primary when a failover happens.

Using the Azure Portal

  1. Go to the Failover groups blade.
  2. Select the failover group and locate the secondary server you want to promote.
  3. Use the ellipsis menu to choose Failover for a planned failover or Forced failover for an unplanned failover with potential data loss.
    https://learn.microsoft.com/azure/azure-sql/database/failover-group-sql-db

Using PowerShell

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

Best Practices (Beginner to Advanced)


Limitations to Keep in Mind

  • A maximum of four secondary servers per failover group.
  • Secondary servers must be on different logical servers.
  • The read-only listener must be in a different region from the primary to serve read workloads.
  • Chaining geo-replicas is not supported.

Final Thoughts

Support for multiple secondaries in Azure SQL failover groups marks a meaningful step forward for cloud disaster recovery and global read scale-out. Whether you are a developer, database administrator, or solution architect, these enhancements provide more control, flexibility, and resilience when building modern Azure workloads.

Because this is a public preview feature, it should be tested thoroughly before production use. Always follow Azure best practices for disaster recovery and high availability.
https://learn.microsoft.com/azure/azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview


References

Microsoft Azure SQL Tech Community Blog
https://techcommunity.microsoft.com/blog/azuresqlblog/multiple-secondaries-for-failover-groups-is-now-in-public-preview/4489005

Microsoft Learn – Failover Groups for Azure SQL Database
https://learn.microsoft.com/azure/azure-sql/database/failover-group-sql-db

Microsoft Learn – Business Continuity in Azure SQL Database
https://learn.microsoft.com/azure/azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview

Microsoft Learn – Read Scale-Out in Azure SQL Database
https://learn.microsoft.com/azure/azure-sql/database/read-scale-out


Discover more from SQLYARD

Subscribe to get the latest posts sent to your email.

Leave a Reply

Discover more from SQLYARD

Subscribe now to keep reading and get access to the full archive.

Continue reading