[rabbitmq-discuss] Incorrect display of mirrored queues as unsynchronised after database failover

[Matt Pietrek]

Thanks Simon.

I realized just now that I was less than precise in my prior summary of the
state.

It does appear that that rabbitmqctl and the management API are in sync on
what they report. What's "interesting" is that after the broker rejoins the
cluster, it's not always a slave for the queues it was previously a master
or slave for.

If you'll recall from my original message, we normally have 3 brokers.
During the rolling upgrade we take one down and then rejoin it to the
cluster. What we're seeing is that after the broker rejoins, some of the
queues have the expected two slaves ('+2' in the UI). However, other queues
(seemingly at random) have only one slave ('+1').

The management UI and rabbitmqctl agree on what we're seeing. And prior to
the operation, all the queues had two slaves.


On Fri, Jun 22, 2012 at 4:45 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 20/06/12 22:31, Matt Pietrek wrote:
>
>> Back before 2.8.0 was announced, I reported an issue with Mirrored
>> queues reporting some nodes as unsynchronized.
>>
>
> Hmm. Well, there was a real issue there. That one was where the management
> plugin was getting desynchronised from what was really going on. So if you
> are still seeing something similar in 2.8.2, does management agree with
> rabbitmqctl?
>
> (In general rabbitmqctl goes and calls into processes whenever it needs to
> know something, while management listens to events that are broadcast and
> maintains its own view of the world.)
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, VMware
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120622/ef94a6a6/attachment.htm>