RabbitMQ Upgrade Best Practices

#rabbitmq

Some simple best practices around performing RabbitMQ upgrades.

Testing a New Version

Test the upgrade process.
Test the new version with your services/clients.
If doing rolling upgrades, test your services with a mixed cluster using the versions you will upgrade from/to.
Test rolling back.

Rolling Upgrade

Adjust according to your setup.

Per node checklist:

[ ] Assume roughly 5mins per node.
[ ] Ensure the node is not just visible in the dashboard, but also accessible via e.g. DNS names and similar.
[ ] Allow the cluster to stabilise with regards to replication, queue levels and similar.
[ ] Ensure the underlying (cloud) platform reports a steady state.
[ ] Ensure that clients can connect to the node and communicate.

⚠️ Rollback always takes longer than upgrade.

Release Windows

One release per window. If you need to do several upgrades, schedule several windows.

Hands-on debugging session: instrument, monitor, and fix

Join Lazar for a hands-on session where you’ll build it, break it, debug it, and fix it. You’ll set up Sentry, track errors, use Session Replay and Tracing, and leverage some good ol’ AI to find and fix issues fast.

RSVP here →