Re: Informix Remote Mirror Disk

Bill Williams in X-Informix-List-Id: <list.267> appears to consider that remote mirroring of data should not be implemented as it will affect performance of the database. For those sites where performance is the major issue I would fully agree but many sites consider that safty and availability of data are more important. In these cases remote mirroring is an essentail requirement. Of course any site manager interested in performance only that implements a remote mirroring *option* needs his head examined. Bill's method of implementing remote mirroring would indeed provide major performance drawbacks. But there are other solutions. Firstly it is unnecessary to have the primary database continually checking on the remote database to see if it has become available again. On Local mirroring when a disk becomes unavailable the system reverts to using a single drive and waits for the database administrator to invoke the mirroring again either on a new drive or on the repaired old one. Remote mirroring can be implemented in a similar fashion especially if disc block mirroring is being done rather than remote transaction processing. Secondly to recover the link between a local and remote disk though it takes time need be no more difficult than recovery for a local mirrored drive. A background process sends every block from the disk to the remote disk while at the same time blocks written out by the database are mirrored to both drives. Performance impact would be similar to local mirroring, except for the network overhead which with a high performance network need not be that bad. If the remote database was being maintained via remote transaction entry the system can also be quite simple. Assuming that the main system waits for each remote commit. On a failure of the link the system would mark in the log (which is being maintained anyway) when contact was lost and continue processing without reference to the remote system. On database administrator initiated recovery a background process would be started which would read the log from the marked position and send each transaction in turn to the remote system. Performance inpact would be small as the processing of each transaction would be done at the remote site. With the remote system running, during recovery, at peak transaction rate catch up time should not be to bad depending on downtime and transaction rate during downtime. At catch up a checkpoint would be called and double commits restarted. Actual implementation of such systems is more difficult than the above discussion but has been achieved by systems in the field. I would certainly like to see facilities for remote maintenance or mirroring easily available on all Unix boxes whether these are implemented by Informix or at a lower level. At the moment we have to implement our own solutions. Cheers, Jim -------------------------------------------------------------------- Name: Jim Gordon Internet: jgordon@ssf-sys.DHL.COM Company: DHL Systems Inc Phone: (415) 358-5911 Address: 1700 S. Amphlett Blvd. Fax: (415) 571-6429 San Mateo, CA 94402 --------------------------------------------------------------------