SQLServerCentral Editorial

Improving Availability Groups

,

Availability Groups (AG) were introduced in SQL Server 2012, with the idea that we could dramatically improve (and ease) the burden of dealing with high availability in SQL Server. At the time the (code named) HADRON technology seemed full of possibilities.  Since then, there have been some enhancements, but it seems that setting up and managing an AG, especially across subnets, isn't as simple as Microsoft would have us believe.

One of the problems with AGs is that there are non database resources (logins, jobs, etc.) that create dependencies. Working around the issues is a headache for many administrators, and it shouldn't be. While there are some enhancements potentially coming, I don't know what shape these will take or if they will make things easier.

Some of my previous work as a DBA relied heavily on SQL Agent and jobs, neither of which are handled by AGs, or by plenty of other HA/DR technologies. Instead, administrators cobble things together, save scripts, and manually repair issues after failover. To me, this is one area that I'd hope Microsoft enhanced for AGs.

Another area is the listener, which seems to be brittle. It works great, or it's a nightmare to get working, without always an easy way to debug. I'd certainly welcome improvements here, including the ability for tooling to support multiple listeners easily.

Many of you work with AGs now, and many more of you may in the future as the need for HA grows all the time for databases. Are there improvements you'd like to see in AGs, or any other SQL Server HA/DR technology? Feel free to leave a comment or submit something to Microsoft.

Rate

5 (1)

You rated this post out of 5. Change rating

Share

Share

Rate

5 (1)

You rated this post out of 5. Change rating