With C Replicator (CREP) replication, the database instances and replicator can fail due to hardware or software failure. For guidance on monitoring CREP in order to identify failures, see CREP Monitoring and diagnostics.
The failures can lead to loss of process or the process being left in failed state. There is no automatic recovery from failures but the following list describes suggested recovery steps for typical failures.
Note, that in complicated topologies the typical recovery action (executing the START REPLICATION SUBSCRIPTION statement on the replicator instance) might be required in multiple places.
▪ Source or target database failure: The replication is left in an error state. After the database is restarted, replication is not active. In order to continue replication, execute the START REPLICATION SUBSCRIPTION statement on the appropriate replicator instance.
– If the target database fails, the replicator transparently recovers any lost data after the last checkpoint by re-running the lost transactions.
– If the source database fails, the replicator can not recover any lost data that was supposed to replicate to target.
▪ Replication failure: The reason for failure needs to be analyzed. Schema-related failures (missing tables or incompatible schemas) must be resolved by fixing the schema before restarting replication. Depending on the conflict resolution rules, any data-related failures might need resolving before you can restart the replication. After the reason for failure is resolved, restart replication by executing the START REPLICATION SUBSCRIPTION statement.
▪ Connection failure between source and target databases: The replicator fails when the timeout to either database is exceeded. After the connection failure is resolved, restart replication by executing the START REPLICATION SUBSCRIPTION statement.
CREP supports either the source or target database being part of a HotStandby (HSB) pair. If there are HSB-related failovers or switchovers in database instances, replication supports failover and switchover and is able to transparently continue, as long as the connections are aware of the transparent failover, see Failure transparency in Transparent Connectivity.