Forced Quorum Mode and The Value of Democracy
AlwaysOn Availability Groups can be tricky when it comes to cluster configurations. Learn from a real-life scenario involving DR exercises and quorum failures.
Home »
AlwaysOn
What is not contained in contained Availability Groups
While being an awesome feature introduced in SQL Server 2012, Availability Groups were always missing the ability to synchronize server-level objects between replicas. This finally changed 10 years later, in SQL Server 2022, with the introduction of “Contained Availability Groups”.
Read More »What is not contained in contained Availability Groups
Control SQL Jobs based on HADR Role – Taking it to the Next Level
In one of my previous blog posts, Automatically Enable or Disable Jobs based on HADR Role, I provided a solution for automatically enabling or disabling scheduled jobs in combination with Availability Groups and Database Mirroring. In this blog post, I’m going to build upon my previous solution and improve it even further – taking it to the next level of automation!
Read More »Control SQL Jobs based on HADR Role – Taking it to the Next Level
Eitan Guest-Stars in SQL Server Radio Episodes 111 and 117
Last week, I called up Matan Yungman, and offered to replace Guy Glantser as a co-host in SQL Server Radio, while Guy is away on holiday in New Zealand.
We recorded episode 111 in English, and episode 117 in Hebrew.
Check them out!
Automatically Enable or Disable Jobs Based on HADR Role
Imagine the following: You have a couple or more SQL Servers with some sort of High Availability solution between them (AlwaysOn Availability Groups, Database Mirroring, etc.). You also have a bunch of scheduled jobs which you need to be run on the Primary server.
But wait…. How would you make these jobs run only on the Primary server? After all, if they try to run on the Secondary, they would fail (whether because the database is inaccessible or because it’s read-only). Additionally, you would need to consider the possibility of a failover where the Primary and Secondary servers would switch roles.
This means that you would have to, first, create these jobs on both servers, and implement some sort of mechanism that would detect, for each job, whether the instance it’s being executed at is currently the Primary.
There are a few ways to go about doing this.
[For the sake of this article, let’s ignore the fact that most people don’t even think about it, and leave all of their important jobs on the Primary server only, while ignoring the risks of what would happen when their Primary server crashes and fails over to the Secondary]