Updated June 2020
Oninit RFE was delivered with IDS 12.10.xC10 to make switching mirrors easier:
IBM Informix Dynamic Server (IDS) databases reside in “dbspaces”, each composed of one or more “chunks” (files, logical volumes or whole disk devices). If the storage infrastructure is being upgraded, you might find that moving chunks via backup & restore or external copy would take longer than the outage window allows, particularly if this is between different sites.
This article describes a method of achieving this with only a very short downtime using Informix chunk mirroring. We call it Informix Storage Migration via Mirroring:
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:
Informix Storage Migration via Mirroring can be conveniently and quickly achieved by defining mirror chunks on the new array with “onspaces”, waiting for them to be synchronised, and then switching primary and mirror chunks, before eventually dropping the originals.
Downtime while copying the contents is eliminated, and only a very short outage is required to make them the new primary set. Moreover, in a future release, it will be possible to perform that step without no downtime using extended “onspaces” syntax. See this Request for Enhancement we have had accepted:
Suggestions above are provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.
If you have any questions regarding Informix storage migration via mirroring or would like to find out more, simply contact us.