RabbitMQ and Erlang upgrades

Keeping your RabbitMQ cluster updated with the latest RabbitMQ and Erland versions should be a high priority. Not only do newer versions include bug fixes, give better performance, and improve the security of your data, you will find that troubleshooting gets easier and that you have access to all the latest features if you are using the most current version.

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.

RabbitMQ upgrade

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.

Multi-node upgrade

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.

Plugins

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 support@cloudamqp.com for assistance.

Priority queues

Priority queues cannot be migrated between 3.6 and 3.7 and will start empty after such an upgrade.

Erlang 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.

Downgrades

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 support@cloudamqp.com if you have any suggestions or feedback.

CloudAMQP - industry leading RabbitMQ as a service

Start your managed cluster today. CloudAMQP is 100% free to try.

13,000+ users including these smart companies