To ensure the highest data availability, you can mirror the most critical data in the replication system. Mirroring duplicates I/O operations to maintain 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:
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.
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.
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.
create
partition makes a partition available to Replication Server. This
command replaces 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 the “create
partition,” in Chapter 3, “Replication
Server Commands” in the Replication Server Reference
Manual.
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.
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. Refer to Chapter 7, “Replication System Recovery,” in the Replication Server Administration Guide Volume 2 for detailed recovery information.
Mirroring the RSSD can prevent system data loss and the necessity of a complex recovery process. If you don’t mirror the RSSD, be sure to back up the RSSD after any RCL operation that changes system data.
