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 3-node non-clustered broadcast replication groups. Each step is run with pauses after each step.
-
Select Run on the Action toolbar on the Steps portlet.
Table 9 on page 298 shows the commands that are run on the servers, while you execute the procedure steps with the Assure UI portal.
|
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> (if by Container ID) scrt_ra -t <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. |
(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> -F <Failover Context ID> -t <new production server> setup (followed by) rtdr -q -C <Primary Context id> failover |
|
|
50 |
Start replication on the new recovery server 2. |
rtdr -q -C <Primary Context id> -F <Failover Context ID> -t <new production server> setup |
|
|
60 |
Start replication on the new recovery server 1. |
rtdr -q -C <Failover Context ID> resync |
|
|
70 |
Start replication on the new production server. |
rtdr -q -C <Failover Context ID> resync |