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 for single node clusters and for clusters not yet running 3.9.x or higher.
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. All CloudAMQP multi-node clusters running RabbitMQ 3.9.x and higher will also update in a rolling fashion between minor versions (3.9.x->3.10.x, 3.10.x->3.11.x, 3.11.x->3.12.x, etc).
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
Prior to RabbitMQ 3.9.x we enforced stoping the full cluster for Erlang updates. In 3.9.x and later Erlang upgrades are rolling upgrades for multi-node clusters.
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.
