[rabbitmq-discuss] Clustering - communication

[Alexandru Scvorţov]

> But I think I have it: backend is on 2.4.1 and back2 is on 2.7.1. They
> both use the same 0-9-1 protocol but that'll be it, won't it?

They both need to be the same version.  AMQP is used to talk to the
clients; Erlang messages are used to communicate inside the cluster.  As
a rule, all nodes need to run the same version of Erlang and the same
version of RabbitMQ.  If they don't, it might work, but the behaviour is
undefined.

> > Well, one of them has to be.
> Well - for example - if backend is started (and processing messages)
> and back2 is stopped - and I run the command:
> rabbitmqctl -n rabbit at backend status
> or:
> rabbitmqctl cluster rabbit at backend
>  on back2 - that should be OK?

Yes.

> > Stop_app is the equivalent of a clean shutdown, so, it will kill
> > transient messages/queues, but save to disc persistent messages/durable
> > queues/any other configuration.
> So the solution is to make everything durable I want to keep?

Yes.

> Is the same true when I just do:
> /etc/init.d/rabitmq-server stop

Yes.

> > Again, when it's stopped, it won't have
> > any connections, so it won't get new messages.
> That's why we're trying to do it as fast as possible.

Bear in mind that the more persistent things you have (messages and
queues), the longer it will take for RabbitMQ to shutdown and to recover
from unclean shutdowns (caused by killing the rabbitmq-server process,
for instance).

The problem you're seeing is probably caused by the version mismatch.

Cheers,
Alex

On Tue, Jan 31, 2012 at 01:21:49PM +0000, Dan Dart wrote:
> > You seem to have done everything right.
> Ouch.
> 
> > Well, one of them has to be.
> Well - for example - if backend is started (and processing messages)
> and back2 is stopped - and I run the command:
> rabbitmqctl -n rabbit at backend status
> or:
> rabbitmqctl cluster rabbit at backend
>  on back2 - that should be OK?
> 
>  > The *target* nodes also have to be started for rabbitmqctl to work.
> The ones you're trying to cluster into - they are started.
> 
> > Stop_app is the equivalent of a clean shutdown, so, it will kill
> > transient messages/queues, but save to disc persistent messages/durable
> > queues/any other configuration.
> So the solution is to make everything durable I want to keep?
> Is the same true when I just do:
> /etc/init.d/rabitmq-server stop
> 
> 
> > Again, when it's stopped, it won't have
> > any connections, so it won't get new messages.
> That's why we're trying to do it as fast as possible.
> 
> > That sounds a bit worrying.  Could you just put some human readable text
> > in both (e.g. "test"), make sure that both nodes are started, and try
> > the rabbitmqctl status command from one to the other?
> Well - yes - it reads the same on each. No more carriage returns - the
> hex is exact.
> and the current node cookie hash is also the same.
> 
> But I think I have it: backend is on 2.4.1 and back2 is on 2.7.1. They
> both use the same 0-9-1 protocol but that'll be it, won't it?
> 
> Cheers
> Dan