[rabbitmq-discuss] High availability questions

Fri Dec 7 14:36:36 GMT 2012

> In order to update the version of RabbitMQ (or Erlang for that matter)
you need to stop the entire cluster I'm afraid.
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.
   - database schema fixed?
   - messages schema between nodes fixed?
   - ...?

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).

To bring down a HA cluster is clearly a very big minus for RabbitMQ, even
though there are maybe some workarounds.

Cheers
Maze

On Wed, Nov 28, 2012 at 11:31 AM, Simon MacMullen <simon at rabbitmq.com>wrote:

> On 27/11/12 21:54, Chris Toomey wrote:
>
>> I'm fairly new to RabbitMQ and we're in the process of setting up our
>> production RabbitMQ servers.  We're going to set up a server cluster and
>> will use mirrored queues for high availability. I've read through the
>> great documentation you guys have on these topics but still have some
>> questions.
>>
>> 1) Given the clustered server redundancy and mirrored queues, is there
>> any reason to still make exchanges/queues/messages durable?  Is it just
>> to protect against the case when all nodes in the cluster fail?
>>
>
> Or are deliberately stopped.
>
>
>  2) In order to update the server configuration, it's necessary to
>> restart, correct?  If so, what's the best way to accomplish config.
>> updates across a cluster while minimizing downtime and loss of redundancy?
>>
>
> You can update each node's config one at a time, and restart them all
> individually.
>
>
>  3) Same question for upgrading to a newer version of RabbitMQ?
>>
>
> In order to update the version of RabbitMQ (or Erlang for that matter) you
> need to stop the entire cluster I'm afraid.
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, VMware
> ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121207/f153283f/attachment.htm>