<div>Hi Francesco, thanks for your answer (howcome it isn't showing up in this google group)? Can you give me an example of a durable resource creation/deletion operation that would benefit from a RAM node (so that I know what that means)? If I do have a lot of these, then would I benefit from using the 3rd (non-wep-app) machine as a RAM node, along with the 2 (relevant web app containing) disc nodes? Also, how do I approximately calculate the maximum disk space the disc nodes may possibly need in the very worst case scenario, say when there are 1 Mb/s of messages?</div><div><br></div><div>On 6 July 2012 18:25, Francesco Mazzoli wrote:</div><div>&gt; Hi Navigateur,</div><div>&gt; At Thu, 5 Jul 2012 05:57:57 -0700 (PDT),</div><div>&gt; Navigateur &nbsp;wrote:</div><div>&gt;&gt; New to RabbitMQ. I want do to high-availability over 2 machines. Do I make</div><div>&gt;&gt; them both disk nodes or just 1?</div><div>&gt;</div><div>&gt; Having only one disc node in a cluster deprives you of the nicest characteristic</div><div>&gt; of a cluster: you can be sure that if one database state gets corrupted for some</div><div>&gt; reason, you still have the other one. This is even more relevant when using HA</div><div>&gt; queues, which is what you want to do.</div><div>&gt;</div><div>&gt; Having only a RAM node online is a situation that you should avoid - losing data</div><div>&gt; is really easy in that position.</div><div>&gt;</div><div>&gt;&gt; If just 1, but its disk fails, does the other one automatically become a "disk</div><div>&gt;&gt; node"?</div><div>&gt;</div><div>&gt; No.</div><div>&gt;</div><div>&gt;&gt; If not, and I replace the failed-disk machine with a brand new machine with</div><div>&gt;&gt; the same name (e.g. rabbit@server1) and simply instruct it to join the cluster</div><div>&gt;&gt; - will everything continue to work as if nothing happened?</div><div>&gt;</div><div>&gt; Yes, that should work.</div><div>&gt;</div><div>&gt;&gt; If I can't, then 2 disk nodes is the better solution, yes? And if I did that,</div><div>&gt;&gt; is recovering from an abrupt failure of 1 of the machines simply to replace</div><div>&gt;&gt; that machine, give it the same name (e.g. rabbit@server1) and call the</div><div>&gt;&gt; rabbitmqctl cluster command? Is that all I would have to do?</div><div>&gt;</div><div>&gt; Again, that should be OK.</div><div>&gt;</div><div>&gt;&gt; I also have a 3rd machine running, which doesn't have any local web app</div><div>&gt;&gt; software which creates or listens for any RabbitMQ messages. Would I benefit</div><div>&gt;&gt; from using that as an additional (3rd) RabbitMQ node still? For example, the</div><div>&gt;&gt; 3rd non-web-app machine as a disk node, and the 2 web-app-clustered (which</div><div>&gt;&gt; load-balance) machines as RAM nodes? And maybe have a RAID disk in the 3rd</div><div>&gt;&gt; non-web-app machine. Is this the best solution of all? Last question, how do I</div><div>&gt;&gt; recover after explicitly removing a disk node (i.e. not through disk failure,</div><div>&gt;&gt; this in addition do the disk-failure question)?</div><div>&gt;</div><div>&gt; See my reply at the top of this message. In general you'd want to measure if RAM</div><div>&gt; nodes give you a real benefit and consider them once you established that. RAM</div><div>&gt; nodes do (durable) resource creation/deletion faster, so if you are using those</div><div>&gt; operation intensively you might get something out of RAM nodes. Everything else</div><div>&gt; is not affected - persistent queue still persist, and transient operations are</div><div>&gt; transient on disc nodes too.</div><div>&gt;</div><div>&gt; --</div><div>&gt; Francesco * Often in error, never in doubt</div><div><br></div>