RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

Example 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.
Example 3 Invalid Chain Replication
System \A System \B System \C
RDF Subsystem 1
Primary DB 1 ---------> Backup DB 1
RDF Subsystem 2
Backup DB 1 ---------------> Another Backup DB 1
In Example 3 , RDF should not be configured to replicate RDF updater changes to another backup
system. You would not get an error in configuring this environment, but replication to the database
on \C would only consist of TMF Backout-generated audit on \B due to updater transactions that
aborted because RDF extractors filter out all updater-generated audit.
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 as in Example 1 “Reciprocal Replication”. 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, when the
updater for RDF Subsystem 2 on \A applies this record to Primary DB 1, it thereby backs out the
46 Introducing RDF