Stopping app vs. stopping server

[V Z]

Hello. Our network people will be performing maintenance, and will be rebooting routers, switches, firewalls, etc. I am afraid my nodes will not be able to talk to each other while that happens, and the cluster will partition. I would rather stop the cluster prior to the maintenance, and restart afterwards.

Is it sufficient to stop RabbitMQ app on the nodes using 'rabbitmqctl stop_app' to prevent cluster partition, or do I need to stop the entire server using 'rabbitmqctl stop'?

The reason this matters to me is because I cannot SSH to the node VMs, and if I stop just the app (remotely), I can start it remotely (by using 'rabbitmqctl start_app'); but if I stop the server, the only way to start it would be to SSH to the node VMs and run 'rabbitmq-server'.

Thank you

[Michael Klishin]

`rabbitmqctl stop` should only be used when RabbitMQ is provisioned using a binary package

or built from source, that is, not provisioned via a .deb or .rpm package. That is the case on Cloud Foundry.

`rabbitmqctl stop_app` will stop RabbitMQ and its dependencies but leave the VM running.

I suspect an even better way of doing it on CF is using Monit. `rabbitmqctl stop_app` will likely be better

than `rabbitmqctl stop` because the latter will freak Monit out.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send an email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[V Z]

Thank you for the Cloud Foundry insight -- you've read my mind (probably from my other posts). 

That aside, though, would stopping Rabbit app but leaving VM running prevent cluster partitioning if network goes down, or is Mnesia replication done at the VM level?