Abstract
Informix dbspace backups are known as “archives”. From version 14.10, these can be made on a Remote Standalone Secondary (RSS) replica system. This article describes the necessary configuration changes which are not well documented. The process is easy, but does require a restart of the RSS instance.
Content
Examples in this article were produced using the provided “stores_demo” database in a Docker container from ibmcom/informix-developer-database.
In a real case, we manage a multi-terabyte Informix 14.10 system which has both a local “High-availability Data Replication” (HDR) standby server and an RSS in another country for faster querying and to reduce traffic on the WAN link. We needed to be able to clone the RSS to a fourth system under testing without having to copy an archive across the WAN which would be very slow and affect other systems.
This article assumes that you already have RSS up and running. If not, refer to “Starting an RS secondary server for the first time“. Before doing that, you must enable “Index page logging” on the primary instance.
From the first release of IDS version 14.10, archives on an RSS system are possible if you set the following configuration parameter in the $ONCONFIG file, but the instance must be restarted:
It can also be set to 2, which is undocumented but shown by the following command:
There are two other essential changes. Firstly, unless you disable logical log backups, the RSS will surprisingly try to do that, which you are unlikely to want. Whether you use “ontape” or “onbar” for archives, that should be avoided by setting the following configuration parameter only on the RSS system and restarting that instance:
LTAPEDEV /dev/null
Secondly, it is your responsibility to ensure that all database objects are logged. Any unlogged databases, RAW tables, or unlogged smart blobs cannot be replicated. By default, when you attempt an archive on RSS, it will check and refuse to continue if it finds any. Moreover, if you have large smart blob spaces, that process can be very lengthy, and cause a long checkpoint on the primary, of around 15 minutes in our case. This can be avoided with the following parameter available from IDS 14.10.FC8 onwards:
If you click on the link, you will find that the parameter is documented but not the value 3. It is included in the following command output (also from IDS 14.10.FC8 onwards):
The easiest option is to make all of the above changes to the $ONCONFIG file for the RSS instance and restart it just once.
To check yourself whether there are unlogged objects:
| Type | Check | Fix |
|---|---|---|
| Table | SELECT tabname | ALTER TABLE table TYPE (STANDARD); |
| Database | SELECT name | ontape -s -L 0 -t /dev/null -U database |
| Blob space | SELECT name | None |
| Smart blob | oncheck -pS | grep -c LO_NOLOG | onspaces -ch sbspace -Df "LOGGING=ON" -y |
Note that the “oncheck” command above took 27 minutes on the real system, which is twice as slow as the built-in check.
You are then ready to run archives on the RSS system. There are three archive levels:
0 – all pages
1 – only those changed since the last level 0
2 – only those changed since the last level 1
The following example used “ontape” to create a level 0 archive on the RSS instance:
These messages were also recorded on the primary instance:
Tips & Tricks
HDR and RSS instances require that chunk paths are identical. However, you can create them on the same host for testing by using relative paths, as long as you start them while in the correct directory. Define shell aliases so you don’t forget, as in this case:
Caveats
This is only supported on RSS servers at this time, not HDR.
Conclusion
You only need to set the configuration parameters listed in this article and restart an RSS instance for local archives to be possible.
Disclaimer
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.
