Failback refers to the process of restoring normal user and client access to a primary database, after a failover switched access from the primary database to a standby database.
This section describes only the failback tasks that are specific to the Mirror Activator system. General system failback procedures are not covered in this document.
Table B-2 provides a checklist of the tasks that you must include in failback procedures for the Mirror Activator system.
The checklist in Table B-2 assumes that:
You have purged the Replication Server stable queue to remove any open transactions remaining after failover.
The primary data server is up and functioning correctly, and you are ready to return it to normal operation.
If you do not purge the Replication Server stable queue
to remove any open transaction that remained in the queue after
failover:
Replication will not start, because Replication Server will not send any new transactions to the standby database until it receives operations to complete the open transactions.
Eventually, the stable queue will run out of space, because Replication Server will not send any transactions after you resume replication upon failback.
Sybase recommends that you perform these tasks in the order shown.
Task |
Description |
---|---|
1 |
Quiesce the standby database to suspend update activity. |
2 |
Fail back the disk replication system to:
|
3 |
Bring the primary database online. |
4 |
Initialize the primary database using the pdb_init move_truncpt command to set the secondary truncation point to the end of the log. |
5 |
Quiesce the primary database. |
6 |
Initialize the Mirror Replication Agent using the ra_init force command, and set the paths to the mirror log devices. |
7 |
Release the quiesce hold on the primary database, after the Mirror Replication Agent initialization is complete. |
8 |
Switch access for users and client applications from the standby database to the primary database. |
9 |
Release the quiesce hold on the standby database, after client access is switched to the primary database. |
10 |
Start replication in the Mirror Replication Agent with the resume command. |
Use the following procedure for Mirror Activator system failback tasks.
To fail back the Mirror Activator system
Quiesce the standby database to suspend update activity.
The quiesce method you use depends on whether you want to use the snapshot materialization mount database option (for databases in Adaptive Server version 12.5.1 or later).
If the Mirror Activator databases are in Adaptive Server version 12.5.0.3, log in to the standby Adaptive Server with a System Administrator user role, and execute the following command:
quiesce database MA_fback hold sdb
where:
MA_fback is a user-defined tag that identifies the database.
sdb is the name of the standby database.
If you want to use the snapshot materialization mount database option for databases in Adaptive Server version 12.5.1 or later, log in to the standby Adaptive Server with a System Administrator user role, and execute the following command:
quiesce database MA_fback hold sdb for external dump to sdb_manifest
where:
MA_fback is a user-defined tag that identifies the database.
sdb is the name of the standby database.
sdb_manifest is the name of the manifest file.
Fail back the disk replication system to:
Materialize the primary database data and log devices from the standby database devices.
Materialize the mirror log devices at the standby site from the materialized primary log devices.
Re-establish synchronous replication from the primary log devices to the mirror log devices at the standby site.
Refer to the documentation provided by your disk replication system vendor for more information about the procedures in this step.
See Appendix A, “Materializing Databases,” for more information about re-materializing a primary database.
Bring the primary database online.
Initialize the primary database using the Mirror Replication Agent pdb_init move_truncpt command. This command marks the database for replication with sp_reptostandby, and sets the secondary truncation point to the end of the log.
See “Setting up the Mirror Activator system” for more information about initializing the primary database.
Quiesce the primary database.
Log in to the primary Adaptive Server with a System Administrator user role, and execute the following command:
quiesce database MA_setup hold pdb
where:
MA_setup is a user-defined tag that identifies the database.
pdb is the name of the primary database.
Initialize the Mirror Replication Agent using the ra_init force command to update the system data repository in the RASD, and then use ra_devicepath to set the paths to the mirror log devices (if necessary).
See “Updating the RASD” for more information.
Release the quiesce hold on the primary database, after the Mirror Replication Agent initialization is complete.
Log in to the primary Adaptive Server with a System Administrator user role, and execute the following command:
quiesce database MA_setup release
where MA_setup is a user-defined tag that identifies the suspended primary database.
Switch access for users and client applications from the standby database to the primary database.
Release the quiesce hold on the standby database, after client access is switched to the primary database.
Log in to the standby Adaptive Server with a System Administrator user role, and execute the following command:
quiesce database MA_fback release
where MA_fback is a user-defined tag that identifies the suspended standby database.
Start replication in the Mirror Replication Agent.
Log in to the Mirror Replication Agent administration port and execute the following command:
resume
After you invoke resume, use the ra_status command to verify that the Mirror Replication Agent is in Replicating state.
See “Starting replication in the Mirror Replication Agent” for more information.