The built-in geo-replication feature has been generally available to SQL Database customers since 2014. During this time one of the most common customer requests has been about supporting transparent failover with automatic activation. Now generally available, auto-failover groups extends geo-replication with the following additional capabilities:
- Geo-replication of a group of databases within a logical server
- Ability to choose manual or automatic failover for a group of databases
- The connection endpoint to the primary databases in the group that doesn’t change after failover
- The connection end-point to the secondary databases in the group that doesn’t change after failover (for read-only workloads)
Geo-replication of a group of databases
A typical cloud application includes multiple databases. You can now use Azure SQL Database API to protect the application by geo-replicating all its databases in one simple step. During an outage, all these databases will failover to the secondary server as a group. The group can include individual databases, elastic pools or a combination of the two. If you are already using geo-replication for your production databases you can create a failover group and add them to it to take advantage of the above benefits at no extra cost. The following diagram shows this experience in Azure Portal.
Connection endpoints
You no longer need to worry about changing SQL connection string after failover. Each auto-failover group includes two connection endpoints. The read-write endpoint is a DNS name that will always point to the primary database and will automatically switch during failover. The read-only endpoint is a DNS name that points to the secondary server and allows using the secondary databases to load balance the read-only workloads.
