Upgrading RabbitMQ can be considered in two directions:
- Upgrading the Erlang installation
- Upgrading the broker installation
In both cases, it is good practice to perform a full backup of the RabbitMQ broker before performing an upgrade. Also you should check out the release notes for all the versions issued between the old and the new version to see if there are any specific steps that must be performed during the update. Typically, installation of a RabbitMQ broker preserves data and updates only the RabbitMQ installation and the database structures used for representing the broker metadata and message stores. It is important to make sure that, if you have to update nodes in a cluster, you first stop all nodes and use the same version of RabbitMQ for the update over all nodes in the cluster.
For easier management, we have decided to pre-configure our CSN RabbitMQ broker (using a custom script) with two separate vhosts:
v_chat: For handling all chat messages in CSNv_events: For handling of all events in CSN
Moreover we have decided to separate the users that are allowed to access each vhost. The users of the v_events group are further divided into the following logical groups:
- Administrators have the ability to create event queues, and publish and consume messages
event_publishershave the ability to publish messagesevent_subscribershave the ability to consume messages
As you may guess, we can implement the preceding logical separation easily for the users in the v_events host using policies. The users of the v_chat vhosts have full configure, read, and write access to the components of the vhost.
Another thing we want to provide is the ability to log all messages that pass through the broker for backup and restore purposes. We also decide to set limitations on the RAM and disk storage used by the broker using a custom rabbitmq.config file.
You can provision the additional components as part of the setup process easily by using custom code and the REST API, which allows to create the vhosts, users for them (with the appropriate policies to act as access control based on the logical separation of the users), and a backup exchange that receives a copy of all messages passed to all other exchanges in the broker. A custom utility (that could be part of the backup databases as well) subscribes to that exchange and stores the messages in the database.