Using Zlt To Achieve The Same Protection; Rdfzlt With Triple Contingency - HP NonStop RDF J-series RVUs Management Manual

RDF Subsystem #2
\A ---------> \C
Because the two subsystems run independently of one another, if system \A fails and you execute
TAKEOVER commands on systems \B and \C, the two backup databases might not be
synchronized with one another. The extractor for the \A-to-\B subsystem, for example, might
have replicated audit data to system \B, but, before the extractor for the \A-to-\C subsystem
could replicate the same data to system \C, system \A failed. To correct this situation, you issue
a COPYAUDIT command to transfer the extra audit data from system \B to system \C. You
then reissue the TAKEOVER command on system \C, and the two backup databases are logically
identical. At this point you can then continue application processing from system \B to system
\C or from system \C to system \B within minutes of losing system \A.

Using ZLT to Achieve the same Protection

While the COPYAUDIT command does not work for RDF configurations that include auxiliary
audit, you can achieve Triple Contingency with auxiliary audit by using the ZRDF/ZLT product
because the ZLT functionality supports auxiliary audit. To achieve the same result using the
RDF/ZLT product you configure system \B as the ZLT standby node for both RDF subsystems
#1 and #2. Upon losing system \A, you connect the remote mirrors to system \B and issue
TAKEOVER commands on both systems \B and \C. Since, as part of the ZLT takeover, each
subsystem fetches the final audit data from the remote mirrors connected to system \B, both
backup databases receive the same data. When the takeover operations are complete, the databases
on systems \B and \C are logically identical to one another, you have not lost any committed
data regardless of the number of auxiliary audit trails involved.
Figure 10-1 RDFZLT with Triple Contingency
276 Triple Contingency