RDF/IMP, IMPX, and ZLT System Management Manual

Introducing RDF
HP NonStop RDF/IMP, IMPX, and ZLT System Management Manual—524388-002
1-27
Reciprocal and Chain Replication
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.
Alternatively, if your two databases must share the same disks, then you must explicitly
specify which files and tables you want replicated by each RDF subsystem. For
erxample, RDF Subsystem 1 would INCLUDE only Primary DB 1, and RDF Subsystem
2 would INCLUDE only Primary DB 2.