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

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

explicitly excluded by INCLUDE/EXCLUDE lists), most of the physical audit records generated
either for block splits or during FUP RELOAD operations, and all audits generated by the RDF
updaters.
The extractor always tries to fill the buffer to be sent to the receiver. The buffer never contains
partial records; if the buffer is nearly full and the next record to be transmitted does not fit in its
entirety, the extractor transmits the current buffer and puts that next record at the beginning of
the next buffer. The extractor never waits for more than one second to send data to the receiver.
If its current buffer is not filled within a second, the extractor transmits the buffer (even though
it is not filled).
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 can be restarted without any loss
of data. The restart point is based on the MAT position of the last record safely stored in the
image trail on the backup system.
Whenever you start RDF, the extractor requests its starting position in the audit trail from the
receiver. Because this position is based on the audit trail position of the last image record safely
stored in the image trail by the receiver, this method guarantees that no audit is mistakenly
omitted. If the primary extractor process fails, the backup 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 directs the extractor to restart.
When the extractor reads from an audit trail file, it pins the file by sending a message to TMF.
Once pinned, an audit trail file remains pinned until the extractor unpins it or if you issue the
RDFCOM UNPINAUDIT command at the primary system.
CAUTION:
Before deleting an RDF configuration, always issue an UNPINAUDIT command
to unpin any audit trail files that might be pinned by the configuration. If you delete the
configuration without first doing so, then you will be unable to unpin the files afterward.
If you unpin files, RDF cannot be restarted if the files required by the extractor cannot be made
available. When you unpin audit trail files, be sure that these files are dumped to disk or tape.
If they are not dumped, and the TMP renames the file or files required by the extractor, you will
have to reinitialize RDF and resynchronize the primary and backup databases.
In response to the UNPINAUDIT command, RDFCOM issues a prompt asking you to confirm
your request.
If the files are unpinned successfully, RDFCOM issues an informational message to that effect.
If an error occurs while attempting to unpin the audit trail files, the command is ignored, and
RDFCOM issues a message indicating the error.
Receiver Process
A receiver process is a process pair that runs on the backup system. There is one receiver for
each configured extractor. A receiver process accepts audit records from its extractor, sorts them,
and then writes them to the appropriate RDF image trail, as shown in
Figure 1-6 . (The restartability
of a receiver ensures the receiver's correctness at process takeover or under any conditions
requiring resynchronization with its extractor.)
A receiver determines which updater will apply a given image record, and it sorts that record
into the image trail used by that updater. The records in the image trails are subsequently used
by updater processes to update the backup database.
Each receiver creates its own image trail files, preallocates extents, initiates rollovers, and manages
them, except for purging, a task performed by the purger process .
44 Introducing RDF