Migrating a queue manager cluster

We can migrate queue managers in a cluster all at once, or one at a time, which is called a staged migration. Migrate full repository queue managers in a cluster before partial repository queue managers. We must consider what the effect is of migrating some queue managers in a cluster, before all the queue managers are migrated.

Before starting

Before starting the migration, check that no cluster-specific migration issues are identified for the migration we are intending to perform.

Consider the following issues that relate to migrating a queue manager cluster:

• Minimizing application outages.
• Measuring and verifying migration success and planning for backward migration if there are any migration problems.
• Taking advantage of new IBM MQ features
• Manage the migration of a cluster in the context of the wider IBM MQ network and the systems architecture of our organization.

About this task

Cluster queue managers can participate in clusters with other queue managers running at different versions, which is why a staged migration is possible. Being able to stage a migration is important, as migrating each queue manager in a cluster takes time. By staging the migration, which leaves other queue managers that are in the cluster running, you reduce the effect of queue manager downtime on applications.

Migrate queue managers with full repositories first. Then migrate the other queue managers, which have partial repositories, one at a time. Complete migration of the entire cluster before starting to use new functions.

If you do have to start using new functions before completing migration of the entire cluster, you might need to refresh the partial repositories. After each migration of a queue manager with a partial repository, issue the REFRESH CLUSTER command on the newly migrated queue manager. The command updates the cluster records in the newly migrated queue manager, potentially receiving updates for any new attributes. Do not do this step if we migrated the entire cluster before using new function. The REFRESH CLUSTER command takes a long time for all the changes to work through the cluster. Note: For large clusters, use of the REFRESH CLUSTER command can be disruptive to the cluster while it is in progress, and again at 27 day intervals thereafter when the cluster objects automatically send status updates to all interested queue managers. See Refreshing in a large cluster can affect performance and availability of the cluster.

If full repositories are not migrated before partial repositories, the cluster continues to work, but without all the new features in a version working as expected. To work predictably, the full repository queue managers must be at the new command level to be able to store information from the rest of the cluster that arises from using new features.

For example, the information might be a new channel attribute, such as shared conversations, which were introduced in Version 7.0. Information about the shared conversation attribute of a channel between two other Version 7.0.1 queue managers can be stored in a Version 7.0 full repository, but not in a Version 6.0 repository. If information about a channel with the shared conversation attribute is updated from the Version 6.0 full repository, the definition loses its shared conversation attribute. How mixed version cluster repositories are updated explains how information is updated in a mixed-version cluster.

Note: In exceptional circumstances, it might be necessary to upgrade some of our partial repositories before your full repositories.

While the product supports this configuration, in this situation be very careful to avoid use of any new clustering function on the partial repositories, until your full repositories have been upgraded, to avoid unexpected results.

• How mixed version cluster repositories are updated
  Repositories store records for an object in a cluster in the version of the record format that matches the version of the queue manager hosting the repository. Repository queue managers forward object records, before they are stored, in the format that they are received in. The recipient ignores fields from a newer version, and uses default values for fields that are not present in the record.
• Create a migration plan for a queue manager cluster
  Before carrying out the migration of a queue manager cluster, plan what we are going to do. Identify the roles that different queue managers play in the cluster, and decide in what order to migrate the queue managers.
• Create a backout plan for queue manager cluster migration
  Before performing a migration, decide on a backout plan in case of failure.
• Migrating one cluster queue manager
  Follow these steps to migrate a single queue manager in a cluster, starting with a queue manager in your test system. Base these steps on the cluster migration plan.

Parent topic: Migrating IBM MQ