Home

 

RESET CLUSTER

 

You are unlikely to need to use this command, except in exceptional circumstances. Use the RESET CLUSTER command to forcibly remove a queue manager from a cluster. We can do this from a full repository queue manager by issuing either the command:

RESET CLUSTER(clustername) QMNAME(qmname) ACTION(FORCEREMOVE)  QUEUES(NO)
or the command:
RESET CLUSTER(clustername) QMID(qmid) ACTION(FORCEREMOVE)  QUEUES(NO)
We cannot specify both QMNAME and QMID.

Specifying QUEUES(NO) on a RESET CLUSTER command is the default. Specifying QUEUES(YES) means that reference to cluster queue or queues owned by the queue manager being force removed are removed from the cluster in addition to the cluster queue manager itself. The cluster queues are removed even if the cluster queue manager is not visible in the cluster, perhaps because it was previously force removed without the QUEUES option.

You might use the RESET CLUSTER command if, for example, a queue manager has been deleted but still has cluster-receiver channels defined to the cluster. Instead of waiting for WebSphere MQ to remove these definitions (which it does automatically) we can issue the RESET CLUSTER command to tidy up sooner. All other queue managers in the cluster are then informed that the queue manager is no longer available.

In an emergency where a queue manager is temporarily damaged, you might want to inform the rest of the cluster before the other queue managers try to send it messages. RESET CLUSTER can be used to remove the damaged queue manager. Later when the damaged queue manager is working again, we can use the REFRESH CLUSTER command to reverse the effect of RESET CLUSTER and put it back in the cluster again.

Using the RESET CLUSTER command is the only way to delete auto-defined cluster-sender channels. You are unlikely to need this command in normal circumstances, but your IBM Support Center might advise you to issue the command to tidy up the cluster information held by cluster queue managers. Do not use this command as a short cut to removing a queue manager from a cluster. The correct way to do this is described in Task 10: Removing a queue manager from a cluster.

We can issue the RESET CLUSTER command only from full repository queue managers.

If you use QMNAME, and there is more than one queue manager in the cluster with that name, the command is not actioned. Use QMID instead of QMNAME to ensure the RESET CLUSTER command is actioned.

Because repositories retain information for only 90 days, after that time a queue manager that was forcibly removed can reconnect to a cluster. It does this automatically (unless it has been deleted). If you want to prevent a queue manager from rejoining a cluster, we need to take appropriate security measures. See Preventing queue managers joining a cluster.

All cluster commands (except DISPLAY CLUSQMGR) work asynchronously. Commands that change object attributes involving clustering will update the object and send a request to the repository processor . Commands for working with clusters will be checked for syntax, and a request will be sent to the repository processor.

The requests sent to the repository processor are processed asynchronously, along with cluster requests received from other members of the cluster. In some cases, processing may take a considerable time if they have to be propagated around the whole cluster to determine if they are successful or not.

 

Parent topic:

WebSphere MQ commands for work with clusters


qc11190_


 

Home