[rabbitmq-discuss] Unexaplainable behaviour with shovel plugin.

[Laing, Michael]

Persistence might increase reliability when you plan to restart nodes and
need to regain state. We don't do that.

We have clusters of 3 nodes across independent zones - forming an AWS
region - and run with 3 regions, i.e. nine nodes in the core, replicating
the processing of important messages across these core clusters. We have
several other ancillary clusters for clients, proxies, etc., also in
multiple regions.

We target queue lengths of zero and are close most of the time. Anything
else stands out like a black spot on a white sheet.

So we never restart nodes that die. Just sync in new ones. Actually we have
not yet had any core nodes die in production.

Our Cassandra cluster of 18 nodes, 6 per region, synchronizes globally in
less than 1 sec, and persists all of our message traffic in multiple useful
inversions. We use a replication factor of 3 per region so every message
has nine copies; important ones have many more due to message replication.
We push and pull a lot from this cache.

Our instances are ridiculously small and inexpensive to run. We rely on
this global, headless, mutually supporting rabbit army for our reliability,
paired with a small Cassandra horde.

ml





On Sat, Mar 1, 2014 at 6:21 PM, Ben Hood <0x6e6562 at gmail.com> wrote:

> On Sat, Mar 1, 2014 at 6:00 PM, Laing, Michael
> <michael.laing at nytimes.com> wrote:
> > We rely on replication
> > instead; our persistence requirements are 'outsourced' to a global
> Cassandra
> > cluster.
>
> Interesting. So you're using Rabbit for event notification rather than
> reliable(*) transfer of state?
>
> (*) For some value of reliable.
> _______________________________________________
> 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/20140301/80f5b69b/attachment.html>