HP NonStop RDF, Руководство по управлению

Страница: 298 / 478

the MAT and auxiliary audit trails and send data to the receivers. The updaters read their data
from their image trails and apply it to their UpdateVolumes. During normal processing, no RDF
subsystem (except the RDFNET process within the network master primary system) interacts
with any other RDF subsystem in the RDF network. Therefore, the performance of an individual
RDF subsystem is unaffected by its inclusion within an RDF network.
RDF Takeovers Within a Network Environment
With RDF/ZLT, no committed data from any primary system in the RDF network is lost. The
discussions that follow regarding loss of data in a network takeover only apply to non-RDF/ZLT
environments.
If you have configured an RDF network and must initiate a takeover on a backup system in the
network, then you must execute a takeover on all the backup systems in the network. You do
that by issuing an RDFCOM TAKEOVER command on each individual backup system. When
a takeover occurs within an RDF network, each subsystem’s takeover operation consists of three
phases of operation:
1. A local undo phase
2. A file undo phase
3. A network undo phase
Takeover Phase 1 – Local Undo
This phase is identical to a normal RDF takeover (one that is totally unrelated to an RDF network).
It consists of determining what transaction data has already been applied to the backup database
but whose outcomes are unknown. Once the transactions have been identified, all updates
associated with them are undone. The purger process determines what transactions must be
undone and it writes the list into the ZTXUNDO file in the MIT.
For example, suppose you began a transaction on your primary system, you executed ten updates,
and you committed the transaction, but the extractor process was only able to transmit the first
five updates to the backup system before being terminated by an unplanned outage. In such a
case, the RDF subsystem recognizes it is missing data for the particular transaction (because it
does not know how the transaction ended), and it undoes the five updates it had previously
applied to the backup database.
In summary, phase 1 of a takeover operation undoes data associated with transactions whose
complete data did not make it to the backup system at the time the primary system failed.
Takeover Phase 2 – File Undo
This undo phase only gets executed if volumes went down on the primary system, transactions
were aborted, and the volumes were never reenabled on the primary system before the primary
system was lost. In that situation, RDF determines what Backout could not undo on the primary
system, and the Phase 2 File Undo operation performs this type of undo. Even with the RDF/ZLT
product, the File Undo operation performs this type of undo.
Takeover Phase 3 – Network Undo
Phase three determines if network transaction data is missing from any of the backup systems
in the RDF network, and marks those transactions to be undone on all of the systems. For example,
suppose you began a network transaction, updated tables on ten different systems, and then
committed the transaction. Now suppose that nine of the ten systems were able to transmit their
updates and commit records to their backup systems, but the tenth primary system went down
before its extractor was able to do the same. Phase three determines that the particular transaction
involved all 10 databases, that one of the backup databases is missing audit data for that
transaction, and identifies the transaction as one that must be undone on the other nine systems
298 Network Transactions