Designing Disaster Recovery Clusters using Metroclusters and Continentalclusters, Reprinted October 2011 (5900-1881)

If the monitored cluster comes back up following an alert or alarm, but it is certain that the primary
packages cannot start (say, because of damage to the disks on the primary site), then use a special
procedure to initiate recovery:
1. Use the cmhaltcl command to halt the primary cluster.
2. Wait for the monitor to send an alert.
3. Use cmrecovercl -f to perform recovery.
After the cmrecovercl command is issued, Continentalclusters displays a warning message,
such as the following and prompts for a verification that recovery should proceed (the names
“LAcluster” and “NYcluster” are examples):WARNING: This command will take over for
the primary cluster “LAcluster” by starting the recovery package on the
recovery cluster "NYCluster.You must follow your site disaster recovery
procedure to ensure that the primary packages on "LAcluster" are not
running and that recovery on "NYCluster" is necessary. Continuing with
this command while the applications are running on the primary cluster
may result in data corruption.Are you sure that the primary packages
are not running and will not come back, and are you certain that you
want to start the recovery packages? [Y/N].
Reply “Y” to proceed only if you are certain that recovery should take place. After replying “Y”,
a group of messages will appear as shown below.
As the processing of each recovery group occurs (the message about the data receiver package
appears only using logical data replication with data sender and receiver packages):Processing
the recovery group nfsgroup on recovery cluster eastcoast.Disabling
switching for data receiver package nfsreceiverpkg on recovery cluster
eastcost.Halting data receiver package nfsreceiverpkg on recovery cluster
east coast.Starting recovery package nfsbackuppkg on recovery cluster
eastcoast.Enabling package nfsbackuppkg in cluster
eastcoast.----------------exit status = 0----------------
The command cmrecovercl starts up all the recovery packages that are configured in the recovery
groups. The cmrecovercl -c command will skip recovery for recovery groups in maintenance
mode.
In addition to starting the recovery packages all at once, another option is to recover an individual
recovery group by using the following command:
# cmrecovercl -g Recovery_Group_Name
Running the cmrecovercl with option -g starts up only the recovery package configured in the
specified recovery group. The cmrecovercl -g command fails to recover if the specified recovery
group is in maintenance mode.
NOTE: After the cmrecovercl command is issued, there is a delay of at least 90 seconds per
recovery group as the command makes sure that the package is not active on another cluster.
Use the cmviewcl command on the local cluster to confirm that the recovery packages are running
correctly. Following recovery, halt the package that was monitoring the remote cluster if preferred.
If this is not done then notification, if there is a change in the remote cluster’s state, will continue
to be received. The following table shows the status of Continentalclusters packages after recovery
has taken place, and applications are now running on the local cluster.
96 Designing Continentalclusters