REFRESH CLUSTER considerations for publish/subscribe clusters
Issuing the REFRESH CLUSTER command results in the queue manager temporarily discarding locally held information about a cluster, including any cluster topics and their associated proxy subscriptions.
The time taken from issuing the REFRESH CLUSTER command to the point that the queue manager regains a full knowledge of the necessary information for clustered publish/subscribe depends on the size of the cluster, the availability, and the responsiveness of the full repository queue managers.
During the refresh processing, disruption to publish/subscribe traffic in a publish/subscribe cluster occurs. For large clusters, use of the REFRESH CLUSTER command can disrupt the cluster while it is in progress, and again at 27 day intervals thereafter when the cluster objects automatically send status updates to all interested queue managers. See Refreshing in a large cluster can affect performance and availability of the cluster. For these reasons, the REFRESH CLUSTER command must be used in a publish/subscribe cluster only when under the guidance of the IBM Support Center.
The disruption to the cluster can appear externally as the following symptoms:
- Subscriptions to cluster topics on this queue manager are not receiving publications from publishers that are connected to other queue managers in the cluster.
- Messages that are published to cluster topics on this queue manager are not being propagated to subscriptions on other queue managers.
- Subscriptions to cluster topics on this queue manager created during this period are not consistently sending proxy subscriptions to other members of the cluster.
- Subscriptions to cluster topics on this queue manager deleted during this period are not consistently removing proxy subscriptions from other members of the cluster.
- 10-second pauses, or longer, in message delivery.
- MQPUT failures, for example, MQRC_PUBLICATION_FAILURE.
- Publications placed on the dead-letter queue with a reason of MQRC_UNKNOWN_REMOTE_Q_MGR
For these reasons publish/subscribe applications need to be quiesced before issuing the REFRESH CLUSTER command.
After a REFRESH CLUSTER command is issued on a queue manager in a publish/subscribe cluster, wait until all cluster queue managers and cluster topics have been successfully refreshed, then resynchronize proxy subscriptions as described in Resynchronization of proxy subscriptions. When all proxy subscriptions have been correctly resynchronized, restart your publish/subscribe applications.
If a REFRESH CLUSTER command is taking a long time to complete, monitor it by looking at the CURDEPTH of SYSTEM.CLUSTER.COMMAND.QUEUE.
Parent topic: Designing publish/subscribe clusters
Related concepts
- Clustering: Using REFRESH CLUSTER best practices
Related information