Replication System Recovery

While Replication Server tolerates most failure conditions and recovers from them automatically, some failures require user intervention. Learn to identify those failures, and the procedures for recovery which are designed to maintain the integrity of the replication system by recovering lost and corrupted data and restoring that data to its previous state.

Design, install, and administer your replication system with backup and recovery in mind. We assume that dumps are performed on a regular basis and that appropriate tools and settings for handling recovery are in place.

In discussions about recovery, the "current" Replication Server refers to the one with a database (for example, RSSD) that you are recovering. An "upstream" Replication Server has a direct or indirect route to the current Replication Server. A "downstream" Replication Server is one to which the current Replication Server has a direct or indirect route.

You can resynchronize the replicate databases in your replication environment if, for example, there is replication latency between primary and replicate databases such that to recover a database using replication alone is not feasible.

• How to Use Recovery Procedures
  When using recovery procedures, always write down or check off recovery steps as you perform them. Such information can help Sybase Technical Support determine where you are in the recovery procedure, if necessary.
• Configure the Replication System to Support Sybase Failover
  Learn how Replication Server version 12.0 and later supports Sybase Failover available in Adaptive Server Enterprise version 12.0 and later.
• Configure the Replication System to Prevent Data Loss
  Learn the recommended measures for preventing data loss in the event of an irrecoverable database error. If used properly, these measures allow you to restore replicated data using the system recovery procedures.
• Recovery from Partition Loss or Failure
  When a Replication Server detects a failed or missing partition, it shuts down the stable queues that are using the partition and logs messages about the failure. Restarting Replication Server does not correct the problem. You must drop the damaged partition and rebuild the stable queues.
• Recovery from Truncated Primary Database Logs
  Recover from failures caused by truncating a primary transaction log before Replication Server has received the messages.
• Recovery from Primary Database Failures
  If a primary database fails and you are unable to recover all committed transactions, you must load the database to a previous state and follow a recovery procedure designed to restore consistency at the replicate sites.
• Recovery from RSSD Failure
  If you cannot recover the most recent database state of the RSSD, recovering from an RSSD failure is a complex process. In this case, you must load the RSSD from old database dumps and transaction log dumps.
• Recovery Support Tasks
  Standard recovery tasks let you manipulate and identify critical data in the replication system.
• Replicate Database Resynchronization for Adaptive Server
  Replication Server allows you to resynchronize and materialize the replicate database, and resume further replication without losing or risking inconsistency of data, and without forcing a quiesce of your primary database.