Rabbitmq-server: We would like the ability to be able to work around having to take a RabbitMQ cluster down to upgrade between major versions.

[davidhiston]

Hi,

We are looking to use RabbitMQ in production environments with quite strict SLA's around service downtime. We would therefore like the capability to initiate rolling upgrades for major release versions which will would allow each node to be upgraded in turn, while keeping the messaging service as a whole on-line.

One suggested method of attack could be to support something like the following:

Have the RabbitMQ cluster behind a VIP. To upgrade the RabbitMQ cluster, it should be possible to spin up an alternate cluster and switch the VIP over to the alternate cluster to maintain message queue availability. We should then have a tool which moves messages between clusters (like the shovel). When the 'master' cluster's update is done, the process is reversed.

Thanks,

Dave

[davidhiston]

Re-opening as had not meant to close it.

[benlaplanche]

The problem statement to is, we'd like the ability to do:

• Rolling upgrade deployments across a cluster
• with no downtime
• across both major & minor lines of RabbitMQ
• client applications to continue operating with no impact _(apart from reconnecting to nodes as they are restarted which is application specific behavior)
  _
  We can currently do this with patch versions - so we'd expect this behaviour to continue.

It could be acceptable for certain features to not be available during the upgrade window, such as features impacted by protocol changes, but for the RabbitMQ cluster itself to protect against this.

[rwkarg]

Old issue, but we're currently working to design around the same problem.

One part not brought up yet is handling federation during the upgrade.
Ex. BrokerA1 is the old broker that has an upstream to BrokerB
BrokerA2 is created with a newer version
EITHER we add an upstream from BrokerA2 to BrokerB and then remove the upstream from BrokerA1 or we do that in the reverse order. This leads to either duplicated or missed messages, respectively.

We're currently looking at potential duplicated messages since we are already working in the "at least once" delivery mindset just by using RabbitMQ.

[michaelklishin]

There are no plans to make in place upgrades possible between major versions but blue/green deployments are decently documented now and achieve roughly that.