Preparing to migrate, upgrade, or revert clusters

If you use high-availability clusters, you must coordinate the migration of all of the servers that are involved in a high-availability cluster, and you must perform additional steps when preparing to migrate.

Prerequisites:

Perform all migration operations as user informix.
Download the product package from IBM® Passport Advantage® at http://www.ibm.com/software/howtobuy/passportadvantage, or download recommended fixes for server products.
If you are migrating to a new version of the server, complete all steps in Preparing for migration.

To prepare for migration or reversion of a cluster:

Prepare each server in the cluster:
1. Install the target server software in a different location from where the source database server software is installed. Do not install the target server software over the source server.
  Tip: Install the new version of IBM Informix® Client Software Development Kit (Client SDK), which contains the Connection Manager that you must use with the new version of the server. If you want to use only the Connection Manager from the new version of Client SDK, install Client SDK in a new location and use the Connection Manager from that location.
2. Copy the onconfig and sqlhosts configuration files to the target installation directory (for example, $INFORMIXDIR/etc).
3. Install on the target server any user-defined objects or DataBlade modules that are used on the source server.
Back up your primary server. You can perform this step in the following ways:
- Use ON–Bar or ontape to make a level-0 backup on the primary source server.
- If you have a high-availability cluster with a High-availability Data Replication (HDR) secondary server, you can use the HDR secondary server as a standby server for any contingencies that occur while you upgrade the primary server. However, if it is necessary to use an HDR secondary server as a standby server for contingencies, do not perform updates on the standby server while migration or reversion is in progress, because the updates cannot be replicated and will be lost. Additionally, nonlogged objects on the primary server will not exist on the secondary server.
  Attention: Do not use RS secondary servers as backup servers, because transactions could be lost.