RDF System Management Manual for H-Series RVUs (RDF 1.8)

Reciprocal and Chain Replication
Example 1-1 Reciprocal Replication
System \A System \B
RDF Subsystem 1
Primary DB 1 ---------------------------------> Backup DB 1
RDF Subsystem 2
Backup DB 2 <-------------------------------- Primary DB 2
Thus, you have a primary database for RDF subsystem 1 on
system \A (primary DB 1) and a primary database for RDF
subsystem 2 on system \B (primary DB 2).
Example 1-2 Chain Replication
System \A System \B System \C
RDF Subsystem 1
Primary DB 1 ---------> Backup DB 1
Primary DB 2 ----------> Backup DB 2
RDF Subsystem 2
Thus, system \B is both the backup system in RDF subsystem
1 and the primary system in RDF subsystem 2.
The updaters generate audit records as they replicate data to the target files and target tables,
and these audit records are internally marked as updater-generated audit records. The extractors
filter out all updater-generated audit. Thus, under normal circumstances, the extractors do not
send updater-generated audit to their backup systems for replication.
Consider the following example. Assume that Primary DB 1 and Backup DB 2 are both located
on $DATA on \A, and assume that Primary DB 2 and Backup DB 1 are also located on $DATA
on \B. Using the reciprocal example, suppose your application does an update on \A to Primary
DB 1. The extractor of RDF Subsystem 1 sees that the update was for $DATA and sends that
update to \B where the updater applies that update to Backup DB 1. This update generates an
audit record that goes into the audit trail on \B and is marked as updater-generated. The extractor
for RDF Subsystem 2 reads the audit trail looking for audit associated with $DATA. When it
reads the record generated by the updater, it sees the update was associated with $DATA, but
it also sees that the record was updater-generated, which causes the extractor to filter that record
out and not send it to \A. This is correct and desired behavior.
If an updater transaction aborts, the TMF Backout process executes undo for the aborted
transaction, and Backout has no information about what process generated the original audit for
the transaction before it aborted. This can corrupt your primary and backup databases unless
you take appropriate steps (see further below).
Consider the following extension to the example above. After the updater on \B has replicated
the application's update from \A and before the update can commit its transaction on \B, a CPU
failure causes TMF to abort the transaction. Backout undoes the updater's update. The resulting
audit record is associated with $DATA, but Backout does not know which process generated
the original update, and the resulting record is not marked as updater-generated. When the
extractor for RDF Subsystem 2 reads this record generated by Backout, it sees it was for $DATA
and it sees that the record was not updater generated. It therefore sends this record to \A. Now,
56 Introducing RDF