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

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

An unplanned outage typically occurs as the result of a sudden disaster that prevents the database
on the primary system from being used. The classic purpose of RDF is to make rapid recovery
from an unplanned outage possible by maintaining a replicated database on a backup system.
When the primary system is unexpectedly affected by a disaster, you can shift operations to the
replicated database on the backup system after having the RDF updaters bring the backup
database to a consistent state. You do that by starting RDFCOM on the backup system and
initiating an RDF takeover operation.
An RDF takeover operation ensures that all audit records associated with transactions that are
known to have been committed is applied to the backup database
Unplanned Outages With ZLT
Zero Lost Transactions (ZLT), functionality that is available only with the RDF/ZLT product,
ensures that no transactions that commit on the primary system are lost on the RDF backup
system if that primary system is downed by an unplanned outage. RDF achieves this though the
use of remote mirroring for the relevant TMF audit trail volume(s). That is, one mirror of an
audit trail volume remains local to the primary system, but the other mirror is located at a remote
standby site.
When a primary system is downed by some unplanned outage or disaster, there might be some
audit data that the extractor on the primary system was unable to send to the backup system
before the outage. With ZLT functionality, RDF fetches all remaining audit data from the remote
mirror, thereby guaranteeing no loss of committed data during the RDF takeover operation.
For information about the ZLT function, see Chapter 17 (page 337) .
Unplanned Outages Without ZLT
Without ZLT functionality, it is possible for some committed transactions to be lost during an
unplanned outage. When the RDF TAKEOVER command is issued, any transaction whose final
outcome is unknown on the backup system is backed out of the backup database. One or more
transactions might have committed on the primary system, but, before the extractor could read
and send the associated audit data to the backup system, the primary system failed. Loss of audit
data in this manner typically involves no more than a fraction of a second.
If the primary system is unexpectedly brought down because of a disaster, the outcome of some
transactions might never be known, as illustrated in
Table 1-1 .
Table 1-1 Audit Records at the Time of a Primary System Failure
Updates sent to the backup (Sequence in image trail file) Primary database updates (Sequence in master audit trail
file)
TRANS100—Update 1 TRANS100—Update 1
TRANS100—Update 2 TRANS100—Update 2
. .
. .
. .
TRANS100—Update 10 TRANS100—Update 10
TRANS101—Update 1 TRANS101—Update 1
TRANS100—Commit record
(Primary system fails)
In the example illustrated in Table 1-1 , a disaster has brought down the primary system
immediately after the commit record for transaction 100 was written to the MAT, but before the
RDF extractor process was able to send the commit record to the backup system. For transaction
34 Introducing RDF