Takeover Ramifications; Usage Of Master And Auxiliary Audit Trails; Using Expand Multi-Cpu Paths - HP NonStop RDF J-series RVUs Management Manual

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. The same can happen to the updaters when a
stop-update-to-time or a SQL shared access DDL operation enters the RDF subsystem, wherein
the updaters configured to an auxiliary audit trail may take a long time to shutdown if the
auxiliary extractor has fallen behind. When that extractor finally caztches up, the affected updaters
are able to shutdown.

Takeover Ramifications

For a non-RDF/ZLT congfiguration, 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, Fast Ethernet, or Servenet 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.
Takeover Ramifications 293