Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, Thanks for your answer , i only hava one last question. I got two nodes one primary and one secondary like these: Node 1 connects to Node 2 by a switched network and Node 1 connects to Node 2 by a crossover cable. Consider the following software configuration: DRBD communicates over the switched network and Heartbeat (HA) communicates over both networks. Now, following these steps I can repeat the case when i have both nodes in a standalone state which require user intervention to reconnect the current PRIMARY DRBD node. 1.) Node 1 is DRBD Primary and Node 2 is DRBD Secondary 2.) I pull the switched network cable from node 1 3.) Node 1 detects the failure and HA moves the resources to node 2 4.) Node 2 is now StandAlone->Primary/Unknown and node 1 is StandAlone->Secondary/Unknown 5.) I reconnect the switched network cable from node 1 and it is at this moment when i got "split-brain". my question is, there is any posibility to avoid the "split brain" situation when y reconnect the cable from node1? Thanks Best Regards Abraham OLIVARES Lars Ellenberg <lars.ellenberg at linbit.com> escribió: On Fri, Aug 10, 2007 at 12:57:03PM +0000, paddy at panici.net wrote: > On Fri, Aug 10, 2007 at 04:05:02AM -0500, Abraham olivares Varela wrote: > > Hi everybody, > > > > > > Does anybody knows how can i configurate the Automatic split-brain > > recovery strategies, in order to avoid a "split brain situation". ? > > > > any example or any idea to do it that. > > > > please help me > > > > On the one hand you talk about recovery and on the other hand you > talk about avoiding it. > > I fear you may already be incurable ;-) > > > Do you *ever* want to go split brain. are there scenarios for you where > that would be preferable and you want to think about what you are going > to do afterwards, or would you prefer to avoid it ever happening ? basic problem is, that currently, with drbd 8 and two-primaries, as necessary for cluster file systems, drbd will _always_ run into a resource-internal (drbd specific) split brain as soon as you lose the replication link, even if it is a very short network hiccup, even if there has been no io on-the-fly. that is because we did not yet implement any freeze-io due to loss of write-quorum for drbd8 yet. so as of now, if you want to use cluster file system with drbd8, and you expect network hiccups, you run into "split-brain". then you either always need to recover this by hand. your you can configure some non-intrusive after-split-brain handler, like the "discard-zero-changes", which would have nothing to "discard", and "feature" auto-rejoin when there had been no-in-flight io, or no changes on one side. once you start using destructive settings, "auto-recovery strategies" get very ugly very quickly, though. and they are not a solution to the problem, but only a work-around for those that commonly run into these problems, e.g. people how configure two-primaries, but usually only accessing it exclusively from one node (xen images). if you have a network hiccup here, you will only have changes on one node, so you are fine with the "discard-zero-changes" option. solution is related to the implementation of (dynamically reconfigurable) write-quorum, suspending IO as soon as we lose quorum, then timeout, arbitrate, retransmit, resume ... sorry, no time frame on that, besides "as soon as possible", we are very busy with a lot of things around here :) -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client. _______________________________________________ drbd-user mailing list drbd-user at lists.linbit.com http://lists.linbit.com/mailman/listinfo/drbd-user --------------------------------- ¡Sé un mejor ambientalista! Encuentra consejos para cuidar el lugar donde vivimos. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20070813/dacb4cc6/attachment.htm>