Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 2009-11-27 18:37, . Honmans wrote: > If it is not possible now, would be possible in future for a > primary/primary split-brain to be resolved by keeping track of "recently > updated" data on the two nodes and merge the changes rather than rolling > them back on one of the nodes as in > http://www.drbd.org/users-guide-emb/s-resolve-split-brain.html ? Nope. I mean it technically would be possible, but it would be a sure fire way to _completely_ wreck your filesystem, which would be blissfully unaware of such a merge. And then what would you do with a block which was modified on both nodes? Sorry, forget that. > Obviously a primary/primary configuration will be anarchy unless there > is coordination between peers at a higher software level - such as the > Proxmox VE software which "knows" which of the peers each VM is running on. > > Can DRBD make use of that information to synchronise regions of a > resource in different directions - or would it be possible to add that > as a feature at some future date? > > For example, if we have LVM on top of DRBD (say /dev/drbd0), and each VM > has a distinct Logical Volume for its virtual disk... > > VM vm1 on LV vm1data - currently running on peer A > VM vm2 on LV vm2data - currently running on peer B > > When resolving split-brain, the region of /dev/drbd0 occupied by LV > vm1data is synced from peer A to B, and the region occupied by vm2data > is synced from B to A. > > In effect, there would be synchronisation of regions of resources rather > that whole DRBD resources. Use 2 DRBD resources. > In the meaintime, any more information on resolving primary/primary > split-brain conditions would be very welcome. Don't let that happen. :) When you run into replication breakage, you really need to kick one node out of your cluster. Quickly. Check the drbd.conf manpage for the "fencing resource-and-stonith" option, and boot one of your nodes. There will be some more information about this in the DRBD User's Guide with the next maintenance release. Cheers, Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20091130/6a4154c0/attachment.pgp>