How to protect RabbitMQ virtual host deletion by accident
Article ID: 382684
Updated On:
Products
Issue/Introduction
Every so often we see users delete virtual hosts by accident. This can happen both over the HTTP API
and with the CLI command: rabbitmqctl delete_vhost.
Environment
Applicable to all RabbitMQ product offerings and versions
Cause
The RabbitMQ virtual host deletion can happen by accident. When this happens, certain kinds of virtual host data can be
restored relatively easily. The definitions data set is small (compared to tens or hundreds of
GiBs a stream can contain, for example). Unfortunately, for messages stored in queues (not streams),
the backup and restore problem is very different in scope
Tanzu RabbitMQ has a Warm Standby Replication feature that replicates both schema and messages (for QQs, streams, and CQs) to a remote warm standby cluster or multiple clusters. This does help with certain fat finger errors but not all of them,
and only if a reasonably large schema synchronization interval is used.
Resolution
Since virtual host deletion is one of the most destructive operations (up there with node reset),
it could use some extra protection and will be addressed in future 4.0.x releases of RabbitMQ via
Protection of virtual hosts from "fat finger" deletion #12772
Please subscribe to this article to get updates.
Additional Information
Workaround:
For HTTP API operations, restricting user permissions is the best solution. Roles other than "administrator" cannot delete virtual hosts.
For CLI tools, there are no restrictions of any kind.
References:
Feedback
