Moving a cluster topic definition to a different queue manager

For either topic host routed or direct routed clusters, you might need to move a cluster topic definition when decommissioning a queue manager, or because a cluster queue manager has failed or is unavailable for a significant period of time.

About this task

You can have multiple definitions of the same cluster topic object in a cluster. This is a normal state for a topic host routed cluster, and an unusual state for a direct routed cluster. For more information, see Multiple cluster topic definitions of the same name.

To move a cluster topic definition to a different queue manager in the cluster without interrupting the flow of publications, complete the following steps. The procedure moves a definition from queue manager QM1 to queue manager QM2.

Procedure

Create a duplicate of the cluster topic definition on QM2.

For direct routing, set all the attributes to match the definition of QM1.

For topic host routing, initially define the new topic host as PUB(DISABLED). This allows QM2 to learn of the subscriptions in the cluster, but not to start routing publications.
Wait for information to be propagated through the cluster.
Wait for the new cluster topic definition to be propagated by the full repository queue managers to all queue managers in the cluster. Use the DISPLAY CLUSTER command to display the cluster topics on each cluster member, and check for a definition originating from QM2.
For topic host routing, wait for the new topic host on QM2 to learn of all subscriptions. Compare the proxy subscriptions known to QM2 and those known to QM1. One way to view the proxy subscriptions on a queue manager is to issue the following runmqsc command:
```
DISPLAY SUB(*) SUBTYPE(PROXY)
```
For topic host routing, redefine the topic host on QM2 as PUB(ENABLED), then redefine the topic host on QM1 as PUB(DISABLED).

Now that the new topic host on QM2 has learned of all subscriptions on other queue managers, the topic host can start routing publications.

By using the PUB(DISABLED) setting to quiesce message traffic through QM1, you ensure that no publications are in train through QM1 when you delete the cluster topic definition.
Delete the cluster topic definition from QM1.

You can only delete the definition from QM1 if the queue manager is available. Otherwise, you must run with both definitions in existence until QM1 is restarted or forcibly removed.

If QM1 remains unavailable for a long time, and during that time you need to modify the clustered topic definition on QM2, the QM2 definition is newer than the QM1 definition, and therefore usually prevails.

During this period, if there are differences between the definitions on QM1 and QM2, errors are written to the error logs of both queue managers, alerting you to the conflicting cluster topic definition.

If QM1 is never going to return to the cluster, for example because of unexpected decommissioning following a hardware failure, as a last resort you can use the RESET CLUSTER command to forcibly eject the queue manager. RESET CLUSTER automatically deletes all topic objects hosted on the target queue manager.