[rabbitmq-discuss] Queue replication (I know, I know)

[Simon MacMullen]

On 20/10/10 05:14, Derek Chen-Becker wrote:
> What's more interesting is that if I copy the /var/lib/rabbitmq
> directory to the backup host *without stopping the primary broker*, and
> then stop the primary and start the backup, everything still appears to
> work fine. Now, I suspect that with the low volume I'm pushing here I'm
> just getting lucky and not copying files in an inconsistent state,

Probably not. Rabbit is designed to repair queues when it comes up 
again, so if you're copying queues when they're inconsistent it'll get 
fixed by the time the backup broker is accepting connections. Of course, 
if you're unlucky, you could lose a few messages in such a process but 
from what you've said before it sounds like that isn't your biggest concern?

Of course with buffering involved messages can take a while to be 
written to disk. Transactions around publishes will help here - when you 
get commit-ok back you know any persistent messages are on disk.

> but
> it made me think of possibly another approach to making backups: would
> it be possible to implement a "pause/snapshot" for the broker such that
> it would flush data, hold off on writes, etc. so that I could copy the
> data in a consistent state. I could then issue a "resume" and all of the
> clients would just continue on their merry way. At least this way the
> sockets and socket bindings would stay open so that as far as clients
> are concerned my broker is just being reaaaaallly slow.

Hmm, interesting idea. I'll see if we're interested in doing that. We're 
currently looking at how to make the HA experience better so this might 
be a possibility.

Cheers, Simon
-- 
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware