<br><div>Hi Simon,</div><div><br></div><div>I am sorry that my post appears all over the place. I am trying to work out a clear understanding of a cluster to advise what not do do to avoid data loss. It is becoming clear that server maintenance must account for the status of the queues in the cluster and great care must be applied to maintain the cluster. I have read the unsynchronised-saves section and basically the cluster buster testing is to&nbsp;purposely&nbsp;break the cluster in the way that the queue&nbsp;synchronization&nbsp;is documented to not handle. By doing this I am learning in more detail about how the cluster actually works.</div><div><br></div><div>After looking at the section again this statement stands out "... ensure that your use of messaging generally results in very short or empty queues that rapidly drain." &nbsp;When dealing with the cluster buster test scenarios I have been using a scenario that a queue is not empty and is not rapidly drained. &nbsp;</div><div><br></div><div>It has us nervous that if each node in the cluster is restarted one at a time and allowed to rejoin the cluster then all data in the idle persistent queues would be lost. Performing Windows updates might be fatal to idle queued data! &nbsp;To clarify the messages are published with&nbsp;persistent&nbsp;on.</div><div><br></div><div>Back to the cluster test scenario....</div><div><br></div><div>I guess the conclusion is the cluster performed as&nbsp;designed&nbsp;and it did require all nodes in the cluster to be started under the 30 second timeout. &nbsp;Although, I am not sure if the erl_crash.dump is expected.</div><div><br></div><div>When all 3 servers were booted things went as expected but with an erl_crash.dump. &nbsp;Each server performed the 30 second search and then shutdown + crash.dump. &nbsp;After I noticed all 3 services were not running I quickly started each service under the 30 seconds and the cluster came up plus no queue data was lost.</div><div><br></div><div>Each server had its relative log&nbsp;</div><div><br></div><div>=INFO REPORT==== 30-Oct-2012::08:36:36 ===</div><div>Limiting to approx 924 file handles (829 sockets)</div><div><br></div><div>=ERROR REPORT==== 30-Oct-2012::08:37:13 ===</div><div>Timeout contacting cluster nodes. Since RabbitMQ was shut down forcefully</div><div>it cannot determine which nodes are timing out. Details on all nodes will</div><div>follow.</div><div><br></div><div>DIAGNOSTICS</div><div>===========</div><div><br></div><div>nodes in question: ['rabbit@RIOBARON-1','rabbit@CUST1-MASTER']</div><div><br></div><div>hosts, their running nodes and ports:</div><div>- CUST1-MASTER: [{rabbit,55021}]</div><div>- RIOBARON-1: []</div><div><br></div><div>current node details:</div><div>- node name: 'rabbit@RIOOVERLORD-1'</div><div>- home dir: C:\Windows</div><div>- cookie hash: MXZdkdzg76BGNNu+ev94Ow==</div><div><br></div><div><br></div><div><br></div><div>=INFO REPORT==== 30-Oct-2012::08:37:14 ===</div><div>&nbsp; &nbsp; application: rabbit</div><div>&nbsp; &nbsp; exited: {bad_return,{{rabbit,start,[normal,[]]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;{'EXIT',{rabbit,failure_during_boot}}}}</div><div>&nbsp; &nbsp; type: permanent</div><div><br></div><div>Then, in the -sasl.log there is the following entry + the "erl_crash.dump" file.</div><div><br></div><div>=CRASH REPORT==== 30-Oct-2012::08:35:40 ===</div><div>&nbsp; crasher:</div><div>&nbsp; &nbsp; initial call: application_master:init/4</div><div>&nbsp; &nbsp; pid: &lt;0.133.0&gt;</div><div>&nbsp; &nbsp; registered_name: []</div><div>&nbsp; &nbsp; exception exit: {bad_return,{{rabbit,start,[normal,[]]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;{'EXIT',{rabbit,failure_during_boot}}}}</div><div>&nbsp; &nbsp; &nbsp; in function &nbsp;application_master:init/4 (application_master.erl, line 138)</div><div>&nbsp; &nbsp; ancestors: [&lt;0.132.0&gt;]</div><div>&nbsp; &nbsp; messages: [{'EXIT',&lt;0.134.0&gt;,normal}]</div><div>&nbsp; &nbsp; links: [&lt;0.132.0&gt;,&lt;0.7.0&gt;]</div><div>&nbsp; &nbsp; dictionary: []</div><div>&nbsp; &nbsp; trap_exit: true</div><div>&nbsp; &nbsp; status: running</div><div>&nbsp; &nbsp; heap_size: 1597</div><div>&nbsp; &nbsp; stack_size: 24</div><div>&nbsp; &nbsp; reductions: 132</div><div>&nbsp; neighbours:</div><div><br></div><div><br></div><div>I do not know if the sasl.log entry has anything to do with the crash.dump file output but I have one.</div><div><br></div><div>=erl_crash_dump:0.1</div><div>Tue Oct 30 08:37:17 2012</div><div>Slogan: Kernel pid terminated (application_controller) ({application_start_failure,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{rabbit,failure_during_boot}}}}})</div><div>System version: Erlang R15B02 (erts-5.9.2) [async-threads:30]</div><div>Compiled: Mon Sep &nbsp;3 11:00:33 2012</div><div>Taints:&nbsp;</div><div>Atoms: 21679</div><div>=memory</div><div>total: 16514240</div><div>processes: 4423098</div><div>processes_used: 4423098</div><div>system: 12091142</div><div>atom: 495069</div><div>atom_used: 481297</div><div>binary: 21864</div><div>code: 9403948</div><div>ets: 27188</div><div>=hash_table:atom_tab</div><div>size: 19289</div><div>used: 13066</div><div>objs: 21679</div><div>depth: 8</div><div>............................</div><div><br></div><div><br></div><div>On Tue, Oct 30, 2012 at 11:49 AM, Simon MacMullen &lt;simon@rabbitmq.com&gt; wrote:</div><div>I am not sure quite what you are saying. You say that when you started the nodes again, none of them successfully started? And there was "an error". But then you started them "quickly" and that worked?</div><div><br></div><div>When each node is started it decides whether it thinks there are any other nodes which were running when it was killed. If so it waits 30 seconds for them to become available and if nothing appears gives an error about "timeout waiting for tables",</div><div><br></div><div>Was this the error you saw?</div><div><br></div><div>We might make this 30 seconds configurable in future, but we need to think of the other case (where people start one node and not the other, and don't realise anything is wrong until the timeout).</div><div><br></div><div>You should also read:</div><div>http://www.rabbitmq.com/ha.html#unsynchronised-slaves</div><div><br></div><div>Cheers, Simon</div><div><br></div><div>On Tuesday, October 30, 2012 9:45:21 AM UTC-5, Mark Ward wrote:</div>