<div dir="ltr">On your clustering and clients connecting transparently - I highly recommend a load balancer in front of your Rabbit servers.  With tcp-half open monitoring on the rabbit port, you can tell pretty quickly when a node/site goes down, and then get failover to one of the other nodes/clusters.  With clustering and mirrored queues and by using publisher confirms you'll avoid data loss this way.  You CAN get data duplication though.  But I'd only recommend clustering over a really reliable link.  If you're going across a WAN - use shovel/federations to replicate messages to rabbit clusters on the other side, vs. trying to do cross-wan clusters.  You could for run a cluster in each site and use federation to send messages to the other cluster as needed.  If any given site goes down, your load balancer could switch traffic to the other cluster.  There's still a chance for downtime, but it's pretty minimal.  We use this to redirect traffic to any given node in the cluster right now so if a single node fails, the load balancers pull that node out of service automatically.<div>
<br></div><div>Regarding question 2 - if you design it right, using confirms (the default in most clients as i understand it), and use persistent messages, you'll never get message loss with a mirrored queue, unless ALL servers completely crash and hard drives die.  At least this is my understanding :)<div>
<br></div></div><div>Last point - you may want to do manual handling of this situation if it's that much of concern.  e.g. let the nodes remain partitioned, let all messages empty (again, remember there would be duplicates possible), then restrict access to the bad nodes to anything but your consumer processes, shut down the "bad" nodes and bring them back up.  They'd not have any messages, and they'd get their queues/exchanges from  your "master" node that was good when they come back up.  In the case of a load balancer in front, you could use your load balancer to control this very effectively.</div>
<div><br></div><div>Definitely read through partitioning and reliability documentation and actually try these scenarios:</div><div><a href="https://www.rabbitmq.com/partitions.html">https://www.rabbitmq.com/partitions.html</a><br>
</div><div><a href="https://www.rabbitmq.com/reliability.html">https://www.rabbitmq.com/reliability.html</a><br></div><div><br></div><div><br></div><div>Jason</div><div><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, May 22, 2014 at 8:04 AM, Steffen Daniel Jensen <span dir="ltr"><<a href="mailto:steffen.daniel.jensen@gmail.com" target="_blank">steffen.daniel.jensen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We have two data centers connected closely by LAN. </div><div> </div><div>We are interested in a *reliable cluster* setup. It must be a cluster because we want clients to be able to connect to each node transparently. Federation is not an option.</div>
<div><div>1. It happens that the firewall/switch is restarted, and maybe a few ping messages are lost.</div><div>2. The setup should survive data center crash</div></div><div>3. All queues are durable and mirrored, all messages are persisted, all publishes are confirmed</div>
<div> </div><div>There are 3 cluster-recovery settings</div><div>a) <span>ignore:</span> A cross data center network break-down would cause message loss on the node that is restarted In order to rejoin.</div><div>b) <span>pause_minority:</span> If we choose the same number of nodes in each data center, the whole cluster will pause. If we don't, only the data center with the most nodes can survive. </div>
<div>c) auto_heal: If the cluster decides network partitioning, there is a potential of message loss, when joining.</div><div>[I would really like a resync-setting similar to the one described below]</div><div> </div><div>
Question 1: Is it even possible to have a fully reliable setup in such a setting?</div><div> </div><div>In reality we probably won't have actual network partitions, and it will most probably only be a very short network downtime.</div>
<div> </div><div>Question 2: Is it possible to adjust how long it takes rabbitmq to decide "node down"?</div><div> </div><div>It is much better to have a halted rabbitmq for some seconds than to have message loss.</div>
<div> </div><div> </div><div>Question 3: Assume that we are using the ignore setting, and that we have only two nodes in the cluster. Would the following be a full recovery with zero message loss? </div><div> </div><div>0. Decide which node survives, Ns, and which should be restarted, Nr.</div>
<div>1. Refuse all connections to Nr except from a special recovery application. (One could change the ip, so all running services can't connect or similar)</div><div>2. Consume and republish all message from Nr to Ns.</div>
<div>3. Restart Nr</div><div>Then the cluster should be up-and-running again.</div><div> </div><div>Since all queues are mirrored, all messages published in the partition time is preserved. If a certain service lives only in the one data center, messages will pile up in the other (if there are any publishes).</div>
<div> </div><div>If you have any other suggestions, I would be very interested to hear them.</div><div> </div><div>I would be really sad to find it necessary to choose Tibco ESB over RabbitMQ, for this reason.</div><div> </div>
<div>Thank you,</div><div>-- Steffen</div></div><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Jason McIntosh<br><a href="https://github.com/jasonmcintosh/" target="_blank">https://github.com/jasonmcintosh/</a><br>573-424-7612</div>
</div>