Nobody wants to lose a single message…
summary
Recommendation: run a three-node cluster, use pose minority partition handling, migrate queues to quorum queues or streams, and require publisher confirms plus manual consumer acknowledgements. Two-node setups create split‑brain risk; five-node clusters can leave metadata or individual quorum queues stuck on the minority side. Mnesia holds queue/stream metadata so partitions force operator decisions; recovering a quorum queue may require scaling down to one node via CLI on 3.12+. These steps prevent most message loss but require majority-based thinking.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:02RabbitMQ users fear message loss
- 2:52Three-node cluster recommended
- 8:16Split-brain in RabbitMQ
- 13:39Amnesia in cluster consistency
- 17:15Quorum vs Classic Queues
- 20:32Five-node clusters recovery
- 25:32Risks in RabbitMQ designs
- 26:57Operator fixes network partitions
- 27:41Summary
related talks
51mKeynote: Quorum Queues: A Retrospective
26mBreaking Magical Barriers
22mWhy Are Distributed Systems so Hard?
01h 04mConsensus with Asymmetric Trust
15mUpdate from RabbitMQ Core Team
31mAKKA CLUSTER MANAGEMENT AND SPLIT BRAIN RESOLUTION
23mLightning Talks on Distributed Systems
57mSafe Passage: Messaging in a distributed systems environment