Removing a queue manager from a cluster

Remove a queue manager from a cluster, in scenarios where the queue manager can communicate normally with at least one full repository in the cluster.


Before starting

This method is the best practice for scenarios in which at least one full repository is available, and can be contacted by the queue manager that is being removed. This method involves the least manual intervention, and allows the queue manager to negotiate a controlled withdrawal from the cluster. If the queue manager that is being removed cannot contact a full repository, see Removing a queue manager from a cluster: Alternative method.

Before you remove the queue manager from the cluster, we must ensure that the queue manager is no longer hosting resources that are needed by the cluster:

  • If the queue manager hosts a full repository, complete steps 1-6 from Moving a full repository to another queue manager. If the full repository functionality of the queue manager to be removed is not to be moved to a different queue manager, it is only necessary to complete steps 5 and 6.
  • If the queue manager hosts cluster queues, complete steps 1-7 from Removing a cluster queue from a queue manager.
  • If the queue manager hosts cluster topics, either delete the topics (for example by using the DELETE TOPIC command), or move them to other hosts as described in Moving a cluster topic definition to a different queue manager. Note: If you remove a queue manager from a cluster, and the queue manager still hosts a cluster topic, then the queue manager might continue to attempt to deliver publications to the queue managers that are left in the cluster until the topic is deleted.


About this task

This example task removes the queue manager LONDON from the INVENTORY cluster. The INVENTORY cluster is set up as described in Adding a queue manager to a cluster, and modified as described in Removing a cluster queue from a queue manager.

The process for removing a queue manager from a cluster is more complicated than the process of adding a queue manager.

When a queue manager joins a cluster, the existing members of the cluster have no knowledge of the new queue manager and so have no interactions with it. New sender and receiver channels must be created on the joining queue manager so that it can connect to a full repository.

When a queue manager is removed from a cluster, it is likely that applications connected to the queue manager are using objects such as queues that are hosted elsewhere in the cluster. Also, applications that are connected to other queue managers in the cluster might be using objects hosted on the target queue manager. As a result of these applications, the current queue manager might create additional sender channels to establish communication with cluster members other than the full repository that it used to join the cluster. Every queue manager in the cluster has a cached copy of data that describes other cluster members. This might include the one that is being removed.


Procedure

  1. Alter the manually defined cluster receiver channels to remove them from the cluster, on queue manager LONDON: 
    ALTER CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSRCVR) CLUSTER(' ')
  2. Alter the manually defined cluster sender channels to remove them from the cluster, on queue manager LONDON: 
    ALTER CHANNEL(INVENTORY.PARIS) CHLTYPE(CLUSSDR) CLUSTER(' ')

    The other queue managers in the cluster learn that this queue manager and its cluster resources are no longer part of the cluster.

  3. Monitor the cluster transmit queue, on queue manager LONDON, until there are no messages that are waiting to flow to any full repository in the cluster. 
    DISPLAY CHSTATUS(INVENTORY.LONDON) XQMSGSA

    If messages remain on the transmit queue, determine why they are not being sent to the PARIS and NEWYORK full repositories before continuing.


Results

The queue manager LONDON is no longer part of the cluster. However, it can still function as an independent queue manager.


What to do next

The result of these changes can be confirmed by issuing the following command on the remaining members of the cluster: 
DISPLAY CLUSQMGR(LONDON)
The queue manager continues to be displayed until the auto-defined cluster sender channels to it have stopped. We can wait for this to happen, or, continue to monitor for active instances by issuing the following command: 
DISPLAY CHANNEL(INVENTORY.LONDON)
When we are confident that no more messages are being delivered to this queue manager, we can stop the cluster sender channels to LONDON by issuing the following command on the remaining members of the cluster: 
STOP CHANNEL(INVENTORY.LONDON) STATUS(INACTIVE)
After the changes are propagated throughout the cluster, and no more messages are being delivered to this queue manager, stop and delete the CLUSRCVR channel on LONDON: 
STOP CHANNEL(INVENTORY.LONDON)
DELETE CHANNEL(INVENTORY.LONDON)

The removed queue manager can be added back into the cluster at a later point as described in Adding a queue manager to a cluster. The removed queue manager continues to cache knowledge of the remaining members of the cluster for up to 90 days. If you prefer not to wait until this cache expires, it can be forcibly removed as described in Restoring a queue manager to its pre-cluster state.

Parent topic: Configure a queue manager cluster