Thanks for your reply. Please see my response in red.<br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 4:03 AM, Emile Joubert <span dir="ltr">&lt;<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
On 13/06/13 20:41, Girish Gangadharan wrote:<br>
&gt; For example, if a publisher writes a message to an exchange that ends<br>
&gt; up in a specific queue bound to that exchange, it immediately shows<br>
&gt; up in the same queue on the other node.<br>
<br>
There is only one queue on one node in this case. The cluster offers a<br>
consistent view of all resources in the cluster and allows producers and<br>
consumers to connect to any node. Messages are transparently routed<br>
across the cluster.<br></blockquote><div><br></div><div><font color="#cc0000">Does this mean that the queues actually exist only in one node to whose exchange the message was originally written to? And the fact that I can see them in the admin console of the other node is just to provide a consistent view across the cluster? So any action that I do with the original queue on the other nodes&#39; admin consoles basically makes the changes to the queue on the original node and not to the copy of that queue on the other nodes? In fact, if I understand you correctly, there IS no copy of the queue on the other nodes? Did I get that right?</font></div>
<div><font color="#cc0000"><br></font></div><div><font color="#cc0000">Not sure I understand the consistent view explanation either? What are the main benefits of having multiple nodes in a cluster if they can&#39;t really share anything? I would think Mirrored Queues should be an automatic by-product of clustering, thus offering HA out of the box. Can you explain to me why somebody would create a cluster of nodes and NOT have mirrored queues set up?</font></div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt; But then why does the article on Mirrored Queues say that *you have<br>
&gt; to explicitly set up mirrored queues by policy*?<br>
<br>
If a queue exists on only one node and that node crashes then the queue<br>
becomes unavailable. Mirrored queues provides resilience by maintaining<br>
copies of the queue that can take over in case a node crashes. See<br>
<a href="http://www.rabbitmq.com/ha.html" target="_blank">http://www.rabbitmq.com/ha.html</a><br>
<br>
&gt; So if one node goes down, the load balancer would automatically<br>
&gt; redirect all the traffic just to the node that is up and running. And<br>
&gt; the clients will not be affected. Would that work? Is that the<br>
&gt; recommended approach?<br>
<br>
That is a common approach. Another is to provide clients with reconnect<br>
logic that allows them to select the alternative node when one node crashes.<br>
<br>
&gt; I was thinking about using Shoveling technique to push messages from<br>
&gt; a logical broker sitting on a cluster in our local HA servers to a<br>
&gt; different logical broker to the DR server. In this case, a copy of<br>
&gt; the messages will keep getting pumped into the DR with no clients<br>
&gt; processing it. What will happen to those messages?<br>
<br>
Nothing will happen to them. They will accumulate in the DR server<br>
unless you take action to remove them, or unless they expire.<br>
<br>
&gt; Should I have a workflow to go purge them every day manually or via a<br>
&gt; script (after I make sure those messages aren&#39;t needed anymore since<br>
&gt; the clients have already process them from the main HA cluster).<br>
<br>
That depends on the specifics of your disaster scenario, your messaging<br>
pattern and how you plan to switch over to your DR environment. Purging<br>
queues after a day sounds reasonable.<br>
<br>
&gt; If the main HA cluster goes down and I have to bring the DR server into<br>
&gt; action, what happens to the messages that did get processed already by<br>
&gt; the clients? Should the clients have logic built in to ignore duplicates<br>
&gt; to handle this specific scenario?<br>
<br>
Performing deduplication in clients is probably the simplest solution,<br>
or you could mirror the effects of consumers removing messages from<br>
queues in your DR environment.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-Emile<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br>