Progress Sonic 8.5 Installation and Upgrade Guide - Product ...

Zero-Downtime Upgrades of 7.5 and 7.6 Clusters and Replicated Brokers
4. Broker logs both provide Pre-8.5 comments until the other peer is upgraded.
5. At the location of the backup peer, confirm that the primary broker still has the
STANDBY role. If not, force failover by restarting the primary broker’s container.
6. On the backup broker’s system, perform the broker upgrade tasks:
a. Install the Sonic 8.5 Container Launcher
b. Extract the broker’s container’s properties.
c. Specify the working directory if it is not the default MQ7.n root.
d. Run the upgrade. When the 7.5 or 7.6 broker is stopped, the primary broker is
STANDALONE. When the upgrade logic brings the broker up in 8.5, it passes through
STANDBY_SYNC and then takes the STANDBY role. The primary takes the ACTIVE role.
When both peers have been upgraded, the replicated brokers are fully upgraded, and can
perform Version 8 functions.
Note Reverting to Version 7 — In the unlikely circumstance that you are compelled to revert
to Version 7, the installations are still intact, and—despite having lost message traffic in
the interim— the peers can return to the moment when the Version 7 backup broker
stopped. The procedure of setting the roles of the peers through the upgrade ensured that
the Version 7 backup would restart in the ACTIVE role, and the primary in the STANDBY role.
Upgrading a Cluster of Replicated Brokers
Adding the resilience of replicated broker pairs to cluster members enables a highly
scalable and continuously available messaging node. This configuration combines the
tactics for both clustered brokers and replicated brokers.
Progress Sonic Installation and Upgrade Guide 8.5 209