Availability, recovery and restart
Make your applications highly available by maintaining queue availability if a queue manager fails, and recover messages after server or storage failure.
Improve client application availability by using client reconnection to switch a client automatically between a group of queue managers, or to the new active instance of a multi-instance queue manager after a queue manager failure. Automatic client reconnect is not supported by IBM® MQ classes for Java.
Improve server application availability on z/OS® by using queue sharing groups.
On Windows, IBM i, UNIX, and Linux® platforms deploy server applications to a multi-instance queue manager, which is configured to run as a single queue manager on multiple servers; if the server running the active instance fails, execution is automatically switched to a standby instance of the same queue manager on a different server. If you configure server applications to run as queue manager services, they are restarted when a standby instance becomes the actively running queue manager instance.
You can configure IBM MQ as part of a platform-specific clustering solution such as Microsoft Cluster Server, HA clusters on IBM i, or PowerHA® for AIX® (formerly HACMP on AIX ) and other UNIX and Linux clustering solutions.
Another way to increase server application availability is to deploy server applications to multiple computers in a queue manager cluster.
A messaging system ensures that messages entered into the system are delivered to their destination. IBM MQ can trace the route of a message as it moves from one queue manager to another using the dspmqrte command. If a system fails, messages can be recovered in various ways depending on the type of failure, and the way a system is configured.
- Restart recovery, when you stop IBM MQ in a planned way.
- Failure recovery, when a failure stops IBM MQ.
- Media recovery, to restore damaged objects.
In all cases, the recovery restores the queue manager to the state it was in when the queue manager stopped, except that any in-flight transactions are rolled back, removing from the queues any updates that were in-flight at the time the queue manager stopped. Recovery restores all persistent messages; nonpersistent messages might be lost during the process.