Chapter 5. Clustering and dealing with failure
This chapter covers
- Architecture of a RabbitMQ cluster
- Setting up a cluster on your laptop
- Creating a cluster with physical servers
- Upgrading cluster nodes
- Working with mirrored queues
So you just finished your phenomenal new web app powered by RabbitMQ’s queuing magic. The user interface displays real-time notifications fed from your backend API, and Rabbit is routing to each API client only the notifications they’re interested in. Everything looks great, and Rabbit has made you look like a programming guru to your boss. Time to deploy to production; you can just throw up a RabbitMQ instance on a production server and call it a day, right? Not so fast. Your real-time magic may look great to your customers now, but what happens when your RabbitMQ server has its memory corrupted, or the server loses a power supply? Your high-performance app just became the company’s black eye—and your problem. Guess it’s time we talked about making RabbitMQ resilient to failure, so when Murphy’s Law wreaks havoc with your apps, you can trust RabbitMQ to keep chugging as the heart of your application.