Automatic Failback With Optional Confirmed Failback
Failback is the process in which Primary station resumes its Primary status after an Failover event.
Two steps are involved in the Failback process: 1) copy all current files from
the Standalone server to the newly-started server; 2) set the newly-started
server to be the Primary station in the clustering.
ClusterReplica SQL 3.1 offers two ways to Failback:
- Automatic Failback - both step 1 and step 2 are done automatically
as soon as the newly-started server reconnects to the clutering. No human
intervention is required with this Failback method.
- Confirmed Failback - both step 1 and step 2 require user
confirmation to complete. Users are giving the choices of whether or not to
overwrite the data on the newly-started server; and whether or not to make
the newly-started server the Primary station.
There are advantage and disadvantages in each of the Failback method.
Advantages:
- The automatic Failback is simple and hassle-free for keeping
the original Primary station to be the active server whenever the clustering
functions normally.
Some users prefer this way because they use a heavy-duty machine to run
the Primary station while using an average machine for the backup.
Naturally, they would prefer to use the original Primary to be the active
server.
- The confirmed Failback guarantees no mistakes on overwritten data.
In some special circumstances, the newly-started server may contain the
data users wanted. Users may then want to copy the data on the newly-started
server to the Standalone server, instead of vice versa which occurs under
normal Failover. Manual Failback gives you full control of which direction
the data flows.
Disadvantages:
- The automatic Failback - In some special circumstances, the
newly-start server may contain the data users want to keep. If automatic
failover is set on the cluster server, this data will be overwritten as soon
as the system is connected to the clustering. This accidental loss of data
then becomes inevitable.
- The confirmed Failback requires a person to sit in front of the
server and confirm each step of the configuration. This process can be tedious and
is vulnerable to human error.
The main reason that some users want to Failback is that of the two
clustering systems, the one used for the Primary station is more robust than the
one used for the Secondary station. Failback keeps the robust system as the
Active server for as long as possible.
Notice that, if the two systems in the
cluster server are comparable, letting the Primary station "float" in between
the servers without Failback can be equally efficient.
Back to ClusterReplica Home page
|
