Why is implementing Fast-Start Failover always a good idea for your Oracle
Data Guard configuration? There are many customers that do not want to implement Fast-Start Failover
because they say: "I don't want to have any automatic failover to my standby database,
I always want to have the control and check what is the status of the primary
database before failing over to the standby database." But there are three main reasons
why having Fast-Start Failover is a good idea. So, let's see what those reasons are.
When you have a Data Guard configuration without Fast-Start Failover, you have a primary database
that sends the information to the standby database that is synchronized. And if at any point you have
a disconnection you can check that the primary database is healthy but the primary database...
you know, will detect that the standby database is not there anymore, and it will just keep working
because it says "Hey, I'm healthy I don't need to stop; There is no failover for any reason; I will
just keep working without a standby database." Because you wouldn't want to block the primary,
no? Except if you use maximum protection mode. But then, if you have a failure of the primary
database, well, you will need to detect the failure, to alert your DBA, have the DBA connect
and verify the status of the primary database, and do a manual failover to the secondary site.
Okay? So, this requires lots of time. Sometimes it might require hours and if
your business is really important you really want to lower your RTO. So, this is one big point.
But then we have another problem that is what happens if you have a network disconnection
but you don't have access to the primary database because of the network.
Now you have a worse problem that is, if you try to do a manual failover you are exposing
yourself to two major risks: The first one is that you might have data loss because you do not know
if the primary committed beyond the time of the network disconnection. And the other problem is
that if you do the manual failover you don't know if the former primary database is still alive. And
if you do a manual failover, you take the risk of having a split-brain condition: having two primary
databases that work independently, and this is a situation that you really don't want to have.
We have three main problems that we have to solve: the first one is lower the RTO, the second one is
avoiding split brain conditions, and the third one is avoiding a failover if there is any data loss.
Let's see how Fast-Start Failover solves that. Fast-Start Failover puts an observer monitoring
the configuration. It will do regular pings to the primary database and to the standby database,
and it acts as a quorum. We'll see later what I mean by "acting as a quorum", but basically,
when you have a problem with the primary database, the Observer will detect that the primary database
is not there and will start the timer that we call a Fast-Start Failover threshold,
that you can configure to meet your RTO objectives. And whenever the Observer
reaches the threshold and the Observer can still not contact the primary database,
it will do an automatic failover and promote the standby database as the new primary database. By
having this threshold, the RTO is really much much lower, and you can configure the threshold to have
the automatic failover in a matter of seconds from when you had the disconnection with the primary
database. So this is really another level of high availability compared to manual intervention.
But what about the other two problems? Indeed, if you have a configuration with the observer and you
lose connectivity with the primary database, but the primary database is still active, remember,
this is a situation where if you do a manual failover, you expose yourself to a split-brain
condition. But in this situation, you have two different partitions of the network,
one with the primary database, and another with Observer and the standby database.
So what the observer will do, because it doesn't have a connection with the primary database,
it will initiate an automatic failover. But we don't have a split-brain condition because what
the primary database sees is that there is no standby database anymore, there is no observer
anymore, and it says: "Hey they are doing an automatic failover on their own. I better shut
down so that I avoid any split-brain situation". So there is this mechanism, this protection
mechanism inside of the primary database that avoids the primary database to commit beyond
the disconnection with the standby database in case there is no observer connectivity as well.
So the primary is isolated without a quorum and it also stops working. This is how we
solve the split-brain situation. How do we solve the zero data loss failover?
When I have a primary database that is synchronized with the standby database
using a synchronous replication, as far as they are synchronized we know that there is no data
loss, because every transaction committed to the primary is also committed to the standby database.
Now, if the primary database for any reason cannot send information to the standby database,
it will wait for another timer that we call the NetTimeout, and say:
"Hey after that amount of time, if I still have my connectivity with the standby database,
I will connect to the observer and tell to the server that I keep writing unsynchronized.
And observer will record the status as "UNSYNCHRONIZED", so it's a situation where there
is the possibility of data loss. And in case of a connectivity problem with the primary database,
the observer will not execute a failover, knowing that there is a situation of data loss.
So this is how we protect also against data loss inside a Fast-Start Failover
configuration. And we've seen how it solves the lower RTO problem,
no split-brain condition, and no failover in case of data loss.