[rabbitmq-discuss] Disaster Recovery
Jerry Kuch
jerryk at rbcon.com
Tue Aug 14 17:02:53 BST 2012
Hi, Ruben...
In terms of acceptable data loss, for our db’s we accept 15 minutes worth
> of data loss, the same level of tolerance would be acceptable for rabbitmq.
>
Can you say more about the structure, both in physical terms and in
application terms, of your scenario?
First, I'm assuming you have RabbitMQ brokers or clusters thereof in two or
more geographically separated environments, along with whatever application
infrastructure is using them (e.g. databases) replicated, in whole or in
part, possibly modulo contents, at both sites?
What sort of work are your consumers doing in response to the messages they
consume? Does it involve committing things to databases, causing side
effect-ish things to happen in the real world, etc.?
With some of those parameters specified a bit more tightly we can likely
provide guidance. We've worked with Rabbit users in the past who use
shovel or federation between geographically separated sites to transmit
digests or summaries of started operations or finalized state in one site
to the other site. Reviewing the properties of shovel and federation and
figuring out what sort of information your case would need to send to the
backup site as part of general operations is a good starting point.
For example, you might consider having the primary send copies of, or new
messages derived from, work requests at the primary site to the secondary
site, where they'll be logged somehow, likely preferably outside of Rabbit,
and left dormant, to be retired when a corresponding "completed" message is
generated at the primary. Your 15 minute requirement would help you bound
just how much of this you'd need to store, and give you a basis for picking
at the secondary site after suspected or confirmed failure of the
primary... You'd obviously want to favor a design with idempotency of the
messages so that things received twice don't have additional or different
effects from the thing received once, but this is a good idea even *within*
the sites on either end of your WAN connected systems...
Tell us more and let's digest your use case further... :-)
Best regards,
Jerry
The assumption is that the failover will not be automatic but that it will
> have to be manually flipped to the DR site and that back ground processes
> would have to be started up manually.
>
> ** **
>
> Thanks,****
>
> Ruben.****
>
> ** **
>
> *From:* rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:
> rabbitmq-discuss-bounces at lists.rabbitmq.com] *On Behalf Of *Jerry Kuch
> *Sent:* Friday, August 03, 2012 1:54 PM
> *To:* Discussions about RabbitMQ
> *Subject:* Re: [rabbitmq-discuss] Disaster Recovery****
>
> ** **
>
> Hi, Ruben:
>
> We have users that make use of Rabbit/AMQP messaging as part of cross-site
> DR scenarios, but one has to be thoughtful about what one is trying to do.
>
> *What* is it that you want replicated between sites for DR? Presumably
> more than just broker and cluster configs and their metadata since that's
> relatively straightforward... Usually the question is what data, effects
> and business processes do you want to be able to fail over to a
> geographically separated site, and what sorts of guarantees do you want for
> the failover. This naturally affects the design of your application and
> its deployment fairly intimately.
>
> If you feel comfortable talking more about what you want from your
> scenario we can probably make some suggestions based on things we've seen
> done...
>
> Best regards,
> Jerry
>
> ****
>
> On Fri, Aug 3, 2012 at 11:29 AM, Ruben Rotteveel <ruben at fiadmin.com>
> wrote:****
>
> Hi All,****
>
> ****
>
> What is your recommendation for how to mirror a rabbitmq installation in
> a DR site?****
>
> ****
>
> Thanks,****
>
> Ruben Rotteveel****
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss****
>
> ** **
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120814/0682a9b6/attachment.htm>
More information about the rabbitmq-discuss
mailing list