WebSphere® MQ supports the creation of a multi-instance queue manager. A multi-instance queue manager restarts a WebSphere MQ (MQSeries) server instance automatically on a standby server when the active instance goes down.
For the use case described in this topic:
It is important to take into account the time required for the standby instance of a multi-instance queue manager to become active after the active instance becomes unavailable. Preliminary tests indicate that the required time may vary between 30 seconds and two minutes, depending on configuration and reason for failure.
To use a WebSphere MQ queue manager as a multi-instance queue manager:
crtmqm
command to create a single queue manager on one of the servers. addmqinf
command to create a reference to the queue manager data and logs on the network storage.After you install the MQ multi-instance queue manager, you must configure Activator to use the multiple instances. To do this you can create a new pickup or modify an existing pickup.
Alternatively, you can add the multi-queue instance to an existing IBM MQ pickup. To do this:
Activator tries to send or receive every message to the last functional WebSphere MQ (MQSeries) server. WebSphere MQ has a cache where the status for each exchange point is registered. If the primary instance crashes, Activator automatically tries to connect to the standby instance. If the standby is not running, the message is re-queued. The message is then held for a new retry. This provides time for the standby instance to become active. If the standby is still not available, the message goes through additional re-queue and retries. The time between the retries increases for each queue/retry cycle. When the maximum number of retries is reached (defined in the queue manager configuration), the message is rejected.
During the period when neither of the WebSphere MQ server instances is available, Activator tries to connect to the primary and to the secondary server on each retry. After a connection is successfully made to a server instance, the WebSphere MQ cache is updated. In the cache, the last functional host for the exchange point is specified, so that all future messages are exchanged directly with the active WebSphere MQ server.