Enterprise-class Disaster Recovery for Oracle SE that prioritizes database integrity, disaster resiliency, recovery speed, and ease of use.
Difference between failover vs. switchover
Disaster Recovery (DR) is something that more and more companies are looking at, with data becoming more crucial than ever. But some words are often used when working with databases that some might find confusing.
In this post, we will focus on three of these:
- Switchover (also referred to as role switch)
- Failover (also known as Activation)
- Automatic Failover
It might seem clear what these are for those familiar with them, but it can get confusing for some to see these for the first time. So let’s discuss each one of these in a bit more detail.
Switchover (Role Switch)
When implementing a DR solution, there is always a primary and secondary (standby) site. In some cases, there is more than one secondary site to provide extra protection.
When talking about Switchover, you can see it as a controlled process to change the roles between the primary and secondary (standby) sites. It is done in a controlled manner, and the key is that there is no data loss during this process. Yes, downtime is usually experienced with this process, but it is done during a scheduled, planned amount of time. Therefore, the risk with this process is low and should be tested regularly so that you are familiar with the process and the timing to help with your planning, as you will know exactly how long this process takes.
In Standby™️, we have implemented a process to perform this “Switchover” called “Graceful Switchover (GS).” During this process, the roles of the primary and standby database are interchanged, and the standby database will become the primary, and the original primary will become a standby.
During the switchover operation, there is a small outage. How long the outage lasts depends on several factors, including the network, the number, and the sizes of the database redo logs.
Failover, also referred to by many as Activation of the standby database, is a process when you open the standby database read/write - this can be performed if a disaster has happened.
In this case, your primary database is not accessible to your users or, for some reason, became corrupt, for example, due to a faulty firmware upgrade on the storage or a malicious attack. During this “failover” process, the standby database is opened read/write, changing it to a primary database. Once the standby database is opened read/write, your users (applications) can use it. This process cannot be reversed, so the decision to failover should be carefully made. The failover process is initiated during a real disaster or severe outage.
It is also important to note that there is always the risk of potential data loss during a Failover operation. There is the possibility that changes have not been applied to the standby database yet. Due to the primary system not being available, changes are not applied to the standby database.
It is always important to ensure your standby database is up to date and that the time difference between the primary and standby does not exceed your recovery point and recovery time objectives (RPO and RTO).
Automatic failover is an external process that observes (monitors) the primary and standby configuration, ensuring both systems are running and that a certain set of rules are met. If any of these rules are not met, for example, if the primary is found to be inaccessible (down) for some time, the “observer” process can then perform a failover (activation) of the standby database. All of this is automated; the user will specify rules for the “observer” process to ensure there are no false positives.
Using Automatic Failover is becoming more and more important to companies as it can help reduce downtime by automating processes based on predefined rules.
If you are using the Oracle Database and looking at implementing a DR solution, you can make use of Standby™️, which helps you easily configure and perform tasks such as Graceful Switchover (Switchover), Failover (Activation), or even configure an observer process to perform Automatic Failover if required.
For more detail, please view the online documentation, which has detailed instructions on how this can be configured.