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

[Simon MacMullen]

On 15/10/10 00:20, Derek Chen-Becker wrote:
> At my company we're taking a serious look at using AMQP to unify our
> communications between various apps and sites (about 3000 locations in a
> hub and spoke topology). Volume will be relatively low, but some of our
> apps have requirements on delivery guarantees which we've worked hard to
> meet by designing our own protocols and error handling in the past. One
> of our goals here is to actually reduce the amount of error handling we
> have to do for each app, so the delivery guarantees of AMQP are
> important to us.
>
> Of all of the brokers we've looked at, RabbitMQ seems the most
> functional and most mature, but the lack of replicated queues is
> problematic for us because the hardware that will be running the broker
> in our locations is COTS non-enterprise-grade stuff (just the nature of
> our business). To pile on to the issue, we're running Windows (ugh) so a
> nice, simple solution like DRBD is ruled out.

So we're talking about active / passive here, right?

The real issue is that you need some sort of redundant, shared storage. 
Once you've got that, RabbitMQ will tolerate being killed on one machine 
with said storage and restarted on another one.

> We don't need HA or real-time failover, we just need to make sure that
> persistent messages get stored on the broker and backed up somewhere
> else so that if the broker server goes belly up we can somehow restore
> what was in the queue at the time that the server failed.

Ah, in that case you don't even need a backup broker (and hence shared 
storage). Just redundant storage. Is that practical?

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