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?

  • Any update on this? – Reddy May 18 '15 at 10:44

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.

  • 1
    Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Jenny D May 16 '18 at 6:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.