Conventional Clusters

In a conventional cluster, each of the constituent brokers maintains its own separate persistent data store (see Persistence Services). Brokers within the cluster share information about one another’s persistent destinations, message consumers, and durable subscriptions. However, if one of the brokers should fail, none of the other brokers in the cluster can take over its operations, since none of them have access to the failed broker’s persistent messages, open transactions, and other aspects of its internal state.

Changes to a cluster’s destinations, consumers, or durable subscriptions are automatically propagated to all of the other brokers in the cluster. However, a broker that is offline at the time of the change (through failure, for instance) will not immediately receive this information. To keep such state information synchronized throughout the cluster, one of its brokers can optionally be designated as the master broker to track changes in the cluster’s persistent state. The master broker maintains a configuration change record containing information about changes in the persistent entities associated with the cluster, such as durable subscriptions and administrator-created physical destinations. All brokers in the cluster consult the master broker during startup to update their information about these persistent entities; thus a broker returning to operation after having been temporarily offline can update its information about changes that may have occurred during its absence.

While it is possible to mix brokers with different versions in the same cluster, all brokers must have a version at least as great as that of the master broker. If there is no master broker, all brokers in the cluster must have the same version.

Because all brokers in a conventional cluster need the master broker in order to perform persistent operations, the following imqcmd subcommands for any broker in the cluster will return an error when a master broker has been configured but is unavailable:

create dst




destroy dst




update dst




destroy dur

Auto-created physical destinations and temporary destinations are unaffected.

In the absence of a master broker, any client application attempting to create a durable subscriber or unsubscribe from a durable subscription will get an error. However, a client can successfully specify and interact with an existing durable subscription.