Chain Replication; Invalid Chain Replication - HP NonStop RDF J-series RVUs Management Manual

Example 1-2 Chain Replication
System \A
RDF Subsystem 1
Primary DB 1 ---------> Backup DB 1
Thus, system \B is both the backup system in RDF subsystem 1 and the primary system in RDF
subsystem 2.
Example 1-3 Invalid Chain Replication
System \A
RDF Subsystem 1
Primary DB 1 ---------> Backup DB 1
In Example 1-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-1 "Reciprocal
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,
System \B
Primary DB 2 ----------> Backup DB 2
RDF Subsystem 2
System \B
RDF Subsystem 2
Backup DB 1 ---------------> Another Backup DB 1
Replication". The extractor of RDF Subsystem 1 sees that the
System \C
System \C
RDF Operations 51