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 you must manually run to perform an unplanned failover for 2-node non-clustered replication groups.Each step is run, with pauses after each step.
-
Select Run on the Action toolbar on the Steps portlet.
Table 5 on page 283 shows what steps you must manually run to perform an unplanned failover for non-clustered replication groups.
|
Sequence number |
Step |
Dialog for this step |
Command for this step |
|---|---|---|---|
|
10 |
Create a snapshot on failover server. |
scrt_ra -S timestamp (if by Point in Time or Event Marker) -C <Primary Context id> or scrt_ra -t <Container ID> (if by Container ID ) -C <Primary Context ID>, followed by rtmnt -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 |
scrt_ra -F -S <timestamp> (if by Point in Time or Event Marker) <Primary Context id> or scrt_ra -F -t <Container ID> (if by Container ID) -C <Primary Context id> |
|
|
40 |
Failover the replication group. Server roles change. |
rtdr -q -C <Primary Context id> failover |
|
|
50 |
Start replication on the new recovery server |
rtdr -q -C <Primary Context id> resync |
|
|
60 |
Start replication on the new production server |
rtdr -q -C <Failover Context id> resync |