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

If an auxiliary extractor is running behind the master extractor when you issue a STOP TMF
command, the TMF shutdown operation cannot complete until the auxiliary extractor has caught
up with the master extractor. When that happens, RDF (or more specifically, the master receiver
process) might falsely appear to be hung. As soon as the auxiliary extractor has caught up,
however, the TMF shutdown operation proceeds.
Takeover Ramifications
If an auxiliary extractor is running behind the master extractor when you issue a TAKEOVER
command, a transaction just committed on the primary system (and who’s commit record was
received by the master receiver) could be backed out on the backup system.
This could happen under these circumstances:
• In addition to the MAT, you have configured RDF to protect one or more auxiliary audit
trails.
• When the primary system fails, an auxiliary extractor is running behind the master extractor.
For example, the master receiver has received the commit record associated with a particular
transaction, but the auxiliary receiver is missing audit data for that same transaction.
• A committed transaction (whose commit record was received by the master receiver just
before the primary system failure) updated only a volume associated with the MAT.
Usage of Master and Auxiliary Audit Trails
A master extractor must always be associated with the MAT even if no data volumes are
configured to the MAT. A master extractor is required because the MAT contains audit records
that preserve TMF control information required by RDF on the backup system, and this control
information is not stored in any auxiliary audit trail.
Using Expand Multi-CPU Paths
The use of Expand with ATM or Fast Ethernet provides considerable bandwidth, and it is often
sufficient to have a single Expand path driven out of a single processor.
If your RDF configuration is replicating auxiliary audit trails, however, the total amount of audit
data to be sent from the primary system to the backup system could be more than a single Expand
path can handle. If that is the case, you should use the Expand multi-CPU path feature.
Expand multi-CPU paths enable you to spread the communications load over multiple processors
by connecting multiple Expand line-handler processes, each in a separate processor, between
two adjacent nodes. In an RDF environment, you would use this feature to establish dedicated
paths for the master extractor-receiver pair and multiple auxiliary extractor-receiver pairs.
Suppose you will be configuring three extractor-receiver pairs: one for the MAT and one each
for auxiliary audit trails AUX01 and AUX02. Suppose further that both your primary and backup
systems have ten processors. For each Expand multi-CPU path, you place the matching Expand
line-handlers in the same processor on both systems.
To set up our three paths in processors 3, 5, and 7, for example, you would put matching Expand
line-handlers in processor 3 on both systems, in processor 5 on both systems, and in processor
7 on both systems. Within RDF you would then configure processor 3 as the primary CPU for
the master extractor and receiver, processor 5 as the primary CPU for the AUX01 extractor and
receiver, and processor 7 as the primary CPU for the AUX02 extractor and receiver. Thereafter
all messages between the master extractor and receiver will go through the path in processor 3
on both systems, all messages between the AUX01 extractor and receiver will go through the
path in processor 5 on both systems, and all messages between the AUX02 extractor and receiver
will go through the path in processor 7 on both systems.
For more information about Expand multi-CPU paths, see the Expand Configuration and Management
Manual.
Takeover Ramifications 273