What to do when RabbitMQ fails to restart

Occasionally, RabbitMQ fails to restart. This can be an important issue in case the broker contains persistent data; otherwise, it's enough to reset the broker persistent state.

Getting ready

To run this recipe, you just need a test RabbitMQ broker.

Note

We are going to destroy all the previously defined data—avoid using a production instance.

How to do it...

To clean-up RabbitMQ, it's enough to follow these simple steps:

  1. Stop RabbitMQ if it is running.
  2. Locate the Mnesia database directory. By default, it's /var/lib/rabbitmq/mnesia (Linux) or %APPDATA%RabbitMQdb (Windows).
  3. Delete it recursively.
  4. Restart RabbitMQ.

How it works...

The Mnesia database contains all the runtime definitions of RabbitMQ: queues, exchanges, users, and so on.

By deleting it, (or renaming it in case we want to try to recover some data, or to eventually fall back in case it's possible) RabbitMQ is reset to the factory defaults; once started, it will create a new Mnesia database and initialize it with default values.

There's more...

In case the broker fails to start the first time, it is probable that there is a file permission problem in one of the system directories: either the Mnesia database directory or the log directory or some temporary, or custom directories that are specified in the configuration file.

You can find quite an exhaustive list of cases in the RabbitMQ troubleshooting page (http://www.rabbitmq.com/troubleshooting.html).

See also

You can find more information on how to hack Mnesia databases at the Mnesia API documentation pages (http://www.erlang.org/doc/man/mnesia.html).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset