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

Bring me to the latest possible RabbitMQ/Erlang version

The fastest way to get to the newest version is to perform a combined RabbitMQ/ Erlang update. This will install the most recent version of RabbitMQ supported by your current Erlang version, and then install the latest Erlang version available for the new RabbitMQ version.

Depending on how many nodes you have in your cluster, version updates can be performed without downtime.

Single-node update

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

Multi-node update

You can update between major versions of RabbitMQ (i.e. 3.10.x → 3.11.x) without downtime on multi-node clusters if your current version is 3.9.0 or higher. When the update is triggered by you, we perform rolling upgrades where we update one node at the time while the cluster remains online.

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

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

You can update Erlang only to the latest available version for your current RabbitMQ version. For multi-node clusters on 3.9.0 or later, the update will be performed in a rolling manner, where one node is updated while cluster is online.

Single-node clusters will result in some downtime while updating Erlang. For multi-node clusters on RabbitMQ versions after 3.9.0, we perform RabbitMQ updates in a rolling manner where only one node at a time is updated and taken offline while the remaining nodes in the cluster stays online.

RabbitMQ Update

If you need to update to a specific RabbitMQ version, you can specify the version you need to update to on your version page. The available RabbitMQ versions are decided based on what is supported by your current Erlang version.

Single-node clusters will result in some downtime while updating RabbitMQ. For multi-node clusters on RabbitMQ versions after 3.9.0, we perform RabbitMQ updates in a rolling manner where only one node at a time is updated and taken offline while the remaining nodes in the cluster stays online.

Update without any downtime

If your current status differs from above scenarios for rolling updates, and you cannot afford any downtime during version update, we recommend creating a new cluster with the desired version and using queue federation to migrate from the old cluster to the new cluster, 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.