Replication Server provides you with various preventive measures, which you can take to protect data in your replication system.
Standby Applications
Protect the data in your replication system by maintaining separate (standby) copies of primary data.
Two possible standby methods are:
• Warm standby application – a pair of databases from the same vendor, one of which is a backup copy of the other. Client applications update the active database; Replication Server maintains the standby database by copying supported operations to the active database.
• Hardware data mirroring – a form of hot standby application. With the use of additional hardware, data mirroring maintains an exact copy of the primary data by reproducing all operations on the primary data.
See also
• Save Interval on page 82 • Coordinated Dumps on page 82
Compare Methods
Weigh the differences between a hot standby application and a warm standby application. In a hot standby application, a standby database can be placed into service without
interrupting client applications and without losing any transactions. A hot standby database guarantees that transactions committed on the active database are also committed on the standby. When both databases are running, the active database and the standby database are in sync, and the hot standby database is ready for immediate use.
Alternately, a warm standby application maintained by Replication Server:
• Can be used in environments where data mirroring applications cannot, especially when necessary hardware is not available.
• Tolerates temporary network failures better than some hot standby applications because committed transactions can be stored on the active database, even when the standby database is not running.
• Minimizes overhead on the active database because the active database does not need to verify that the databases are in sync.
• Requires some interruption of client applications when switching to the standby database. • May not have executed in the standby database the most recent transactions committed in
the active database.
Warm Standby
A warm standby application is a pair of databases, one of which is a backup copy of the other. Client applications update the active database; Replication Server maintains the standby database as a copy of the active database.
The Replication Server warm standby application for Adaptive Server databases is described in the Replication Server Administration Guide Volume 2 > Managing Warm Standby Applications.
Note: Replication Server version 12.0 and later supports Sybase Failover available in
Adaptive Server Enterprise version 12.0. Failover support is not a substitute for warm standby. While warm standby applications keep a copy of a database, Failover support accesses the same database from a different machine. Connections from Replication Server to warm standby databases work the same way.
For detailed information about how Failover support works in Replication Server, see Replication Server Administration Guide Volume 2 > Configuring the Replication System to Support Sybase Failover and Replication Server Administration Guide Volume 2 > High Availability on Sun Cluster 2.2.
Hardware Data Mirroring
To ensure the highest data availability, you can mirror the most critical data in the replication system. Mirroring duplicates I/O operations, maintaning two identical copies of the data. If the active media fails, the standby is brought online instantly. Mirroring all but eliminates the possibility of transaction loss.
The most beneficial places to use mirroring in a replication system are listed here in priority order:
1. Primary database transaction logs
Transaction logs store transactions that have not been dumped to tape. If the primary transaction log is lost, transactions must be resubmitted.
2. Primary database
A database can be recovered by reloading a previous database dump and subsequent transaction dumps. However, recovering a database that stores primary data also requires recovering or reinitializing the data that has been replicated throughout the enterprise. Extended downtime is often catastrophic for OLTP systems. Mirroring the primary data can prevent this type of catastrophe.
3. Replication Server stable queues
Replication Server stores transactions in store-and-forward disk queues called stable queues. It allocates the queues from disk partitions assigned to the Replication Server using the create partition command.
Note: create partition makes a partition available to Replication Server, replacing the existing add partition command. add partition continues to be supported for backward compatibility. The syntax and usage of the two commands are identical. See Replication Server Reference Manual > Replication Server Commands > create partition.
The data stored in stable queues is redundant; it originates in the primary database transaction log. However, if a stable queue is lost, Replication Server cannot deliver transactions to replicate sites. As a result, subscriptions at replicate sites must be reinitialized. Mirroring disk partitions protects stable queues and minimizes potential downtime for replicate databases.
4. Replication Server System Database (RSSD)
Recovering from a failure of the RSSD can be a complex process if data such as replication definitions, subscriptions, routes, or function or error classes have been modified since the last backup. See Replication Server Administration Guide Volume 2 > Replication System Recovery.
Mirroring the RSSD can prevent system data loss and the necessity of a complex recovery process. If you choose not to mirror the RSSD, be sure to back up the RSSD after any RCL operation that changes system data.