Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
It seems that few other people including myself had experienced exactly the same problem. I've not seen the answer on this message board, though, I've not looked for few weeks now. A quick solution to my problem was to replace the rc script included in heartbeat source with rc script provided in the rpm distribution. http://www.ultramonkey.org/download/heartbeat/1.2.3/fedora_core_1/ Hope this helps. Best regards, Ilya --- Dave Dykstra <dwdha at drdykstra.us> wrote: > This sounds similar to a case of mine that Philipp > Reisner answered. > The archive is at > > http://lists.linbit.com/pipermail/drbd-user/2005-March/002722.html > > - Dave > > On Thu, Mar 31, 2005 at 06:44:31AM -0800, Shane > Walton wrote: > > Hello, > > > > Consider the following hardware configuration: > > > > Node A connects to Node B by a switched network > and > > Node A connects to Node B 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 > where > > I have both nodes in a standalone state which > requires > > user intervention to reconnect the current PRIMARY > > DRBD node. > > > > 1.) Node A is DRBD Primary and Node B is DRBD > > Secondary > > 2.) I pull the switched network cable from node A > > 3.) Node A detects the failure and HA moves the > > resources to node B > > 4.) Node B is now StandAlone->Primary/Unknown and > node > > A is StandAlone->Secondary/Unknown > > 5.) I reboot node A simulating a NIC replacement > and > > reconnect the switched network cable > > 6.) Node B aborts the node A DRBD connection > > complaining that current Primary would be sync > TARGET! > > 7.) Node A waits on a degraded connection timeout > > forcing the need to run `drbdadm connect all` on > node > > B > > > > I have read through previous posts and have seen > this > > issue mentioned a couple of times with responses > > suggesting to ensure the DRBD net::timeout value > is > > lower than the HA deadtime and other suggestions > to > > configure DRBD over the crossover cable. > > > > The timeout change did not make any difference. > > > > Utilizing the crossover cable adds complications, > such > > as if one of the NICs break utilizing the > crossover > > cable, assuming the cable doesn't go bad, there is > > data loss deciding which node has a bad NIC. > > > > The best base would be for the secondary node to > have > > the bad NIC as it could sync up later. If it is > the > > primary node, HA would have to move resource to > the > > secondary node ignoring the fact that there is > data on > > the primary node that did not get copied to the > other > > node. > > > > So my question, is this the expected behavior of > DRBD? > > > > I appreciate your help with this matter and look > > forward to your reply. > > > > Regards, > > > > Shane M. Walton > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > __________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com