RDF System Management Manual

Introducing RDF
HP NonStop RDF System Management Manual—524388-003
1-27
Reciprocal and Chain 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 udpater, 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 commited update of your application. Additionally, Primary DB 1 and
Backup DB 1 are no longer in synch. Even though the updater on \B had its transaction
aborted, that updater will re-apply the application update to Backup DB 1. When done,
Primary DB no longer has the update, but Backup DB 2 does.
Note that, although this example describes a reciprocal configuration, the same basic
problem can happen with chain replication. In the chain case, the extractor for RDF
Subsystem 2 would be sending a Backout generated update to \C where the file or
table involved in the update does not even exist. This will cause the updater
responsibe for $DATA on \C to stall, waiting for you to create the file or table on \C.
The same effect occurs when you set up reciprocal environments or chain
environments, where you also have the REPLICATEPURGE attribute set. In this case,
the updater purges the file through the file system, and the resulting audit record does
not indicate that it was generated by an updater. If the extractor sends the audit record
for the purge to its backup system, the updater might purge a file you do not want
purged, or it might encounter an error 11.
To prevent these problems in a reciprocal configuration or chain configuration, you
must ensure that Backup DB 1 and Primary DB 2 are on mutually exclusive volumes.
For example, put Primary DB 1 and Backup DB 1 is on $DATA1 and put Primary DB 2
and Backup DB 2 on $DATA2. Thus the extractor can filter out the audit by volume
name and not depend on records being marked as updater generated.