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.
For information about switching the active and standby databases
in a warm standby application, see the Replication Server Administration
Guide.
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.
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.
|
4 |
Failover the disk replication system to:
|
5 |
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 perform failover in 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:
quiesce
The quiesce command completes once the Replication Agent has reached the end of the Primary database transaction log, and all generated LTL commands are sent to Replication Server.
For more information, see “Stopping replication in the Mirror Replication Agent” and “Determining current Mirror Replication Agent status”.
Check the Replication Server stable queue for open transactions.
Log in to the Replication Server with a user login that has “sa” permission, and execute the following command:
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.
For more information about the admin who command, see the Replication Server Reference Manual.
Fail over the disk replication system.
Reconfigure the disk replication system to:
Treat the standby database data and log devices as “primary” (source) devices
Mirror all subsequent changes on the standby database data and log devices to another set of standby (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.
