[rabbitmq-discuss] upgrading a cluster

[Francesco Mazzoli]

Hi Aaron,

At Wed, 22 Aug 2012 08:44:52 -0400,
Aaron Westendorf wrote:
> 
> To date we've accepted the downtime associated with upgrading our
> rabbit cluster as we perform that work infrequently. In evaluating our
> planned improvements for the coming year, decreasing downtime is an
> important goal.
> 
> With that in mind I reviewed the documentation for upgrades and found
> that it is still recommended/required that the whole cluster be shut
> down for an upgrade. That doesn't fit with our goals, so my questions
> are:
> 
> * is that recommendation up to date?

Yes.

> * is it a requirement or recommendation?

You can read it as "if you don't follow this, things might go wrong".  And
things will indeed go wrong, especially when upgrading to a feature release.
Doing that when upgrading to a bugfix release is less risky, but still risky.

> * is there a configuration that would give us the benefit of clustering and
>   mirrored queues without this requirement?

You can take a look at federation <http://www.rabbitmq.com/federation.html> and
shovel <http://www.rabbitmq.com/shovel.html>.

> Our use of Rabbit is fairly simple. We have a front-end web server to
> handle client requests, queue messages to Rabbit, and run a pool of
> consumers to handle the requests.

Well this description does not justify your clustering requirements.  If it's
just to achieve high availability, then federation might help you, if you don't
care about having strong guarantees about the published messages.

--
Francesco * Often in error, never in doubt