Processor Failures; Extractor Failure; Receiver Failure; Updater Failure - HP NonStop RDF J-series RVUs Management Manual

Processor Failures

All RDF processes other than RDFCOM run as process pairs. If a CPU failure causes a primary
RDF process to fail, the backup process takes over without interruption in service.
If any RDF process pair stops unexpectedly, the monitor sends abort messages to the other RDF
processes in order to bring about an orderly shutdown of RDF. You can then restart the subsystem
by merely issuing a START RDF command.
NOTE:
If the monitor process pair unexpectedly stops (for example, as in a double CPU failure),
you must stop the other RDF processes manually and then restart the subsystem. The easiest
way to do this is to issue a series of commands of the following form: STATUS *,PROG
RDF-software-loc.procname, STOP.
The subtopics that follow discuss how RDF responds to extractor, receiver, updater, and RDF
state transition failures.

Extractor Failure

Although the extractor runs as a process pair, the primary process does not maintain restart
information nor checkpoint this information to its backup. Instead, the receiver maintains all
restart information for the extractor, ensuring that the extractor is restartable. The restart point
is based on the audit trail position of the last record stored in the image trail on the backup
system.
If the extractor process pair inadvertently stops, you can (as stated above) restart the RDF
subsystem by merely issuing a START RDF command.
CAUTION:
should not add any disk volumes to the RDF configuration (with the ADD VOLUME command).
If the primary CPU of the extractor process fails, the backup extractor process requests from the
receiver a new starting position in the audit trail, ensuring a correct restart position. This
extractor-receiver protocol also provides protection against messages from the extractor
erroneously arriving out-of-order: if a message arrives out-of-order, the receiver simply directs
the extractor to restart.
When the CPU that failed comes back up, RDF switches the extractor to run on the reactivated
primary CPU.
If both the primary and backup CPUs of the extractor process fail, RDF aborts.

Receiver Failure

If the primary CPU of the receiver process fails, the receiver process in the backup CPU takes
over and resynchronizes with the extractor process. The extractor process might have to resend
audit data that was generated several seconds earlier. When the CPU that failed comes back up,
RDF switches the receiver to run on the reactivated primary CPU.
If both the primary and backup CPUs of the receiver process fail, RDF aborts.

Updater Failure

If the primary CPU of an updater process fails, the corresponding updater process in the backup
CPU takes over.
If the primary CPU of an updater process fails and then comes back up, RDF does not switch
the updater to run on the reactivated primary CPU. Instead, once the backup updater takes over,
it becomes (and remains) the new primary process. If you subsequently stop and then restart
updating, however, the original CPU configuration for this updater process is restored.
If both the primary and backup CPUs of an updater fail, RDF aborts.
During the interval between loss of the extractor and RDF subsystem restart, you
Responding to Operational Failures 127