RDF/IMP and IMPX System Management Manual (RDF 1.4+)

Managing RDF
HP NonStop RDF/IMP and IMPX System Management Manual—524388-001
5-21
Takeover Failure
Takeover Failure
If a double CPU failure occurs and the receiver process pair or an updater process pair
fails during a takeover operation, you can resume the operation just by entering the
TAKEOVER command through RDFCOM again. You can ascertain that a takeover
operation failed by issuing a STATUS RDF command and getting a response such as
the following:
STATUS RDF (\RDF04 -> \RDF05) is NOT running
A partial RDF TAKEOVER has completed
Also, a takeover failure generates a 725 event in the EMS log.
Monitor Considerations
Whether the RDF monitor was started when the initial TAKEOVER command was
executed or not, this process is always started when the TAKEOVER command is
reissued.
Updater Considerations
When the purger shuts down at the end of the takeover operation, it examines the
context record of each updater process to determine if that updater has processed all
applicable audit data through the end-of-file in the image trail. If all updaters have
processed through the end-of-file, the purger logs a 724 message to the EMS event
log, indicating that the takeover operation completed successfully. But if it determines
that one or more updaters have terminated prematurely, the purger logs RDF Message
726 for each updater that failed and then logs RDF Message 725, a general message
indicating that the takeover operation did not complete successfully. If these messages
appear in the EMS event log, you must reissue the TAKEOVER command.
Takeover and File Recovery
After you initiate a takeover, it is possible that the last committed transactions did not
make it to the backup system (meaning that the backup and primary databases are not
synchronized).
If the takeover completes on the backup system, the purger logs an RDF event 888
specifying a MAT position (sno, rba). Subsequently, when the primary system is once
again online and you are ready to switch the applications back to the primary, you first
initiate a TMF file recovery command with the TOMATPOSITION option on the primary
system specifying the logged MAT position from the 888 event. TMF restores the
primary database to the exact same state that the backup database was in when the
takeover operation completed.
Note. You always use the logged MAT position from the 888 event message to initiate the file
recovery operation, even if the RDF configuration is replicating auxiliary audit trails.