Migrating a queue manager cluster

You 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. You must consider what the effect is of migrating some queue managers in a cluster, before all the queue managers are migrated.

Before you begin

Before starting the migration, check that no cluster-specific migration issues are identified for the migration you 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
  • Managing the migration of a cluster in the context of the wider IBM MQ network and the systems architecture of your 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 you 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 running the latest IBM MQ major version (for LTS users) or CD version (for CD users). This ensures that the full repositories can store information from the rest of the cluster that arises from using new features.

Note: In exceptional circumstances, it might be necessary to upgrade some of your 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.