RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

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: During the interval between loss of the extractor and RDF subsystem restart, you 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, after 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.
Responding to Operational Failures 119