Home
Migrating and upgrading
You can upgrade to the 14.10 release of HCL Informix® or migrate from other database servers to Informix. Upgrading is an in-place migration method that uses your existing hardware and operating system software. Some changes to the Informix database server can affect upgrading from a previous release.
Migrating Informix® database systems
The Informix® Migration Guide describes how to move data manually between databases, servers, and computers.
Migration to and reversion from 14.10
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.
Restoring clusters to a consistent point
You can restore the primary server in a high-availability cluster to a consistent point after a failed upgrade.

Migrating and upgrading
You can upgrade to the 14.10 release of HCL Informix® or migrate from other database servers to Informix. Upgrading is an in-place migration method that uses your existing hardware and operating system software. Some changes to the Informix database server can affect upgrading from a previous release.
- Migrating Informix® database systems
  The Informix® Migration Guide describes how to move data manually between databases, servers, and computers.
  - Overview of migration
  - Migration to and reversion from 14.10
    - Preparing for migration to Version 14.10
      Before you install the new version of Informix®, you must prepare the database server environment for migration by performing specified pre-migration tasks. If you are also migrating from 32-bit to 64-Bit database servers, you must perform additional tasks.
    - Enterprise Replication and migration
      You must coordinate the migration of all servers that are involved in data replication.
    - 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.
      - 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.
      - Rolling upgrade of an online cluster to the next fix pack or PID (UNIX, Linux)
        As of Informix® 12.10.xC5, you can apply the next consecutive fix pack or interim fix (PID) to your current version of the database server. During the rolling upgrade, the cluster remains online even though the servers in the cluster run different levels of the software. The new capabilities can be used in the cluster after all the servers in the cluster are upgraded.
      - Upgrading an offline cluster to a fix pack or PID
        You can bring a high-availability cluster offline to apply any PID or fix pack of the same version of the database server. For example, you must bring the clusters offline to upgrade the servers to the current fix pack if earlier fix packs were not applied to the server. This procedure is an alternative to the rolling upgrade procedure.
      - Migrating an offline cluster to a new major version
        If you are migrating from Informix 11.70 or later version to 14.10xC4 or later version, 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 need not rebuild the cluster or clone the servers.
      - Rolling upgrade of an online cluster with Enterprise Replication
        You can perform a rolling upgrade in a high-availability cluster by temporarily converting 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. You can use this approach to upgrade to a new major version, or to apply fix packs or interim fixes (PIDs).
      - Reverting clusters
        If you have a high-availability cluster, you must complete additional tasks when you revert from the new version of Informix®. You must revert only the primary database server.
      - Restoring clusters to a consistent point
        You can restore the primary server in a high-availability cluster to a consistent point after a failed upgrade.
      - Restoring a cluster from a backup archive
        If you backed up the primary server before you migrated or reverted the cluster, you can restore the primary server from the backup archive if migration or reversion fails. After you restore the primary server, you must recreate the other servers in the high-availability cluster.
      - Restoring a cluster from the HDR secondary server
        You can restore the primary server from the High-availability Data Replication (HDR) secondary server that you prepared to use as a backup server before you migrated or reverted the cluster. After you restore the primary server, you must recreate the other servers in the high-availability cluster.
    - Migrating to Informix® 14.10
      When you migrate to a new version of Informix®, you must complete required migration and post-migration tasks.
    - Reverting from Informix® Version 14.10
      You can revert to the version of the database server from which you migrated. When you run the reversion utility, you specify the target server for reversion and then Informix® checks your database. If necessary, Informix might tell you to drop new objects, before automatically converting your data into the target server.
  - Migration of data between database servers
  - Data migration utilities

Restoring clusters to a consistent point

You can restore the primary server in a high-availability cluster to a consistent point after a failed upgrade.

Before you begin

Prerequisites:

Before you began the upgrade, you must have enabled quick reversion, according to information in Configuring for recovery of restore point data in case an upgrade fails.
The server must be offline.

About this task

Procedure

To restore the primary server in a cluster to a consistent point after a failed upgrade:

Run the onrestorept utility. For more information, see Restoring to a previous consistent state after a failed upgrade.

What to do next

Alternatively, if you backed up your primary server or you prepared for using the High-availability Data Replication (HDR) secondary server as a backup server before you upgraded and the upgrade fails, you can take other steps to restore the cluster. See Restoring a cluster from a backup archive or Restoring a cluster from the HDR secondary server.