Download Guide to IBM Informix Enterprise Replication

Backup and Restore Considerations
Due to this asynchronous propagation, avoid performing control operations
in quick succession that might directly conflict with one another without
verifying that the first operation has successfully propagated through the
entire enterprise network. Specifically, avoid deleting Enterprise Replication
objects such as replicates, replicate sets, and Enterprise Replication servers,
and immediately re-creating those objects with the same name. Doing so can
cause failures in the Enterprise Replication system at the time of the
operation or later. These failures might manifest themselves in ways that do
not directly indicate the source of the problem.
If you must delete and re-create a definition, use a different name for the new
object (for example, delete replicate a.001 and recreate it as a.002) or wait until
the delete action has successfully propagated through the entire Enterprise
Replication system before you re-create the object. The former strategy is
especially appropriate if you have database servers that are not connected to
the Enterprise Replication network at all times. It might take significant time
before the operation is propagated to those disconnected servers.
Backup and Restore Considerations
When backing up and restoring database servers that participate in replication, do not stop Enterprise Replication before performing a backup on an
Enterprise Replication system.
Database and Table Design Considerations
Consider the following when designing databases and tables for replication:
■
Unbuffered Logging
■
Table Types
■
Shadow Columns
■
SERIAL Data Types and Primary Keys
■
Cascading Deletes
■
Triggers
Overview of Enterprise Replication Administration 2-9