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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 9 | next ›
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedJan 31, '12 at 10:07a
activeJan 31, '12 at 2:43p
posts9
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2018 Grokbase