<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 class="code ">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 class="code ">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>