> In order to update the version of RabbitMQ (or Erlang for that matter) you need to stop the entire cluster I'm afraid.<br>What would it take to allow a rolling update of the cluster? i.e. you take one node out of the cluster, upgrade it (ideally both Erlang as well as RabbitMQ) and bring it back into the cluster, wait until the nodes have fully synchronized and then continue with the next.<br>
- database schema fixed?<br> - messages schema between nodes fixed?<br> - ...?<br><br>According to the philosophy of Erlang it should even be possible to even change version of a running node (at least that was my understanding; upgrade your software with ongoing phone calls are not affected).<br>
<br>To bring down a HA cluster is clearly a very big minus for RabbitMQ, even though there are maybe some workarounds.<br><br>Cheers<br>Maze<br><br><div class="gmail_quote">On Wed, Nov 28, 2012 at 11:31 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@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 27/11/12 21:54, Chris Toomey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm fairly new to RabbitMQ and we're in the process of setting up our<br>
production RabbitMQ servers. We're going to set up a server cluster and<br>
will use mirrored queues for high availability. I've read through the<br>
great documentation you guys have on these topics but still have some<br>
questions.<br>
<br>
1) Given the clustered server redundancy and mirrored queues, is there<br>
any reason to still make exchanges/queues/messages durable? Is it just<br>
to protect against the case when all nodes in the cluster fail?<br>
</blockquote>
<br></div>
Or are deliberately stopped.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) In order to update the server configuration, it's necessary to<br>
restart, correct? If so, what's the best way to accomplish config.<br>
updates across a cluster while minimizing downtime and loss of redundancy?<br>
</blockquote>
<br></div>
You can update each node's config one at a time, and restart them all individually.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Same question for upgrading to a newer version of RabbitMQ?<br>
</blockquote>
<br></div>
In order to update the version of RabbitMQ (or Erlang for that matter) you need to stop the entire cluster I'm afraid.<br>
<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</font></span></blockquote></div><br>