An unplanned failover could be due to a hardware or software failure or power outage with the production server. Because the production server is not available, you may need to failover to the failover server. This procedure guides you through the failover, including validating the rollback location, using a snapshot.
The Steps portlet shows the steps that are run by the cluster in the case of unplanned failover. Steps 10 and 20 need to be run by the user one step at a time. Steps 30-50 are run by the cluster continuously.
-
Select Run on the Action toolbar on the Steps portlet.
Table 7 on page 290 shows the steps that are run by the cluster.
|
Sequence number |
Step |
Dialog for this step |
Command for this step |
|---|---|---|---|
|
10 |
Create a snapshot on failover server. |
If by Point in Time or Event Marker: scrt_ra -S timestamp -C <Primary Context id> or if by Container ID: scrt_ra -t Container ID -C <Primary Context id>followed byrtmnt -f -C <Primary Context id> |
|
|
20 |
Delete a snapshot on failover server. |
rtumnt -f -R -C <Primary Context id> (followed by) scrt_ra -W -C <Primary Context id> |
|
|
30 |
Rollback the failover server |
If by Point in Time or Event Marker: scrt_ra -F -S timestamp <Primary Context id> If by Container ID” scrt_ra -F -t <Container ID> -C <Primary Context ID> |
|
|
40 |
Failover the replication group. Server roles change. |
rtdr -q -C <Primary Context id> failover |
|
|
50 |
Start application on the new production server. (if an application start script is specified in the configuration) |
NOTES: This step is automatically started by cluster services if an application start script is specified in the configuration. When the new recovery server comes back online replication will be automatically started by cluster services. |
|