Pivotal Knowledge Base


Upgrading RabbitMQ with zero downtime


Product Version



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


Requires downtime of the cluster


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



Powered by Zendesk