Question & Answer
Question
You have one IBM MQ multi-instance queue manager at MQ 9.1 in both hosts.
Now you want to perform an upgrade / migration (in multiples stages) of each host to MQ 9.3 and you want to minimize the downtime of the queue manager and MQ client applications connected to the queue manager.
Now you want to perform an upgrade / migration (in multiples stages) of each host to MQ 9.3 and you want to minimize the downtime of the queue manager and MQ client applications connected to the queue manager.
.
You have ONLY one installation of MQ and you want to replace MQ 9.1 with MQ 9.3. That is, you do not want to have multiple installations.
.
If you have several queue managers in the Host where the upgrade will take place, then ALL of the queue managers will be affected by the upgrade. That is, ALL of them will need to be stopped before proceeding to do the upgrade.
Answer
One of the key benefits for using MQ multi-instance queue managers is that the "downtime" for MQ client applications is minimized when doing maintenance activities on the queue manager (or the host that has the queue manager). This is accomplished by:
.
- Ending the Active instance with:
endmqm -si QmgrName
The flags -si perform a switchover and allow the reconnectable clients to reconnect.
.
- Using connectionNameList (via CCDT, MQSERVER, hard coded, etc) with the MQ client application and specify the hostname/IPaddress and port, for both of the instances. This will exploit the automatic client reconnection feature and when the Active is terminated and the switchover takes place, then the MQ client can reconnect to the new Active (previously running as Standby).
.
+ Important notes about what CANNOT be done:
.
1) After step (e), the queue manager in Host-1 will be upgraded from MQ 9.1 to MQ 9.3 when the standby instance becomes the active. This process is NOT reversible. The active queue manager is now at version 9.3 and not at version 9.1.
.
2) Until you upgrade Host-2 you will NOT be able to do a switch over from Host-1 to Host-2. So, if you do NOT upgrade Host-2 in a timely manner (let's say, for several days/weeks) and if you keep it at MQ 9.1, then you will NOT be able to do a switch over from Host-1 to Host-2, because a queue manager that was upgraded to 9.3, will NOT work under 9.1
You will need to upgrade the level of MQ in Host-2 to 9.3 in order to run the queue manager as a standby to allow a switch over from Host-1 to Host-2.
.
+ Steps
.
The following is an example of a multi-staged upgrade of multi-instance queue managers. This example is generic enough that it applies to any level from 9.1 and higher, going to 9.3.
This example uses 9.1 for illustration purposes.
.
The main objective is to upgrade Host-1 as soon as possible.
.
Relevant terms
- Active queue manager instance: A queue manager instance that has been started permitting standby instances, and is running.
- Standby queue manager instance: A queue manager instance that has been started permitting standby instances, and is in standby. It is ready to take over from the active instance automatically.
.
a) Assuming that you have the following as a starting point for your migration:
Host-1: MQ 9.1 (active)
Host-2: MQ 9.1 (standby)
.
b) Stop ALL the MQ activities (clients and queue managers) in Host-1. For queue managers use "endmqm -si qmgr" to do a switchover and allow the reconnectable clients to reconnect.
This will cause in Host-2 that the Standby instance will become active. Clients that are able to reconnect, will detect the switchover and reconnect to the new Active instance in Host-2.
Host-1: MQ 9.1 (stopped)
Host-2: MQ 9.1 (active)
.
c) Upgrade Host-1 to 9.3:
Host-1: MQ 9.3 (no instance started yet)
Host-2: MQ 9.1 (active)
.
c.1) In Host-1 you will need to setup the newly installed MQ 9.3 as "primary" installation.
As user "root" you will need to run the following command.
AIX: /usr/mqm/bin/setmqinst -i -p /usr/mqm
Other Unix: /opt/mqm/bin/setmqinst -i -p /opt/mqm
.
d) Start the standby instance in Host-1 by using "strmqm -x qmgr". Notice that the clients are still connected to the active instance running in Host-2.
Host-1: MQ 9.3 (standby)
Host-2: MQ 9.1 (active)
.
e) Stop ALL the MQ activities (clients and queue managers) in Host-2. For queue managers
.
- Ending the Active instance with:
endmqm -si QmgrName
The flags -si perform a switchover and allow the reconnectable clients to reconnect.
.
- Using connectionNameList (via CCDT, MQSERVER, hard coded, etc) with the MQ client application and specify the hostname/IPaddress and port, for both of the instances. This will exploit the automatic client reconnection feature and when the Active is terminated and the switchover takes place, then the MQ client can reconnect to the new Active (previously running as Standby).
.
+ Important notes about what CANNOT be done:
.
1) After step (e), the queue manager in Host-1 will be upgraded from MQ 9.1 to MQ 9.3 when the standby instance becomes the active. This process is NOT reversible. The active queue manager is now at version 9.3 and not at version 9.1.
.
2) Until you upgrade Host-2 you will NOT be able to do a switch over from Host-1 to Host-2. So, if you do NOT upgrade Host-2 in a timely manner (let's say, for several days/weeks) and if you keep it at MQ 9.1, then you will NOT be able to do a switch over from Host-1 to Host-2, because a queue manager that was upgraded to 9.3, will NOT work under 9.1
You will need to upgrade the level of MQ in Host-2 to 9.3 in order to run the queue manager as a standby to allow a switch over from Host-1 to Host-2.
.
+ Steps
.
The following is an example of a multi-staged upgrade of multi-instance queue managers. This example is generic enough that it applies to any level from 9.1 and higher, going to 9.3.
This example uses 9.1 for illustration purposes.
.
The main objective is to upgrade Host-1 as soon as possible.
.
Relevant terms
- Active queue manager instance: A queue manager instance that has been started permitting standby instances, and is running.
- Standby queue manager instance: A queue manager instance that has been started permitting standby instances, and is in standby. It is ready to take over from the active instance automatically.
.
a) Assuming that you have the following as a starting point for your migration:
Host-1: MQ 9.1 (active)
Host-2: MQ 9.1 (standby)
.
b) Stop ALL the MQ activities (clients and queue managers) in Host-1. For queue managers use "endmqm -si qmgr" to do a switchover and allow the reconnectable clients to reconnect.
This will cause in Host-2 that the Standby instance will become active. Clients that are able to reconnect, will detect the switchover and reconnect to the new Active instance in Host-2.
Host-1: MQ 9.1 (stopped)
Host-2: MQ 9.1 (active)
.
c) Upgrade Host-1 to 9.3:
Host-1: MQ 9.3 (no instance started yet)
Host-2: MQ 9.1 (active)
.
c.1) In Host-1 you will need to setup the newly installed MQ 9.3 as "primary" installation.
As user "root" you will need to run the following command.
AIX: /usr/mqm/bin/setmqinst -i -p /usr/mqm
Other Unix: /opt/mqm/bin/setmqinst -i -p /opt/mqm
.
d) Start the standby instance in Host-1 by using "strmqm -x qmgr". Notice that the clients are still connected to the active instance running in Host-2.
Host-1: MQ 9.3 (standby)
Host-2: MQ 9.1 (active)
.
e) Stop ALL the MQ activities (clients and queue managers) in Host-2. For queue managers
use "endmqm -si qmgr" to do a switchover and allow the reconnectable clients to reconnect.
This will cause the Standby instance in Host-1 to become active. Clients that are able to reconnect, will detect the switchover and reconnect to the new Active instance in Host-1.
Host-1: MQ 9.3 (active)
Host-2: MQ 9.1 (stopped)
.
f) Upgrade Host-2 to 9.3:
Host-1: MQ 9.3 (active)
Host-2: MQ 9.3 (no instance started yet)
.
f.1) In Host-2 you will need to setup the newly installed MQ 9.3 as "primary" installation.
As user "root" you will need to run the following command.
AIX: /usr/mqm/bin/setmqinst -i -p /usr/mqm
Other Unix: /opt/mqm/bin/setmqinst -i -p /opt/mqm
.
g) Start the standby instance in Host-2. Notice that the clients are still connected to the active instance running in Host-1.
Host-1: MQ 9.3 (active)
Host-2: MQ 9.3 (standby)
Host-1: MQ 9.3 (active)
Host-2: MQ 9.1 (stopped)
.
f) Upgrade Host-2 to 9.3:
Host-1: MQ 9.3 (active)
Host-2: MQ 9.3 (no instance started yet)
.
f.1) In Host-2 you will need to setup the newly installed MQ 9.3 as "primary" installation.
As user "root" you will need to run the following command.
AIX: /usr/mqm/bin/setmqinst -i -p /usr/mqm
Other Unix: /opt/mqm/bin/setmqinst -i -p /opt/mqm
.
g) Start the standby instance in Host-2. Notice that the clients are still connected to the active instance running in Host-1.
Host-1: MQ 9.3 (active)
Host-2: MQ 9.3 (standby)
+++ Related technote
https://www.ibm.com/support/pages/node/6220974
Staged application of fix packs of IBM MQ multi-instance queue managers
Staged application of fix packs of IBM MQ multi-instance queue managers
+++ Related tutorial
https://www.ibm.com/support/pages/node/6982723
Installing IBM MQ 9.3 to coexist with MQ 9.1 in Windows and applying Fix Packs
Installing IBM MQ 9.3 to coexist with MQ 9.1 in Windows and applying Fix Packs
+++ end +++
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
23 April 2023
UID
ibm11284952