Overview of Full Merge and Minimerge Operations
| | |
| ||
| ||
The purpose of either a full merge or a minimerge recovery operation is to compare data on shadow set members to ensure that all of them contain identical data on every logical block. Each block is identified by its logical block number (LBN). During recovery operations, application I/O continues but at a slower rate. A full merge or minimerge operation is managed by one of the OpenVMS systems that has the shadow set mounted. Throughout this manual, minimerge operation and merge operation refer to a minimerge recovery operation and a merge recovery operation, respectively.
A full merge or minimerge operation is initiated by any of the following events:
A system failure that results in incomplete application writes.
A shadow set that enters mount verification and then times out or aborts mount verification, under certain conditions (as described in “Merge Resulting from Mount Verification Timeout”.
A system manager issues a SET SHADOW/DEMAND_MERGE command.
When a system with a mounted shadow set fails, if a write request is made to a shadow set and the system fails before a completion status is returned to the application, the data might be inconsistent on the shadow set members:
All members might contain the new data.
All members might contain the old data.
Some members might contain new data and others might contain old data.
The exact timing of the failure during the original write request determines the outcome. Volume Shadowing for OpenVMS ensures that corresponding LBNs on each shadow set member contain the same data (old or new), when the application issues a read to the shadow set.
A shadow set that enters mount verification and either times out or aborts mount verification enters a merge state, if the following conditions are true:
There are outstanding write I/O requests in the shadow driver's internal queues on the system or systems on which it has timed out.
The shadow set is mounted on other systems in the cluster.
The system on which the mount verification timed out (or aborted mount verification) notifies the other systems on which the shadow set is mounted that a merge operation is needed, and then it disables the shadow set. (It does not dismount it.)
For example, if a shadow set is mounted on eight systems and mount verification times out on two of them, those two systems check their internal queues for write I/O. If any write I/O is found, the shadow set is merged.
The SET SHADOW/DEMAND_MERGE command initiates a merge of a specified shadow set or of all shadow sets. This qualifier is useful if the shadow set is created with the INITIALIZE/SHADOW command without using the /ERASE qualfier.
For more information about using the SET SHADOW/DEMAND_MERGE command, see the HP OpenVMS DCL Dictionary.
In a full merge operation, the members of a shadow set are compared with each other to ensure that they contain the same data. This is done by performing a block-by-block comparison of the entire volume. This can be a very lengthy procedure.
A minimerge operation is significantly faster. By using information about write operations that are logged in volatile controller storage or in a write bitmap on an OpenVMS system, volume shadowing merges only those areas of the shadow set where the write activity occurred. This avoids the need for the entire volume scan that is required by full merge operations, thus reducing consumption of system I/O resources.
Minimerges existed as controller-based prior to the introduction of HBMM, and available only on the HSJ, HSC, and HSD controllers.
Volume Shadowing for OpenVMS Version 8.4 is enhanced to increase the performance of minicopy and minimerge by “looking ahead” of the next bit that is set in the write bitmap. The actual number of QIOs between the SHADOW_SERVER and SYS$SHDRIVER is reduced by this method allowing the minimerge and minicopy to complete fast.