Pivotal Knowledge Base

Follow

Upgrading RabbitMQ with zero downtime

Environment

Product Version
RabbitMQ

all

Symptom

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 (since clusters cannot run mixed versions like this) [1]. 

Cause

Requires downtime of the cluster

Resolution

In order to enable zero downtime, you can follow these step to migrate your applications (publisher/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 publisher are pointed to the newly created cluster.
  • Once all message are drained from the previous cluster you can shut that down.

[1] https://www.rabbitmq.com/clustering.html#upgrading

[2] https://www.rabbitmq.com/shovel-dynamic.html

 

Comments

Powered by Zendesk