Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Feb 05, 2009 at 12:45:33PM +0100, Franco Cristini wrote: > > Hello Lars, > > Lars Ellenberg wrote : >> so currently the "node1" gets its data from "node2". > > Yes. > >> I suggest that >> you should simply do a switchover now to node2, i.e. >> stop vms on the "diskless" node, >> make drbd Primary on the still good node, >> start the vms on the still good node. > > Ok > >> then do whatever is neccessary to replace the bad parts in the broken >> node. >> once that is done, >> reconnect DRBD, (vms still running on the "node2", the still good node) >> let it resync, >> then start whatever cluster manager you use. > > Simply with "drbdadm connect" and "drbdadm attach" on node1? > >> downtime: no more than whatever it takes you to cleanly shutdown the >> vms, and restart them one the still healthy node. > > Ok > >>> But my version 0.7.25 don't have this option on drbdadm, >> meta data gets created implicitly with drbd 0.7. > > Good, also without doing drbdadm invalidate vm1 on node1? > Or is more safe? > I have recreate the entire virtual disk /dev/sdc as new array on LSI > controller and SHOULD not contain old drbd corrupted data. > > The "funny" thing is that the 2 hard-drive on the raid5 of node1 not > have nothing of bad, for some strange reason was being temporary > disconnected form scsi bus for some seconds, but sufficient for > invalidating the entire virtual disk /dev/sdc1 and forcing drbd to > detaching it!! :( > >>> 8) During the synchronization process, i can mount and use /dev/drbd on >>> node1, right? :) >> you may. after stopping services on the healthy node, > > Of course. > >> and making the sync target Primary. > > But i need to wait the resync is complete on node1 (that take data form > node2) for promoting drbd on node1 to primary OR i can promote node1 to > primary also just after the restart (and after drbdadm attach and > "drbdadm connect" of course to the resource vm1)? > > I ask this question because for me is not so clear if DRBD automatically > understood that the data on backing storage on node2 is good and sync > data from node2->node1 REGARDLESS the role of DRBD device on node1 > (secondary or primary). currently _there is no more data on the node1_. so what do you think node1 now gets its data from? and, what do you think node1 would get its data from, again, later, once you fixed it, and it is resyncing? right. from the only surviving data set, on node2. via the network. and what do you think will happen, if you have a minor network glitch during the period where node1 does not have good data? right. *boom*. so even though DRBD _allows_ you to make a sync target Primary, it is not really a good idea. but yes, you may make it primary even while it is still synctarget. >> but why would you? > > your vms run on the healthy node just fine, I think... > > Because the node 2 is used only for data backup, the CPU is not > performing well as node1. well, that is not a good idea either. as we say on http://blogs.linbit.com/florian/2007/06/22/performance-tuning-drbd-setups/ ... don’t buy a crappy box for use as the Secondary ... -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed