Blog Post

Creating and Using Failover Groups in Azure DBaaS – Part 1

,

Introduction

Hello everybody! Welcome back! One of my favorite features in Azure SQL DBaaS is Failover Groups.  I have been working with these since they were in preview and I cannot stress the value of this feature enough!  In my former company, we had 22 web applications that all had connections to various databases.  We had all of our databases configured for Geo-Replication already, but still if we had to failover, we had to update each connection string for the web apps along with others which became a tedious process. In came Failover Groups to the rescue!  With a Failover Group, I was able to create two endpoints that stayed the same no matter which server was primary/secondary.  I liked to think of these as my Availability Group Listeners as they kinda serve the same functionality: Route traffic to a node depending on if its read-only or not.  Best part?  It’s configured through the Azure Portal SO EASILY!  You can use PowerShell as well, but for this blog post, I will walk through the creation via the Portal.  I will make a separate post or attach a script at some point for the PowerShell deployment.

Before we start the configuration portion of this though, let’s take a look at how Microsoft defines what a Failover Group is.  I found this definition here:  “Azure SQL Database auto-failover groups (in-preview) is a SQL Database feature designed to automatically manage geo-replication relationship, connectivity, and failover at scale.”  Sounds pretty interesting, right? Let’s make one!

Configuration/Demo

I will do my best to provide step-by-step instructions, but please feel free to reach out to me if you have any questions. By following the steps below, they should enable you to be able to create your first Failover Group through the Azure Portal with little to no problems.

First, login to the Azure Portal and go to the instance you want to start as Primary.  I will be using FlippityFloppity as my Primary server.

Once you have your Primary server selected, scroll down until you reach the “Settings” section, and select “Failover Groups”.

Once you select “Failover Groups” the right side should display something like this if you have no Failover Groups configured yet:

When you are ready to configure the group, click the ” + Add group” button at the top of the window.

Once you do this, you will get a setup dialog box similar to this one.  The one below is filled out already just to save space on the blog post, but each setting is described below the picture.

Settings Descriptions:

  1. Failover Group Name:  This is the name that you designate for your failover group.  Also, this name will be incorporated into the DNS address for the group, so choose wisely.  It MUST be lowercase. I chose “flopsfailover” for mine since this is my personal environment. 
  2. Secondary Server: This is the secondary server for the Failover Group.  This server will be the Read-Only replica for my group. If you do not have a server created, you can make one right through this wizard, when you click on Secondary Server, you will see a list of servers that are available, or you can create a new one.  Once it is created, it will auto-populate the name as the Secondary Server.
  3. Read/Write Failover Policy: By default, Automatic is selected, this means that as soon as a failure is detected the Failover group will initiate a failover to the Secondary (floppityflippity) server.  You can set this to Manual, but I would not recommend it.  This would require you to connect to the Failover Group either through the Azure Portal, or PowerShell and initiate the failover when the problem has already impacted your business.  Now, even if you choose Automatic, you CAN still initiate a Manual failover, so I normally just leave it at Automatic.
  4. Read/Write Grace Period(hours): Since the Failover Group is configured with asynchronous replication, the failover to your secondary *might* incur some data loss. What this setting will control is how long it will wait before Azure initiates the failover that could result in the loss of some data.  By default, it is set for 1 hour, but can be configured for up to 24 hours.
  5. Databases within the group: Select any databases that you would like to be in this Failover Group. This is one of those settings that is a bit different if you have worked with the Azure Portal before.  The Failover Group is a server configuration, but requires the database resource as well.  Usually it’s one or the other, like when you set up Geo-Replication, it is a database level configuration.

There is a GREAT article here that describes these settings in a deeper way and before creating your Failover Group I would suggest reading it over to make sure you have a better technical explanation that I gave above: Failover Group Documentation.

So, once you have the information filled out, go ahead and click the Create button in the lower right hand corner.  This will begin the creation of the Failover Group(DNS entries/Backing up and restoring database to secondary).  Once it is finished, you should see the Failover Group if you click on Failover Groups again under your Primary Server.

Now, go ahead and click on your new Failover Group, and look at the magic inside! In the interest of keeping the image smaller, I did not include the world map, but one of the first things you will notice is a world map that shows you the geographic locations of your two servers.  If you scroll that down, you will see settings similar to what is below:

So, on here, you will see what server is currently Primary, and what is currently Secondary.  With my configuration, flippityfloppity is currently Primary, and floppityflippity is currently Secondary.  You also see your “Read/Write listener endpoint”, and your “Read-Only listener endpoint”.  These are connections that you should use for any application connection strings, but with one additional piece explained below.  Alot of my clients use their secondaries for reporting purposes so after we configure the Failover Group I supply them with the Read-Only connection string to use for their reporting tool.

Summary

As you can see, the initial setup and configuration of your Failover Group is super easy with the Azure Portal.  See part 2 for how to connect and use your Failover Group!

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating