[rabbitmq-discuss] Forcing mirrored queue synchronization?

Matt Pietrek mpietrek at skytap.com
Mon Jan 30 19:11:51 GMT 2012

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

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?



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

More information about the rabbitmq-discuss mailing list