[rabbitmq-discuss] Cluster Disk Node vs Ram Node explanation
rparra at homeaway.com
Tue Aug 30 17:07:36 BST 2011
I know this has probably been discussed at length in this list and
I just want to clarify:
* A load balanced cluster consisting of disk node A, ram node B, and ram
* A client is routed to ram node B via the load balancer,
* AND the client declares a durable queue on its connection to ram node B,
* AND the client declares bindings to a topic exchange being serviced by a
producer connected on ram node C;
WHERE are the messages stored?
WHAT happens to the producer on ram node C when ram node B fails? (Does it
block? Do messages continue to be delivered? Are messages to the client
A) Messages are stored on disk node A but served up through ram node B.
If ram node B goes down, messages are preserved and when the client
reconnects on any node, the messages can be retrieved. Since the messages
are stored on disk node A, the producer connected on ram node C continues to
publish messages to its topic exchange without blocking.
B) They are stored on disk for ram node B. If ram node B goes down, the
queue is unavailable for delivery, the producer on ram node C blocks on
publishing of messages until ram node B comes back up again. (I¹m assuming
metadata of the network is shared by the cluster therefore ram node C,
³knows² it has bindings to a durable queue on node B, which is unresponsive,
so it blocks).
C) They are not stored on disk for ram node B (unless under memory
pressure). Any messages in memory are lost. C does not block on publishing
of messages, but continues to publish messages to topic exchange. Bindings
are non-existent until ram node B comes back up again, or the client
reconnects/redeclares durable queue on another node for servicing.
D) Something else?
My inclination is to say A) is the right answer above.
However, I just finished a soak test where my durable queue on ram node B
lost messages over the weekend due to a network hiccup that crashed ram node
B. When it came back up again messages were lost. As such, we are
recommending our production configuration to be unclustered, disk node only
until we better understand the benefits and use cases associated with
clustering with RabbitMQ 2.5.1
A simple tutorial or explanation of ³To Disk Node or To Ram Node... that is
the question² would be great and useful for those of us implementing,
learning and teaching rabbit to our organizations.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss