We're thrilled to share with you the public preview of zone redundancy for Azure SQL Database Hyperscale Named replica. This feature leverages Azure Availability Zones to distribute Named replica compute nodes across different physical locations within an Azure region. By choosing zone redundancy for Named replica, you can enhance the resiliency of your read workload running on Named replica to a wider range of failures, including disastrous datacenter outages, without any modifications of the application logic. For more details, check out Hyperscale zone redundant availability.
Creating a zone redundant Named replica
To enable zone redundancy for Named replica, the primary Hyperscale database must have zone redundancy enabled. For the Hyperscale service tier, zone redundancy support can only be specified during database creation and can't be modified once the resource is provisioned. To create a zone redundant Hyperscale database, see Create a zone-redundant database. A zone redundant Named replica can then be created with the Azure portal, Azure CLI or PowerShell. The Zone redundant Named Replica can be created under same logical server as primary Hyperscale database or on a different logical server than primary Hyperscale database.
Azure portal
If you want to create a Named replica that is zone-redundant, you can refer following steps and image to use Azure portal to do so.
- Go to the Azure portal and select your Hyperscale database.
- Under Data Management, select the Replicas. Select Create replica on the Replicas page.
- Choose Replica Type as Named replica.
- In the Configure database pane, select the option Yes for Would you like to make this database zone redundant?
- Add at least one High-Availability secondary replica to your configuration and select Apply.
- Select the Review + create button and then on the Create button to start the deployment.
CLI
By using the –zone-redundant input parameter in the ‘az sql db replica create’ command, you can create a zone redundant Named replica. For more details on this CLI command, see az sql db replica.
To validate if this property is enabled, you can use the CLI command: 'az sql db show'. For more information, see az sql db show.
Example:
This example assumes that a primary Hyperscale database having zone redundancy is already created.
Create a Named replica contoso_named_replica_db under same logical server as primary Hyperscale database.
az sql db replica create -g ContosoMultiAzRg -n contososDB -s contososervermultiaz --secondary-type named --partner-database contoso_named_replica_db_2 --partner-server contososervermultiaz --service-objective HS_Gen5_2 --ha-replicas 1 -z
To validate if a zone-redundant named replica is created.
az sql db show -g ContosoMultiAzRg -n contosoDB -s contososervermultiaz
PowerShell
The -ZoneRedundant input parameter in ‘New-AzSqlDatabaseSecondary’ can be used to enable zone redundancy for a Named replica. For more information, see New-AzSqlDatabaseSecondary (Az.Sql).
To validate if his property is enabled, you can use PowerShell: ‘Get-AzSqlDatabase’. For more information, see Get-AzSqlDatabase (Az.Sql).
Example:
This example assumes that a primary Hyperscale database having zone redundancy is already created.
Create a named replica – contoso_named_replica_db under same logical server as primary hyperscale database.
New-AzSqlDatabaseSecondary -ServerName contososervermultiaz -DatabaseName contosoDB -PartnerServerName contososervermultiaz -PartnerDatabaseName contoso_named_replica_db -SecondaryType Named -PartnerResourceGroupName ContosoMultiAzRg -ResourceGroupName ContosoMultiAzRg -HighAvailabilityReplicaCount 1 -ZoneRedundant
To validate if named replica is created as zone redundant.
Get-AzSqlDatabase -DatabaseName contoso_named_replica_db -ResourceGroupName ContosoMultiAzRg -ServerName contososervermultiaz
Once a zone redundant Named replica is created, it can also be validated from portal’s Compute + storage blade as shown in below screenshot:
Troubleshooting
- Troubleshooting steps remain the same as the primary zone redundancy feature. Refer article: High availability - Azure SQL Database | Microsoft Learn.
- Ensure at least 1 High Availability secondary replica is specified both in PowerShell and CLI.
CLI example: Below error will pop-up if parameter “ha replicas” is skipped in "az sql db replica create" command:
|
(ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database. Code: ProvisioningDisabled Message: There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database. |
- Hyperscale database should have zone redundancy enabled as a prerequisite to enable this feature for Named replica. It is optional to enable zone redundancy for Named replica even if primary database has it enabled.
CLI example: Below error will pop-up if zone redundancy is not enabled on primary database:
|
(DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant. Code: DatabaseNamedReplicaSourceDatabaseNotZoneRedundant Message: Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant. |
Current Limitation
Zone redundant configuration for a Named replica can only be specified during its creation. This setting cannot be modified once the resource is provisioned. If you wish to configure zone redundancy on an existing Named replica, it can be dropped and recreated. Since Named replica is just a compute node that uses same storage as the primary replica, there is no data copy needed to add a Named replica and its addition or deletion does not impact the primary Hyperscale database.