Having read through the docs and RabbitMQ in Action, creating a RabbitMQ cluster seems straightforward enough, but upgrading or patching an existing RabbitMQ cluster seems to require the whole cluster to be restarted.
Is there a way to combine clustering, shovel, federation, and load balancing to make a rolling upgrade possible without losing queues or messages, or have I missed something slightly more obvious?
Assuming your rabbitmq clients can tolerate a dropped connection, you can consider what's described here.
our cluster is behind a VIP. When we want to upgrade a cluster, we spin up an alternate cluster and switch the VIP over to the alternate cluster. Meanwhile, we have tooling that moves messages between clusters. When the 'master' cluster's update is done, we reverse the process.
When upgrading from one major or minor version of RabbitMQ to another (i.e. from 3.0.x to 3.1.x, or from 2.x.x to 3.x.x), or when upgrading Erlang, the whole cluster must be taken down for the upgrade (since clusters cannot run mixed versions like this). This will not be the case when upgrading from one patch version to another (i.e. from 3.0.x to 3.0.y); these versions can be mixed in a cluster (with the exception that 3.0.0 cannot be mixed with later versions from the 3.0.x series).
@terence I too had been in same shoes as yours. I think you can quench you thirst for curiosity here. P.S. I haven't tried it myself yet.
