Best practice is that storage devices are never directly presented to IDS as chunks, but only symbolic links to them. This makes a variety of device change scenarios easier, and facilitates standardisation across replicas. It is a prerequisite for the technique described here. Also, you must restart IDS with “MIRROR 1” set in the $INFORMIXDIR/etc/$ONCONFIG configuration file beforehand for the database engine feature to be available.
The example described here is based on an actual case where iSCSI LUNs were replaced with logical volumes in a local SSD RAID 10 array on Linux. This was performed on both the primary instance and a High-availability Data Replication (HDR) secondary server.
The following files were created on both servers (generated in Excel where easier):
Note that temp dbspaces were not included above as:
- they cannot be mirrored;
- contents are not persisted and would never need migrating;
- this system holds temp spaces in RAM disk (see article) so did not need relocating.
The new logical volumes were created – and correct chunk ownership enforced as defined in the provided udev rules file (the contents should all be on one line) – on both primary and secondary systems:
The above is specific to Linux and run as “root”, whereas all other following steps should work on any Unix variant and are run as “informix”.
Symbolic links to the logical volume devices are created next on both systems; Informix mirror chunks are then defined on the primary with “onspaces -m” which automatically replicates the definition on the secondary but only synchronises contents on the primary; contents are then synchronised manually on the secondary with “onspaces -s”:
Once synchronisation had completed several hours later (checked with “onstat -d”), the switch of old/new chunks could be performed on the secondary (it’s better to verify the process there first rather than on the primary):
Depending on the IDS version, it may fail to bring online the root dbspace mirror on the secondary due to a defect, generating an assert. If so, recover the down chunk with:
During a very short planned maintenance outage on the primary some days later, the switch-over was repeated on the primary with:
After running for a suitable time to prove the new storage was working correctly, the mirrors were dropped from both servers by running this final command on the primary: