[rabbitmq-discuss] Cluster nodes stop/start order can lead to failures
tim at rabbitmq.com
Thu Jan 24 16:36:13 GMT 2013
On 01/19/2013 06:26 PM, jbdupont wrote:
> Ok, I understand the reasoning behind this behaviour.
> However, how can I unlock the situation of the node that I cannot restart at
> the moment?
> My app is such that node2 is the normal, node1 is used as backup is node2
> When I restart I may be in a situation where node2 is started first and then
> node1 - at present I fall into a lock situation.
Surely which node starts first is under your control? Also it is the
order in which the nodes were shut down that matters when it comes to
> Is there a way to start afresh node2 without being stuck in the current
> For instance restarting out of the cluster, and then joining the cluster
> again ?
The only way to do that - for a node which *was* a member previously -
is to remove / move the mnesia database directory and restart as a
virgin node. If you don't mind the data loss. You can start a third
virgin node and have it join any time you like. Also I'm not really sure
how this is meant to help you?
> That would suit my needs actually.
> Othewise, I would need to design a different architecture without cluster...
> This may be the way I will have to go.
> Thanks to point me into the right direction on this.
> View this message in context: http://rabbitmq.1065348.n5.nabble.com/Cluster-nodes-stop-start-order-can-lead-to-failures-tp21965p24586.html
> Sent from the RabbitMQ mailing list archive at Nabble.com.
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss