CloudAMQP Console Versions

This feature is available on dedicated instances.

A RabbitMQ cluster can contain one or several RabbitMQ servers, where each server is called a node.

From the Versions view, you can manage all nodes in a cluster and perform actions such as RabbitMQ and Erlang updates.

RabbitMQ cluster

RabbitMQ and Erlang Updates

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

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, version 3.8.1 has major version 3, minor 8, and patch 1. Clicking the Update Erlang or Update RabbitMQ buttons will show a pop-up with further information and the option to confirm or cancel.

You might notice that you can’t update to a specific version. This is because some RabbitMQ versions require specific Erlang versions. Based on what RabbitMQ version is compatible with a particular Erlang version as described here, only certain RabbitMQ updates are allowed. CloudAMQP have also applied some further restrictions based on the experience we’ve had from performing a lot of RabbitMQ updates. If you don’t see the required RabbitMQ version, you will have to perform the update in smaller steps.

Before initiating an update, a health check of the cluster is performed to ensure it can cope with the update. If you get a message that your cluster is not healthy enough for an update, make sure to reduce some of the load.

Don’t forget to send persistent messages to durable classic queues if you want to keep messages after the update. Connections will be dropped when RabbitMQ is restarting after an update, so make sure clients can handle this and properly reconnect when RabbitMQ is up again.

RabbitMQ update

Upgrading between major or minor versions of RabbitMQ (i.e., 3.6.X → 3.7.X) result in some downtime no matter how many nodes you have in your cluster.

Single node update

All single node updates will require some downtime since RabbitMQ will need a restart.

Multi-node update

It is possible to update RabbitMQ between patch versions (i.e., 3.7.10 → 3.7.16) in a multi-node cluster without downtime. It’s called a rolling update, meaning that one node is updated at a time while the other nodes are still running.

Plugins

If you have custom plugins installed, they might not make the update. If this is the case and you want to update, 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 update.

Erlang Update

All nodes must run the same Erlang version, hence an Erlang cluster update 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.

Update without any downtime

If you cannot afford any downtime during an update, we recommend creating a new cluster with the selected 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.