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.

Parent topic: Standby Applications