Upgrading RabbitMQ with zero downtime

Products

• VMware RabbitMQ

Issue/Introduction

Symptoms:
When upgrading from one major or minor version of RabbitMQ to another (i.e. from 3.0.x to 3.1.x, or from 2.x.x to 3.x.x), or when upgrading Erlang, the whole cluster must be taken down for the upgrade because clusters cannot run mixed versions like this [1] .

Environment

Cause

Downtime of the cluster is required.

Resolution

In order to enable zero downtime, you can follow these step to migrate your applications (publisher or consumers) from one cluster to another.

• Export definitions JSON (queues, exchanges, bindings, users, virtual hosts, permissions, and parameters) from current broker using the management plugin [2] 
• Setup you new cluster with the new version of RabbitMQ
• Import the JSON definitions for queues, exchanges, etc.
• Using shovel, dynamic or static, move messages from current cluster to the new cluster.
• This can be fully automated using the HTTP API [2]

• PUT /api/parameters/shovel/%2f/my-shovel
  {"value":{"src-uri": "amqp://", "src-queue": "my-queue", "dest-uri": "amqp://remote-server", "dest-queue": "another-queue"}}
  

• Ensure that consumers and publishers are pointed to the newly created cluster.
• Once all message are drained from the previous cluster you can shut that down.