|
|
|
The FairCom mirroring facility makes it possible to store important files on different drive volumes, partitions or physical drives. If the primary storage location is lost due to some form of catastrophe (for example, a hard drive head crash) the mirroring logic can automatically detect the lost connection and switch to the secondary or “mirrored” storage area.
The mirrored file is easily specified by appending a vertical bar (‘|’) followed by the mirror name to any FairCom DB file name. For example, to mirror the file customer.dat to the file mirror.dat, define the file as follows in the file definitions:
customer.dat|mirror.dat
The mirrored file can be automatically created at file creation time by using the “primary_name|mirror_name” string whenever an ordinary FairCom DB file name is supplied to the FairCom DB create routine, that is, in parameter files, IFIL structures, or in the file name string for low level creates. The file names can include path information on either or both file names, as with:
D:\Data\customer.dat|e:\mirrors\customer.dat
If a file is created without mirroring, it can be subsequently mirrored as follows:
Note: The combined “primary_name|mirror_name” must fit within the 255-byte maximum length defined by the variable MAX_NAME found in ctopt2.h.
Mirroring is supplied for FairCom Server and single-user operations. It applies to all c‑tree file modes including transaction processed files. Once a file is created and opened with mirroring, all subsequent file opens must be mirrored (via the file name) with the following exceptions:
If a mirrored file is opened without a mirror and ctMIRROR_SKP is not in the file mode, then the open fails with error MSKP_ERR (550).
Under Server operation, all mirroring can be suspended by adding MIRRORS NO to the Server configuration file, ctsrvr.cfg. This may be useful when the mirror hardware facility is not operational, but it is necessary to still use the primary data file with the Server.
By default, read and write operations on mirrored files will continue without returning an error if either one of the files fail, but the other succeeds. When this happens, the failed file is shut down and subsequent I/O operations continue only with the remaining file. If mirroring is being used in the client/server model, the SystemMonitor() function receives an event when one of the files succeed and the other fails. Also, the OPS_MIRROR_TRM bit is turned on in the status word. If the default is overridden by a call to SetOperationState(), which turns on the OPS_MIRROR_NOSWITCH bit in the status word, any operation that fails on the primary or the mirror returns an error. See “SystemMonitor” and “SetOperationState (SetOperationState, SetOperationState)” for more details.
The best mirroring approach is to use hardware mirroring so that the application is not burdened with the duplicate writes. Keep in mind that mirroring is not a syncing approach, but rather a live redundant data store.
