[rabbitmq-discuss] Forcing mirrored queue synchronization?

[Matt Pietrek]

We're moving towards a production deployment of mirrored queues for our
platform using RabbitMQ 2.71 on Ubuntu 10.04. One of the things we need to
support is rolling upgrades. Thus, while running in a mirrored cluster, we
plan to bring down one node at a time while leaving at least one node
running.

The potential problem arises in that our queue client may drain the queue
very slowly, e.g., a single message may take hours to execute, and we only
process one message at a time per client.

After completing the maintenance on a node and having it rejoin the cluster,
it might be a long time before the queues are synched again.  (I'm aware
that there's no eager synchronization, and that message synchronization
occurs only on message publish.) As a workaround to speed up
synchronization, I'm thinking of a small "synchronize now" app that
transactionally reads all current messages from the master's queue and
republishes them.

Our code is designed to handle duplicate messages, but we really want to
avoid losing messages.

Questions: Are there any potential pitfalls with this approach? And is there
some optimal way to do this that's better than "read/re-publish/ack"  for
each message in a loop?

Thanks,

Matt


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120130/a3ca40c5/attachment.htm>