This article is contributed. See the original author and article here.
We are excited to announce the preview release of auto-failover groups for Azure SQL Hyperscale tier. This preview release includes support for forced and planned failover for Azure SQL Hyperscale databases that use active geo-replication and auto-failover groups. Some key benefits of auto-failover groups include:
- Simplified management of a group of geo-replicated databases including ability to failover the entire group of databases.
- Ability for application to maintain the same read/write and read-only endpoints after failover.
- Recovery during loss of an entire region through geo-failover which can be initiated manually or through an automatic failover policy.
- Readable online secondaries that can be used for read-only workloads by connecting with read-only listener endpoints which remain unchanged during geo-failovers.
Hyperscale service tier supports 100 TB of database size, rapid scale (out and up) and nearly instantaneous database backups, removing the limits traditionally seen in cloud databases.
How auto-failover groups work for Hyperscale
Auto-failover groups are created between servers in 2 regions. The groups can include all or some databases in the servers. If a Hyperscale database is selected to be part of the failover group, then this database will failover with the rest of the failover group unit. The following diagram illustrates a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.
Auto-failover groups for Hyperscale will be supported in all regions where Azure SQL Hyperscale is supported.
a. Create an Auto-failover group using Portal.
- Failover groups can be configured at the server level. Select the name of the server under Server name to open the settings for the server.
- Select Failover groups under the Settings pane, and then select Add group to create a new failover group.
- On the Failover Group page, enter or select your desired values for your failover group.
- Add your Hyperscale database to the failover group then select Create.
b. Create an Auto-failover group using PowerShell.
c. Create an Auto-failover group using CLI.
d. Create an Auto-failover group using REST API.
Example 1: Planned failover for an auto-failover group
a. Execute a failover of an auto-failover group in Portal.
1. Select your failover group.
2. Select Failover to initiate failover for your auto-failover group. Once failover is completed you should see that your primary and secondary servers have swapped roles.
b. Execute a failover of an auto-failover group using Switch-AzSqlDatabaseFailoverGroup in PowerShell.
c. Execute a failover of an auto-failover group using az sql failover-group set-primary in CLI.
d. Execute a failover of an auto-failover group using REST API.
Example 2: Forced failover with active geo-replication
a. Execute a failover using Portal.
1. Select the Replicas tab. In the list of geo replicas click the ellipsis for the secondary you would like to become the new primary. Then select Forced failover.
2. You should now see that the primary and secondary have swapped roles.
b. Execute a failover using Set-AzSqlDatabaseSecondary in PowerShell with the -AllowDataLoss parameter specified.
c. Execute a failover using az sql db replica set-primary in CLI with the –allow-data-loss parameter specified.
d. Execute a failover using REST API.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.