Dbvisit Standby version 9.0.02 included the much anticipated Automatic Failover feature. To achieve this functionality, a new component called the Dbvisit Observer was introduced. This week I’m going to discuss this new feature.
The idea behind Automatic Failover is to have this component, the Observer, configured to monitor an existing Primary and Standby configuration (DDC) based on certain checks. Once the criteria for these checks are not met, this option allows you to automatically activate the Standby database or just send notifications without activating the Standby database.
As with all new features, it is important to pay attention to the system requirements before attempting to configure it. There are also a couple of important notes which you have to be aware of:
- The Observer can be installed either on its own or together with any of the other Dbvisit components, but it is recommended to run the Observer and the Central Console on the same host.
- The Observer should always run.
- The Observer initiates all communication with the Dbvagent, no information gets pushed back from the Dbvagent to the Observer.
- The Central Console initiates all communication with the Observer, no information gets pushed back from the Observer to the Central Console.
As mentioned earlier, certain checks are performed, and based on the outcome, pre-defined rule priorities will tell the Observer what action to take.
There are 2 main sets of checks that can be performed.
System Check, also known as the Observer check
These are mainly Database connectivity checks which validate that the Primary database is in open read/write state and the Standby database is in read-only or recovery mode.
User Check, also knowns as User Script check
Here we give you the option to add your own checks using a user script which includes specific exit status codes : 0 = all is ok, 1 = warning, 2 = error.
Exit code 2, indicates that your custom check failed, and depending on your specified rule set, the required action should be taken.
Let’s briefly look at Rule Priority. Checks can be combined in the following ways by using the Rule Priority dropdown setting on the "Advanced Settings" screen:
Here is a brief description of the Rule Priority options:
- Observer: only executes the Observer check
- User Script: will execute the Observer check as well as the User Script Check
- Either: if either the Observer Check or the User Script Check fails, automatic failover will be initiated.
- Both: if both the Observer Check and the User Script Check fails, automatic failover will be initiated.
Last but not least, we also allow you to configure notifications via Email or Slack, which will inform you about any failure events on a DDC or configuration, which is monitored by the Observer.
I’m going to demonstrate Automatic Failover in the following 2 videos:
Part 1
I will demonstrate how to install the Observer component and start the Observer process:
Part 2
I will demonstrate how to configure the Observer monitoring and create an event which will initiate an Automatic Failover:
As you can see it’s really not that difficult to configure Dbvisit Standby’s Automatic Failover. The key here is to test it properly before putting it in Production. Make use of “Manual Mode” till you are 200% satisfied with the results, because the last thing you want is for an Automatic Failover to be initiated on a false alarm.
I hope you find this video blog helpful and look forward to bringing you the next instalment in this series.
Back to Blog
