[rabbitmq-discuss] Cluster nodes stop/start order can lead to failures

[Tim Watson]

Hi jb

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
> fails.
> 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 
starting them.

> Is there a way to start afresh node2 without being stuck in the current
> situation?
> 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.
> Regards,
> jb
>
>
>
> --
> 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
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss