<div><br></div><div>Hope springs eternal. I'm looking forward to the 'linear scale full blown HA' feature that must be deep down somewhere in the roadmap.</div><div><br></div><div>Still, mirrored queues will be a welcome addition.</div>
<div><br></div><div>Cheers</div><div><br></div><div>M</div><div><div><br clear="all">
<br><div class="gmail_quote">On Fri, Jul 29, 2011 at 9:47 AM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Jul 29, 2011 at 09:25:55AM -0400, Mark Steele wrote:<br>
> Out of curiosity, does the master election occur on a per queue basis or is<br>
> it cluster-wide?<br>
<br>
</div>Per queue. And it's not really master election. It's simply a list which<br>
is appended to when new slaves join and removed from as people die. It's<br>
done in such a way as to ensure that when the master dies, the new<br>
master is the most likely to have been in the same state as the old<br>
master.<br>
<div class="im"><br>
> Mirrored queues are great, however there is still the thorny issue of being<br>
> limited to the throughput of the master when you've got one queue that has<br>
> lots of messages in it.<br>
><br>
> If the election process operates on a per queue basis, then it would be<br>
> possible to declare multiple queues to the same exchange and effectively get<br>
> load balanced usage of the cluster with all the goodness of high<br>
> availability.<br>
<br>
</div>Slaves have to do almost as much work as the master, and there's much<br>
greater communication overhead. Thus even though the design is async and<br>
has been substantially tuned, you will find mirrored queues perform less<br>
well than non-mirrored queues. At the end of the day, you just have to<br>
do quite a lot more work and that'll take more time.<br>
<font color="#888888"><br>
Matthew<br>
</font></blockquote></div><br></div></div>