[rabbitmq-discuss] Correct way of determining which node is master?

[Matt Pietrek]

| Messages are *always* read from the master node (for a given queue).

This is very helpful. Going a step further, is it true to say that in a
cluster where we mirror all queues, there's really no benefit to assigning
the VIP to one node over another?

Matt


On Wed, Feb 22, 2012 at 1:58 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 21/02/12 19:04, Matt Pietrek wrote:
>
>> In a clustered scenario (3 brokers) with mirrored queues, what is the
>> correct way to determine which node is the "master" via inspection?
>>
>
> There isn't one. As in, there isn't really an overall master node.
>
>
>  On approach would be to look at the list of queues and see which node is
>> hosting the queue (as opposed to slave_nodes). However, I'm unsure if
>> there's some scenario where queue 'A' is hosted by one broker, while
>> queue 'B' is hosted by another.
>>
>
> Absolutely. The original master node *for a given queue* is the one that
> the client that first declared the queue was connected to. But then they
> can fail over to other nodes pretty arbitrarily.
>
>
>  Another approach is to go off of whichever node has the statistics
>> database, but I'm unsure if there's a 1:1 correlation there.
>>
>
> Again, this is the first node with mgmt to come up, or some other node at
> random in the case of failover.
>
>
>  Background info, in case it matters:
>>
>> We're using keepalived to maintain a virtual IP that all clients connect
>> to. We'd obviously like keepalived to put the VIP on whatever node is
>> the master rather than on a slave node. Our understanding is that if the
>> master has messages that aren't in the slave node, a client that
>> connects via the VIP to the slave node and tries to read messages won't
>> see them as they're only on the master.
>>
>
> No, that's not correct. Messages are *always* read from the master node
> (for a given queue).
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, VMware
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120222/8fda9491/attachment.htm>