Rolling upgrade of an online cluster to the next fix pack or PID (UNIX, Linux)

About this procedure

This rolling upgrade procedure works only on UNIX and Linux platforms. Use this procedure to apply the next consecutive fix pack or PID in the current major version. For example, you can do a rolling upgrade from 12.10.xC4 to 12.10.xC5. Otherwise, you must use a different procedure that is documented at High-availability cluster migration.

Do not use this procedure in the following situations:

• To apply a fix pack or PID that requires conversion.
• To upgrade to 12.10.xC5 from 12.10.xC3, 12.10.xC2, or 12.10.xC1.
• To upgrade an earlier major version of the server to a later major version of the database server, for example, to upgrade from version 11.70 to 12.10.
• To upgrade from a patch release or special build, unless advised to do so by HCL Software Support.

You must stop and restart each server in the cluster, including the primary, as part of this procedure. Specifically, you upgrade each secondary server, and then you stop the primary server and promote an upgraded secondary server to primary. Next, you upgrade the original primary server, bring it online as a secondary server, and promote it back to primary, if necessary.

You must have the following permission on all the servers in the cluster: user root or user informix.

Prepare for a rolling upgrade

Use the following steps to plan for and prepare the servers for rolling upgrade:

1. Complete the steps in Preparing to migrate, upgrade, or revert clusters, which include installing the new software on all the servers in the cluster, copying the appropriate configuration files, and backing up the primary server.

2. Configure client redirection to minimize interruption of service.

   Set up redirection and connectivity for clients by using the method that works best for your environment.

   If Connection Manager controls the connection redirection in the cluster: Ensure that every service level agreement (SLA) definition in the Connection Manager configuration file can redirect to at least one server other than the one you are about to update. For example, assume that you have an SLA with only one secondary. Before you upgrade the secondary server in that SLA, update the SLA to include the cluster primary (PRI).

3. Ensure that the primary server has an appropriate amount of disk space for the logical log records that are created during the entire upgrade process. The space that is required depends on your environment.

   Attention: If a log wrap occurs during the rolling upgrade procedure, you must apply the fix pack or PID while the cluster is offline.
   Tip: Examine the online log to get an estimate of your data activity during normal operations. You might want to ensure that you have enough space for data activity for a day. Also, you might find it convenient to plan the rolling upgrade for a period of low traffic.

4. Prepare the secondary server that will become the primary when you upgrade the original primary server. You must use an SD secondary or a fully synchronous HDR secondary server that has transactional consistency with the original primary server.

   1. If the cluster contains an SD secondary server, you don't need to do any additional preparation to that server.
   2. If the cluster contains an HDR secondary server, make sure that it runs in fully synchronous (SYNC) mode.
   3. If the cluster contains only RS secondary servers in addition to the primary server, you must change one of the RS secondary servers to an HDR secondary server in SYNC mode.

Upgrade the servers

1. Run the onmode -c command to force a checkpoint for each server.

2. If a wire listener is running on the server that you want to upgrade, stop that wire listener.

3. Stop the server that you want to upgrade. If you can wait for all connections to exit gracefully before stopping the server, use the onmode -kuy command. Otherwise, use the onmode -ky command to stop the server.

   • When you stop a secondary server: If redirection is configured for the cluster, the client application automatically connects to another active server in the cluster.
   • When you stop the primary server: If failover is configured for the cluster, a secondary server is promoted automatically to primary. Otherwise, you can run the onmode -d make primary command to promote a prepared secondary server to primary.
     Tip: If the primary is offline before the failover, you must use the onmode -d make primary force command.

4. Set your environment to use the fix pack or PID that you installed on the server.

   1. Set the INFORMIXDIR environment variable to the full path name for the target installation.
   2. Update all environment variables that depend on the INFORMIXDIR environment variable. At a minimum, update these environment variables: PATH, DBLANG, INFORMIXSQLHOSTS, and any platform-specific library path environment variables, such as LD_LIBRARY_PATH.

5. Start the upgraded server.

   To start an upgraded secondary server: Use the oninit command.

   To start an upgraded original primary server: Start the original primary server as a secondary server. For convenience, start it as the server type that was promoted to primary during the rolling upgrade. For example, if you promoted an HDR server to primary for the rolling upgrade, start the original primary as an HDR secondary server.

   • To start the upgraded server as an SD secondary server, run the oninit -SDS command.
   • To start the upgraded server as an HDR secondary server, run the oninit -PHY command, and then run the following command: onmode -d secondary primary_server secondary_server

   After the server starts, it runs the new version of the software and automatically reconnects to the cluster.

6. To verify that the upgraded secondary server is active in the cluster, run the onstat -g cluster command on both the server you upgraded and on the primary server.

7. If you stopped the wire listener to upgrade this server, restart the wire listener.

After you upgrade all the servers and restart them, the original primary server is running as a secondary server.

Return the cluster to its original configuration

Use the following steps if you want the cluster to operate as it did before you prepared it for a rolling upgrade.

1. Manually promote the secondary server that was the original primary to be the primary server again.

   1. Run the onmode -c command to force a checkpoint.
   2. Run the onmode -d make primary command to promote the secondary server to primary.

2. Undo any changes that you made when you prepared the servers for a rolling upgrade. Some of these optional steps might not apply to you.

   • Adjust the amount of disk space that is allocated for logical log records.
   • Convert the HDR secondary server back to an RS secondary server.
   • Change the HDR secondary server back to ASYNC mode from SYNC mode.
   • Change the Connection Manager SLA definitions.