How mixed version cluster repositories are updated

Repositories store records for an object in a cluster in the version of the record format that matches the version of the queue manager hosting the repository. Repository queue managers forward object records, before they are stored, in the format that they are received in. The recipient ignores fields from a newer version, and uses default values for fields that are not present in the record.

Cluster repositories hold records that represent objects, for example, a queue record represents a cluster queue. A full repository holds records for all objects in the cluster. Partial repositories hold records for local objects and remote objects that are used locally. A repository record can hold information only about attributes at the same command level as the queue manager holding that repository. So for example, an IBM® MQ 9.1 repository contains only IBM MQ 9.1 level attribute information. An IBM MQ 9.2 repository contains all IBM MQ 9.1 records, plus IBM MQ 9.2 records containing additional IBM MQ 9.2 attributes.

A repository stores a record it receives in its own version. If the record it receives is at a later version, the later version attributes are discarded when the record is stored. An IBM MQ 9.1 queue manager receiving information about an IBM MQ 9.2 queue manager stores only IBM MQ 9.1 information. An IBM MQ 9.2 repository receiving an IBM MQ 9.1 record stores default values for attributes introduced in the later version. The defaults define the values for the attributes that are not included in the record it receives.

A repository normally sends records in its own version format, which is the same as the format it has stored them in. There is one exception to this rule. When a full repository receives a record from a partial repository, it is immediately forwarded in the same format. So if an IBM MQ 9.1 full repository were to receive a record from an IBM MQ 9.2 partial repository, it would forward the IBM MQ 9.2 record. It sends the record to any other full repositories, and any other partial repositories that have subscriptions that match the record.

A partial repository reflects whichever full repository sent it the latest update to a record. As a consequence, you might see the information held by an IBM MQ 9.2 partial repository for new IBM MQ 9.2 attributes changing unexpectedly. The values might change from actual IBM MQ 9.2 information to default values. The changes occur if the full repositories in the cluster are at different levels. Migrate full repositories first to avoid instability.

A partial repository sends information about its objects to a full repository periodically at least once every 27 days. Information is sent about any object when it is altered or defined. See How long do the queue manager repositories retain information?

After migrating all full repositories to IBM MQ 9.2, some attributes might hold default values. The attributes might hold default values in place of actual values, if a repository has not received an update. You can refresh the repository in either of two ways:
  • Alter the object which the record containing default values represents, for example, using ALTER QL for a local queue. The alteration forces the local repository to send the record again.
  • Issue the REFRESH CLUSTER command on the partial repository which holds the record containing default values. REFRESH CLUSTER forces the partial repository to discard the record containing default values and get a new record as required.
    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.
In summary, for the most predictable, and fastest migration, when you stage cluster migration do these steps in the following order:
  1. Migrate the queue managers with full repositories.
  2. Migrate the queue managers with partial repositories.
  3. Start using new function in the cluster.
Note: In exceptional circumstances, it might be necessary to upgrade some of your partial repositories before your full repositories.

While the product supports this configuration, in this situation be very careful to avoid use of any new clustering function on the partial repositories, until your full repositories have been upgraded, to avoid unexpected results.