Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2006-10-29 09:57:11 -0800 \ sidimustafa: > Server A: acts is primary for drbd0, drbd1 and drbd2 and secondary for drbd3 > resources [lun0, lun1, lun2] > Server B: acts is primary for drbd3 and secondary for drbd0, drbd1 and > drbd2resources [zim0] > ** Pull the plug [server B]: DRBD3 Resource was brutely murdered, and never > survived [brute force - no more electricity] > DRBD3 Resource does not fail over to Server A [due to the next issues, the > intire heartbeat resource don't start] so. would you please give more details on this one. log files? what did drbd say? what did heartbeat say? > DRBD3 Resource goes in Secondary Mode on server A. uhm, it stays secondary, or it "goes" secondary? > Server B is restarted, DRBD Service gives it's warning at startup, which one? > and after a few seconds it connects with Server A, and heartbeat still > didn't pull over the DRBD3 Resource. why would you expect it to? what did it say? what did drbd say? > DRBD3 resource now shows Secondary on both Server A and Server B and "connected" or what? any resync? any side "inconsistent"? > Once server B is up and running the following was done on Server B: > "drbdadm -- --do-what-I-say primary zim0" <-- the DRBD3 resource in > question. why do you think you have to use that ugly flag? you really should not, unless you want to take the blame for anything that goes wrong. > "drbdadm -- connect zim0" <-- the DRBD3 resource in question. why would you need to connect it here? it should have been connected all along. I'd like to see facts, not funny desciptive stories. let us see the heartbeat and kernel logs. show the output of /proc/drbd before you do manual intervention. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.