Hello,

Is there any way I can move queues from one RabbitMQ node to another?

My usage scenario is moving a live RabbitMQ instance from one server to
another as transparently as possible. Something like:
- start another RabbitMQ instance on the target server
- cluster together the source and target RabbitMQ instances
- close all existing connections
- flip IPs (target's IP takes the source's IP)
- start moving all the queues from source to target. During this time
clients should be able to consume from the target queues.
- when the move process has finished, terminate the source RabbitMQ instance

Reading the documentation I see the following potential options - which
don't seem completely satisfactory:
- The shovel plugin. I would need to redeclare all queues on the target
RabbitMQ and then shovel messages over. The only problem that I see is that
it's not completely transparent to clients - a queue may appear empty or
may report less messages if not all messages have been shoveled over when a
client starts using it.
- Mirrored queues. But I don't think you can make a queue mirrored *after*
it has been created. Can you?
- Shared network disk. But this requires a broker restart - and thus
implies loosing all non-durable queues and non-persistent messages.

Is there any other way?

Thanks,
Ionel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120227/89d7b28e/attachment.htm>

Search Discussions

  • Matthew Sackman at Feb 28, 2012 at 11:21 am
    Hi Ionel,
    On Mon, Feb 27, 2012 at 07:25:41PM +0000, Ionel Gog wrote:
    Is there any way I can move queues from one RabbitMQ node to another?
    Nope, sorry, not an individual queue.
    - Mirrored queues. But I don't think you can make a queue mirrored *after*
    it has been created. Can you?
    No, you can't do that.
    - Shared network disk. But this requires a broker restart - and thus
    implies loosing all non-durable queues and non-persistent messages.

    Is there any other way?
    I would suggest something along the lines of the following.

    - bring up the new broker. Do not cluster it.
    - declare all the exchanges/bindings/queues you need on the new broker
    - i.e. have the topology match exactly
    - change all publishers to be publishing to the new broker
    - wait for all messages to be drained from the old broker, and then
    switch over all consumers to be consuming from the new broker
    - shut down the old broker

    In general, whilst this does require manual intervention, and will
    certainly require thought especially if your consumers also publish
    messages (you'll want to abstract those connections out and generally
    start the switchover from the top of the message flow to the bottom),
    this process does allow you to upgrade Rabbits with no downtime at all,
    though potentially with some service disruption.

    Matthew

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 27, '12 at 7:25p
activeFeb 28, '12 at 11:21a
posts2
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Matthew Sackman: 1 post Ionel Gog: 1 post

People

Translate

site design / logo © 2022 Grokbase