Adding a queue manager to a cluster

Follow these instructions to add a queue manager to the cluster you created. Messages to cluster queues and topics are transferred using the single cluster transmission queue SYSTEM.CLUSTER.TRANSMIT.QUEUE.

Before you begin

Note: For changes to a cluster to be propagated throughout the cluster, at least one full repository must always be available. Ensure that your repositories are available before starting this task.
Scenario:
  • The INVENTORY cluster is set up as described in Setting up a new cluster. It contains two queue managers, LONDON and NEWYORK, which both hold full repositories.
  • The queue manager PARIS is owned by the primary installation. If it is not, you must run the setmqenv command to set up the command environment for the installation that PARIS belongs to.
  • TCP connectivity exists between all three systems, and the queue manager is configured with a TCP listener that starts under the control of the queue manager.

About this task

  1. A new branch of the chain store is being set up in Paris and you want to add a queue manager called PARIS to the cluster.
  2. Queue manager PARIS sends inventory updates to the application running on the system in New York by putting messages on the INVENTQ queue.
Follow these steps to add a queue manager to a cluster.

Procedure

  1. Decide which full repository PARIS refers to first.

    Every queue manager in a cluster must refer to one or other of the full repositories. It gathers information about the cluster from a full repository and so builds up its own partial repository. Choose either of the repositories as the full repository. As soon as a new queue manager is added to the cluster it immediately learns about the other repository as well. Information about changes to a queue manager is sent directly to two repositories. In this example, you link PARIS to the queue manager LONDON, purely for geographical reasons.

    Note: Perform the remaining steps in any order, after queue manager PARIS is started.
  2. Define a CLUSRCVR channel on queue manager PARIS.
    Every queue manager in a cluster must define a cluster-receiver channel on which it can receive messages. On PARIS, define: 
    DEFINE CHANNEL(INVENTORY.PARIS) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(PARIS.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('Cluster-receiver channel for queue manager PARIS')

    The cluster-receiver channel advertises the availability of the queue manager to receive messages from other queue managers in the cluster INVENTORY. There is no need to make definitions on other queue managers for a sending end to the cluster-receiver channel INVENTORY.PARIS. Other definitions are made automatically when needed.

  3. Define a CLUSSDR channel on queue manager PARIS.

    Every queue manager in a cluster must define one cluster-sender channel on which it can send messages to its initial full repository.

    On PARIS, make the following definition for a channel called INVENTORY.LONDON to the queue manager with the network address LONDON.CHSTORE.COM. 
    DEFINE CHANNEL(INVENTORY.LONDON) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('Cluster-sender channel from PARIS to repository at LONDON')
  4. Optional: If this queue manager is rejoining a cluster, complete some extra steps.
    1. If you are adding a queue manager to a cluster that has previously been removed from the same cluster, check that it is now showing as a cluster member. If not, complete the following extra steps:
      1. Issue the REFRESH CLUSTER command on the queue manager you are adding. This step stops the cluster channels, and gives your local cluster cache a fresh set of sequence numbers that are assured to be up-to-date within the rest of the cluster.
        REFRESH CLUSTER(INVENTORY) REPOS(YES)
        Note: For large clusters, use of the REFRESH CLUSTER command can be disruptive to 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.
      2. Restart the CLUSSDR channel (for example, using the START CHANNEL command).
      3. Restart the CLUSRCVR channel.
    2. If the cluster is a publish/subscribe cluster, and the rejoining queue manager has subscriptions, issue the following command to ensure the proxy subscriptions are correctly synchronized across the cluster: 
      REFRESH QMGR TYPE(PROXYSUB)

Results

The following figure shows the cluster set up by this task.
Figure 1. The INVENTORY cluster with three queue managers
The diagram shows a cluster with three connected queues, LONDON, NEW YORK, and PARIS. NEW YORK has a queue called INVENTQ.

By making only two definitions, a CLUSRCVR definition and a CLUSSDR definition, we added the queue manager PARIS to the cluster.

Now the PARIS queue manager learns, from the full repository at LONDON, that the INVENTQ queue is hosted by queue manager NEWYORK. When an application hosted by the system in Paris tries to put messages to the INVENTQ, PARIS automatically defines a cluster-sender channel to connect to the cluster-receiver channel INVENTORY.NEWYORK. The application can receive responses when its queue-manager name is specified as the target queue manager and a reply-to queue is provided.