Migrating a high-availability cluster queue manager

Follow the steps listed to migrate a queue manager in a high-availability queue manager configuration.

Before you begin

The following terms are relevant:
active server
The running server or active queue manager instance
passive server
A server that is ready to take over from the active server automatically.
inactive server
A server that is not prepared to take over automatically. The server might have been removed from the cluster, or taken offline in some way.

Procedure

Base your migration procedure on the following steps. The details depend on the specific commands in the cluster concerned.

  1. Before you start the migration process, create a different queue manager on a server on which you have installed the upgrade.
  2. Test the upgrade by performing whatever verification checks that your enterprise requires.
  3. Form two cluster pairs if you have four servers available.
    With two pairs, the queue manager can continue to run in a cluster-pair at the old command level. When you are ready, you can transfer the queue manager to the pair of servers at the new command level.
  4. Remove a passive server from the cluster.
    Ensure that the cluster cannot automatically restart the server. The server is made inactive.
  5. Create a second location for the upgraded code, if a high-availability cluster is using a common location for IBM® MQ code.
  6. Install, or upgrade, IBM MQ code using the server that is not now running the queue manager.
  7. Verify the upgrade by creating a different queue manager on the server, and performing whatever verification checks that your organization requires.
  8. If more than half the servers remain in the cluster, remove a server, upgrade IBM MQ, and verify the upgrade.
    Each server is made inactive as part of the process. Continue until half the servers are upgraded.
  9. If your active server is part of a remaining cluster, deactivate the passive servers so that the cluster cannot reactivate them automatically.
  10. Decide whether downtime or recoverability is more important in the migration.
  11. Optional: Follow this procedure if recoverability is more important:
    1. Stop the queue manager and remove the server from the cluster.
    2. Back up the queue manager.
  12. Optional: Follow this procedure if downtime is more important:
    1. Add the migrated servers back into the cluster, as passive servers.
    2. Switch the remaining server in the high-availability server cluster over to one of the passive servers.
      The switch causes the running queue manager to stop, and restarts it on one of the passive servers.
  13. Upgrade any remaining high-availability servers, and add them back into the cluster.