One of the really great things about Azure is the capability to easily create servers in other data centers, in other parts of the country or world (referred to as “regions” in Azure). Couple that with SQL Server’s Always On Availability Groups, and you’ve got the ingredients for a good disaster recovery setup. And that’s exactly what we did as part of our Azure SQL Server 2017 Migration.
What Are Azure Regions?
An Azure Region is a reference to a set of data centers at a specific location. For example, current regions include Eastern US, North Europe, and South India. Each region has multiple layers of redundancy built in, at both the data center and region level. At the time of this writing, Azure has 52 regions worldwide, available in 140 countries, and they are regularly adding more.
How Do I Create Availability Group Nodes Across Multiple Azure Regions?
Adding an Availability Group node from a different region is not much different than setting up your initial Availability Group. I would recommend that you first get your “single-region” Availability Group up and running correctly, then add the node from a different region. If you need help initially setting up an Availability Group in Azure, here are some tutorials:
- Automatically create an availability group from a template
- Configure Always On Availability Group in Azure VM manually
- Check my Notes From A SQL 2017 Azure Install series to see issues I ran in to
Once you have your initial Availability Group set up, adding a new node from a different region is pretty straight forward, and is mostly just a repeat of some of the steps taken to get the initial AG up. Thankfully, Microsoft has a tutorial for that as well:
Following this tutorial was pretty straight forward, and I didn’t run into any issues getting the secondary region added to my Availability Group.
This post is part of an ongoing series of blog posts related to my Azure SQL Server 2017 Migration.