High-availability cluster migration

You must coordinate the migration and reversion of all servers that are involved in high-availability clusters. You can use a rolling upgrade in some cases to update servers while the cluster is online, with minimal interruption to client applications. Otherwise, you must schedule cluster downtime to upgrade the servers. A cluster must be offline to reverse an upgrade or revert to an earlier release.

A rolling upgrade can minimize downtime, but the tradeoff is that you must spend time to prepare for a rolling upgrade. The effort to prepare your servers for a rolling upgrade depends on how closely your current configuration matches the procedure requirements. In some cases, you might find it easier to plan for downtime during a period of low activity instead of setting up your environment for a rolling upgrade. The downtime that is required depends on your system, but smaller clusters usually require less downtime.

Use the following table to help you determine which upgrade procedure to use. Also, review the requirements and limitations that are documented in each procedure.

Table 1. Comparison of upgrade procedures for high-availability clusters
Upgrade to Procedure Use Procedure overview
Next consecutive fix pack or PID of the same major version Rolling upgrade of an online cluster to the next fix pack or PID (UNIX, Linux) You can apply the next consecutive fix pack or interim fix (PID) of the same major version to all the servers while the cluster remains online. You must stop and restart each server in the cluster, including the primary. 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. Interruption to client applications is minimized because transactions are redirected to active servers by Connection Manager or through the client applications. The new database server capabilities can be used in the cluster after all servers are upgraded.
Any later fix pack or PID of the same major version Upgrading an offline cluster to a fix pack or PID You can use this procedure within a major version to apply a fix pack or PID in offline clusters in the following situations:
  • Your cluster does not meet the requirements for a rolling upgrade.
  • The limitations that are imposed by a rolling upgrade are impractical for your environment.
  • You prefer or need to bring the servers in the cluster offline before you upgrade them.
 You stop all servers in the cluster during a period when downtime is acceptable. While the cluster if offline, you upgrade all the servers. You then start the primary followed by the secondary servers. You don't have to rebuild the cluster or clone the servers.
New major version

A fix pack or PID that requires conversion

 Migrating an offline cluster to a new major version You can use this procedure to migrate the servers in your offline cluster to a new major version. For example, you can migrate from HCL Informix to HCL OneDB 2.0.0.0.

Also, you can use this procedure to apply a fix pack or PID that requires standard conversion procedures. Usually conversion is not required for a fix pack or PID. The machine notes indicate whether conversion is required.

 You stop the servers in a specific order during a period when planned downtime is acceptable. Then, if you are migrating from HCL Informix, you stop all servers in the cluster during a period when downtime is acceptable. While the cluster if offline, you upgrade all the servers. You then start the primary followed by the secondary servers. You don't have to rebuild the cluster or clone the servers.
Any supported release Rolling upgrade of an online cluster with Enterprise Replication This alternative rolling upgrade procedure requires a working knowledge of Enterprise Replication. You can use this procedure to upgrade online clusters to any supported product release. You can use this procedure to upgrade to a new major version or to apply any fix pack or PID (not just the next consecutive one) within a release. This procedure is more flexible than the other rolling upgrade procedure; however, it is more complex to set up. You temporarily convert the primary and secondary servers to stand-alone Enterprise Replication servers. The upgrade occurs without incurring any downtime because Enterprise Replication supports replication between different versions of the server software.