RabbitMQ and Erlang upgrades
RabbitMQ versions come in major, minor and patch versions, with major being the first number in the version, minor the second and patch the third. For example, 3.8.1 is major version 3, minor 8 and patch 1.
You can check which version your RabbitMQ cluster is currently running under the ‘Nodes’ tab in the CloudAMQP Console. This is also where you can find the option to upgrade to a newer version of RabbitMQ and Erlang. Clicking the upgrade button will show a popup with further information and the option to confirm or cancel.
You might notice that you can’t upgrade to a specific version. This is because some RabbitMQ versions require specific Erlang versions. Based on what RabbitMQ version is compatible with what Erlang version as described here , we are only allowing certain RabbitMQ upgrades. We’ve also applied some further restrictions based on experience we’ve had from doing a lot of RabbitMQ upgrades. If you don’t see the required RabbitMQ version, you will have to perform the upgrade in smaller steps.
Before we initiate an upgrade, we perform a health check of the cluster to make sure it can cope with an upgrade. If you get a message that your cluster is not healthy enough for an upgrade, make sure to reduce the load on the cluster.
If you want to keep messages after the upgrade, don’t forget to use persistent messages in durable queues. Connections will be dropped when RabbitMQ is restarting after an upgrade, so make sure clients can handle this and properly reconnect when RabbitMQ is up again.
Upgrading between major or minor versions of RabbitMQ (i.e. 3.6.X → 3.7.X) will result in some downtime no matter how many nodes you have in your cluster.
Single node upgrade
All single node upgrades will require some downtime since RabbitMQ will need a restart.
It is possible to upgrade RabbitMQ between patch versions (i.e. 3.7.10 → 3.7.16) in a multi-node cluster without downtime. This is called a rolling upgrade and means that one node is upgraded at a time while the other nodes are still running.
If you have custom plugins installed they might not make the upgrade. If this is the case and you want to upgrade, please email us at firstname.lastname@example.org for assistance.
Priority queues cannot be migrated between 3.6 and 3.7 and will start empty after such an upgrade.
All nodes must run the same Erlang version, so an Erlang cluster upgrade will lead to some downtime for the cluster. The downtime depends on the number of mirrored queues, persistent messages, the size of the messages, and other factors.
Upgrade without any downtime
If you cannot afford any downtime during an upgrade, we recommend creating a new cluster with the upgraded version and using queue federation to migrate from the old cluster to the new one as described here.
It is not possible to downgrade RabbitMQ and Erlang versions unless you use a queue federation to migrate a cluster to an older RabbitMQ version, as described here.
Feel free to contact us at email@example.com if you have any suggestions or feedback.