Monitoring Always On Availability Groups with SQLDocKit

In this article, we’re going to discuss Always On availability groups: what they are and why it’s important to monitor them if they are set up in your environment.

They’ve become increasingly popular since the release of SQL Server 2016 because they now offer greater performance and stability.

When Always On technology was introduced with SQL Server 2012, DBAs needed a solution that would let them monitor Always On availability groups from one central console.

The Always On availability groups feature is a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring. It’s a technology that’s based on the Failover Cluster.

An availability group supports a failover environment. This means that availability groups act as a backup solution for an SQL Server environment, sort of like a synchronized secondary system that automatically takes over the primary node in case the primary system fails, stops, goes offline, or becomes unavailable.

Basically, you have one main server and, in the background, you have a node that replicates the main server in case it goes down. This is an excellent solution allowing end users to continue using the server without data loss, even if it went down.

You can also manually perform a failover, and the best thing about Always On availability groups is that you don’t have to bother anymore with adjusting your applications to work with Always On. It’s an out-of -the-box thing. Now, all you need to do is use the SQL connection string and then Always On will take care of the data, replication, uptime, and everything else automatically in the background.

Document Always On availability group status

So, if you’re a DBA and you have set up a failover environment using Always On, you need to monitor it to ensure nodes are running and performing optimally. Of course, just because the nodes took over and your end users haven’t even noticed the switch, that doesn’t mean you shouldn’t check what the heck is going on and find out why the nodes took over.

The most important thing to be aware of is the status of your availability groups, replicas, listeners, and availability databases, as well as the synchronizations states and database synchronization health.

Keep track of your Always On availability groups with SQLDocKit

Now, without a third-party console from which to monitor Always On availability groups, you end up wasting hundreds of man hours clicking here and there and everywhere to gather information about your availability groups. As you might figure, no one likes to do that.

That’s why, at the SQLDocKit headquarters, we’ve decided to implement SQLDocKit with a group of reports containing information about replicas: Which replica is primary and which is secondary? Have the failover settings been adjusted to automatic or manual? Which availability mode is being used? Is the operational state online? All these questions answered and more.

Download a full-featured 30-day trial, fire up SQLDocKit, and then navigate to the Security Management section to see detailed information on:

  • Group
  • Server name, failure condition level, backup preference, synchronization health, check timeout (ms), is basic, supports DTC, Db failover, is distributed.
  • Replicas
  • Group name, server, role (primary or secondary), operational state, synchronization health, availability mode, failover mode, timeout, primary connections, secondary connections, backup priority, create date, modify date, seeding mode, end point URL, last error, last error timestamp.
  • Databases
  • Group name, replica name, name, synchronization state, synchronization health, database state, is suspended, suspend reason, primary replica.
  • Listeners
  • Group, name, port, IP address, state, subnet, is conformant.

P.S. Though Always On acts as a disaster-recovery solution, this should by no means be your only and primary backup solution; it’s still prone to attacks and data tampering. For instance, if something is deleted on the primary server, it will also be deleted on the replica. You must secure a proper database backup, stored in a separate location.