I am not sure if many of my readers are aware but I am a fan of the work that Davide Mauri, and his team at Microsoft do on the Azure SQL Hyperscale team. I have had the pleasure of working with Davide through the MVP program and he is truly one of the more beautiful minds at Microsoft. Therefore, I am always excited when his team releases a new feature.
On January 5th they announced, auto-failover groups for Azure SQL Hyperscale are now available in preview. Auto-failover groups is a feature that allows you to manage the failover and replication of a group of databases on a server or managed instance from one region to another region in Azure. This can be done manually or in conjunction with a user-defined policy. The nice thing about using the user-defined policy is that it allows you to automatically recover related databases in the secondary region after a failure or event that results in the full or partial loss of data in either a SQL Database or SQL Managed Instance. Typically, to minimize disruption, application databases will be grouped together and failover together. This is why the addition of the Azure SQL Hyperscale to this offering is so important; it will allow databases that logically, or based on business rules that you would like to run in hyperscale, to be included in failover groups.
In this diagram I got from Emily Lisa’s blog, it outlines how the failover works. You can see the failover of the databases as a failover group. After the failover, the secondary becomes the primary and the DNS record is automatically updated to redirect the endpoints to the new region. This is the read, write and read-only listener. The change to the end points happens in both directions switching the read/write to the new primary and the read-only to the new secondary In Emily’s announcement blog she outlines a quick start for you.
If you want to learn more check out Azure SQL Hyperscale
