Active geo-replication for Azure SQL Hyperscale now in preview
Business continuity is a key requirement to implement any business-critical system, not having a disaster recovery plan in place can put organizations at great financial loss, reputation damage and customer churn.
Active geo-replication is an Azure SQL Database business continuity and disaster recovery feature that allows customer applications to have a disaster recovery strategy and regional resiliency, some of the key benefits include:
We are excited to announce the preview release of Active geo-replication for Azure SQL Database Hyperscale tier. Azure SQL geo-replication feature provides the availability to create a readable secondary database in the same or in different region, in the case of regional disaster, failover to the secondary can initiated to have business continuity.
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 Geo-replication works for Hyperscale?
When creating a geo-replica for Hyperscale, the geo secondary is seeded with data from the primary and is a size of data operation. A geo-replica does not share page servers with the primary, even if they are in the same region. This provides the necessary redundancy for geo-failovers.
Current preview limitations:
We are working on addressing these limitations to have Hyperscale with the same Active geo-replication capabilities that we have for other Azure SQL service tiers including Auto-failover groups support.
In the case you need to make the geo-secondary a primary (writable database), follow the steps below:
1) Break the geo-replication link using the cmdlet Remove-AzSqlDatabaseSecondary in PowerShell or az sql db replica delete link for Azure CLI, this will make the secondary database a read-write standalone database. Any data changes committed to the primary but not yet replicated to the secondary will be lost. These changes could be recovered when the old primary is available, or in some cases by restoring the old primary to the latest available point in time.
2) If the old primary is available, delete it, then set up geo-replication for the new primary (a new secondary will be seeded).
3) Update connection strings in your application accordingly.
Active Geo-replication for Hyperscale will be supported in all regions where Azure SQL Hyperscale is supported.
a. Configure from Portal using the Geo Replication blade
b. Configure using Azure CLI
c. Configure using Powershell
To learn more,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.