Example: Rolling Upgrade of a SwiftMQ HA Router

This example explains how a SwiftMQ HA Router can be upgraded to a new release during operation without disrupting JMS clients. Note that it is not necessary to use the HAWizard because the old config files are used.

Scenario

  • The upgrade should be done from SwiftMQ Release 6.1.0 to SwiftMQ Release 7.0.0.
  • HA Instance 1 on host "msgserver1", current state ACTIVE, Linux OS, SwiftMQ Release 6.1.0 installed on /opt.
  • HA Instance 2 on host "msgserver2", current state STANDBY, Linux OS, SwiftMQ Release 6.1.0 installed on /opt.
  • Replicated File Store is used.

Step 1: Upgrade the STANDBY

a) Transfer and unpack SwiftMQ HA 7.0.0 to "msgserver2".

b) Stop HA Instance 2 (the STANDBY), HA Instance 1 turns to STANDALONE.

c) Copy the configuration file from the 6.1.0 HA Instance 2 to the 7.0.0 HA Instance 2:

      cp /opt/swiftmq_ha_6_1_0/config/replicated/instance2/routerconfig.xml
         /opt/swiftmq_ha_7_0_0/config/replicated/instance2/routerconfig.xml

d) Change to the "scripts" directory of SwiftMQ Release 7.0.0 and add exec rights to the scripts:

      cd /opt/swiftmq_ha_7_0_0/scripts/unix
      chmod +x *

e) Start SwiftMQ HA 7.0.0, HA Instance 2:

      ./smqr2_replicated

f) HA Instance 1 is now ACTIVE on release 6.1.0, HA Instance 2 is STANDBY on 7.0.0.

Step 2: Upgrade the ACTIVE

a) Transfer and unpack SwiftMQ HA 7.0.0 to "msgserver1".

b) Stop HA Instance 1 (the ACTIVE), HA Instance 2 turns to STANDALONE, JMS clients failover to HA Instance 2.

c) Copy the configuration file from the 6.1.0 HA Instance 1 to the 7.0.0 HA Instance 1:

      cp /opt/swiftmq_ha_6_1_0/config/replicated/instance1/routerconfig.xml
         /opt/swiftmq_ha_7_0_0/config/replicated/instance1/routerconfig.xml

d) Change to the "scripts" directory of SwiftMQ Release 7.0.0 and add exec rights to the scripts:

      cd /opt/swiftmq_ha_7_0_0/scripts/unix
      chmod +x *

e) Start SwiftMQ HA 7.0.0, HA Instance 1:

      ./smqr1_replicated

f) HA Instance 1 is now STANDBY, HA Instance 2 is ACTIVE. Both are now on release 7.0.0.

g) If HA Instance 1 should be the ACTIVE, reboot HA Instance 2. This will make instance 1 the ACTIVE. You can also set the "preferred active" flag at HA Instance 1 to initiate the failover automatically.

Step 3: Upgrade the Clients

SwiftMQ uses fully versioned protocols so a new release always supports prior protocol versions and JMS clients can use their current swiftmq.jar with the new release.

Therefore, upgrading the clients can be done if the client is shutdown anyway. Then copy the swiftmq.jar of the new release (7.0.0 in our example) to the client's classpath.