Abstract
Buffered logging with Informix Dynamic Server (IDS) can significantly improve throughput on systems where a second or two of data loss could be tolerated in the event of a system crash. We recently wanted to make this change on a version 14.10.FC11 cluster with a primary and two active read-only replicas each using one of these protocols:
- High-availability Data Replication (HDR) – local
- Remote Standalone Secondary (RSS) – remote
The application is a 24×7 public service, and only a short break in service could be tolerated. The instance has around 1.5TB used pages, so we needed to have the replication state preserved without needing to perform any restore. That was a problem as IDS usually only allows a change of logging if there are no replicas. This article explains how it was achieved. The same technique can be used for the reverse change.
Content
The problem was reproduced – and a solution devised and tested – with IDS 14.10.FC12W12 Developer Edition from Fix Central, which was the latest at the time, installed in a Rocky 9 Docker container as described here. The necessary steps were evolved and automated in this test environment. For the live change, production Informix server names were substituted and commands were selectively entered manually on the relevant hosts in turn, but otherwise the technique worked perfectly entirely unchanged.
Firstly, remember that, for RSS, configuration parameter LOG_INDEX_BUILDS must be set to 1 on the primary before the level 0 archive is created that will be used to rebuild the replicas:
You can use this command:
Secondly, for buffered logging, you must set a minimum interval between log buffer flushes to reduce data loss in the event of a crash during idle periods. This is defined with configuration parameter LOGBUF_INTVL:
We recommend reducing it to the minimum of 1 second. You can use this command:
The documentation says you need to restart the instance for the above to be effective, which is incorrect: the above command does work and is effective immediately.
A set of databases can be changed to buffered logging as in this example:
The first “-s” option means to “save” an archive (instance backup). When you set the backup device to the special case “/dev/null”, it understands not to perform an actual archive. The ontape logging options are:
| -N | No logging |
| -U | Unbuffered logging |
| -B | Buffered logging |
| -A | ANSI logging |
The databases involved must not be in use while changing logging mode, or you get an error like this:
The full details of that error number are:
The simplest way to gain exclusive access is Administration mode (only user “informix” can be connected by default).
If you try to enable buffered logging directly on a primary with replicas, the standard command and result are as follows:
The full details of that error number are:
Assuming that “stores_demo” currently has unbuffered logging, that might be considered a defect: there is no good reason that couldn’t be changed in flight. However, you can understand why changing from unlogged should be refused with replicas defined.
To prove the solution, the following shell script was used to set up 3 test instances in a state comparable to the live systems before the change:
That uses these utilities:
A trick is necessary to create a high-availability cluster on the same host for testing purposes. A replica must have the same chunk device paths as the primary, but must also have its own storage. This is possible by using relative paths, and starting the instances while in different directories containing “cooked” chunks in the file system. That’s why the “cluster” script above changes directory as well setting the required environment variables.
The “all” script runs a command against all three instances after setting the instance with “cluster” in each case.
Beforehand, empty chunk files were created in advance in each location as user “informix” with the required permissions, for example:
Distinct TCP ports were set for each instance (* means listen on every IP address):
Only 3 parameters needed to be different in each configuration file, for example:
Other essential differences from the standard configuration for the test to work were:
The following script switches specified databases to or from buffered logging in the cluster:
For example:
It’s as simple as that: it works fine as long as the replicas are stopped and undefined for the change. No restore is required, and the whole process should take less than a minute.
To roll back the change and have unbuffered logging again, change “-B” above to “-U”.
Conclusion
This article provides a way to change the logging mode of selected databases in a replication cluster between unbuffered and buffered with a very short downtime.
Caveats
To create a high-availability cluster, old and new hosts must be networked together, running the same IDS version, and trusted for user “informix”.
The backup mechanism is assumed to be ontape to a directory. You may need to replace those commands with onbar equivalents if using the Informix Primary Storage Manager (PSM) or similar third party product.
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.
Contact Us
If you have any questions or would like to find out more about this topic, please contact us.
