Archives on RSS

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:

BAR_SEC_ALLOW_BACKUP 1

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:

ARCHIVE_UNLOGGED_OBJECTS 3

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):

$ onstat -g cfg full ARCHIVE_UNLOGGED_OBJECTS

IBM Informix Dynamic Server Version 14.10.FC10DE -- Read-Only (RSS) -- Up 1 days 02:11:32 -- 285264 Kbytes

Configuration Parameter Info

id   name                      type    maxlen   units   rsvd  tunable
105  ARCHIVE_UNLOGGED_OBJECTS  INT4    12                     *

min/max : 0,3
     default : 0
     onconfig: 3
     current : 3

This parameter is undocumented.

Description:
     Use ARCHIVE_UNLOGGED_OBJECTS with caution. Setting it allows an archive
     to proceed on a secondary node despite the presence of unlogged objects
     such as raw tables, BLOBspace BLOBs, unlogged smartblobs, and non-logging
     databases.  Because these objects are not fully replicated they will not
     be complete on an archive taken from a secondary. Restoring the archive
     will result in inconsistencies within these objects that make them
     unusable.

Possible values: 0 --   OFF   -- Archive of unlogged objects disallowed
                      1 --  QUIET  -- Archive allowed, quiet check mode
                      2 -- VERBOSE -- Archive allowed, verbose check mode
                      3 --  FAST   -- Archive allowed, no check performed

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 FROM systables -- repeat per database WHERE sysmaster:bitval(flags, "0x10") = 1;`	`ALTER TABLE table TYPE (STANDARD);`
Database	`SELECT name FROM sysmaster:sysdatabases WHERE is_logging = 0;`	`ontape -s -L 0 -t /dev/null -U database`
Blob space	`SELECT name FROM sysmaster:sysdbspaces WHERE is_blobspace = 1;`	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.