Failover procedure

Failover refers to the process of switching normal system operations from a primary database to a standby database, particularly in the event of a failure that interrupts:

Operations at the primary database, or

Access to the primary database.

You can also use a failover procedure to mitigate the impact of scheduled downtime on database users and clients (for example, when maintenance operations require the primary database to be offline).

This section describes only the failover tasks that are specific to the Mirror Activator system. General system failover procedures are not covered in this document.

The failover procedure described in this section does not use the Replication Server warm standby switch active feature. See the Replication Server Administration Guide for information about switching the active and standby databases in a warm standby application.

Table B-1 provides a checklist of the tasks that you must include in failover procedures for the Mirror Activator system.

The checklist in Table B-1 assumes that:

The primary database has gone offline, triggering the failover procedure to begin.

To provide recovery from a standby database failure, you will use the disk replication system to capture and mirror all changes on the standby database devices while the primary database is offline.

Sybase recommends that you perform these tasks in the order shown.

**Table B-1: Mirror Activator system failover tasks**
Task	Description
1	Verify that the Mirror Replication Agent has finished processing the last transaction record in the log, and then stop replication in the Mirror Replication Agent.
2	Verify that the Replication Server has distributed the last committed transaction in the log.
3	Check the Replication Server stable queue for open transactions. Before failback, you must purge any open transactions that remain in the Replication Server stable queue.
4	Fail over the disk replication system to: Treat the standby database data and log devices as “primary” devices. Mirror all subsequent changes on the standby database data and log devices to another set of standby (or backup) devices.
5	Switch access for users and client applications from the primary database to the standby database.

Table B-1: Mirror Activator system failover tasks

Task

Description

Verify that the Mirror Replication Agent has finished processing the last transaction record in the log, and then stop replication in the Mirror Replication Agent.

Verify that the Replication Server has distributed the last committed transaction in the log.

Check the Replication Server stable queue for open transactions.

Before failback, you must purge any open transactions that remain in the Replication Server stable queue.

Fail over the disk replication system to:

Treat the standby database data and log devices as “primary” devices.
Mirror all subsequent changes on the standby database data and log devices to another set of standby (or backup) devices.

Switch access for users and client applications from the primary database to the standby database.

Use the following procedure for Mirror Activator system failover tasks.

To fail over the Mirror Activator system

Verify that the Mirror Replication Agent has finished processing all transactions in the log, and then stop replication in the Mirror Replication Agent.

Log in to the Mirror Replication Agent administration port and execute the following command:
```
ra_status
```
When the Mirror Replication Agent has finished processing all of the log records, the ra_status command shows its state is Replicating (Waiting at end of log).
After it finishes processing the last log record, execute the following command to stop replication in the Mirror Replication Agent:
```
suspend
```
After you invoke suspend, use the ra_status command to verify that the Mirror Replication Agent is in Admin state.

See “Stopping replication in the Mirror Replication Agent” and “Determining current Mirror Replication Agent status” for more information.

Verify that the Replication Server has finished distributing the last committed transaction to the standby database.

admin who, sqt

When Replication Server has finished distributing the last committed transaction, the admin who, sqt output shows the value 0 (zero) in the Closed column for the SQT thread associated with the standby database connection.

See the Replication Server Reference Manual for more information about the admin who, sqt command.

Check the Replication Server stable queue for open transactions.

admin who, sqt

Check the admin who, sqt output for the SQT thread associated with the standby database connection. The following column values indicate that all committed transactions have been distributed successfully, and that open (uncommitted) transactions remain in the stable queue:

Closed – 0
Open – (any number other than zero)
SQM Blocked – 1
First Trans – STO

Before failback, you must purge any open transactions that remain in the Replication Server stable queue.

See the Replication Server Reference Manual for more information about the admin who command.

Fail over the disk replication system.

Reconfigure the disk replication system to:

Treat the standby database data and log devices as “primary” (or source) devices
Mirror all subsequent changes on the standby database data and log devices to another set of standby (or backup) devices, preferably at an alternate site (neither the primary nor standby site)

Refer to the documentation provided by your disk replication system vendor for more information about the procedures in this step.

After you complete all of the previous tasks, you can switch access for users and client applications from the primary database to the standby database.