Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, On 04/17/2012 09:11 PM, Jacek Osiecki wrote: > after-sb-0pri discard-zero-changes; > after-sb-1pri discard-secondary; > after-sb-2pri disconnect; alright. > [287856.622136] block drbd0: Split-Brain > detected, 1 primaries, automatically solved. Sync from this node Acknowledged - your automatic resolution works fine. >> A policy of discard-zero-changes could solve this for you, but only if >> configured thus. > > Seems that my config is lacking this. It's not, your config is quite fine. (Although Linbit has suggested "consesus" for the 1pri case in the past, which certainly appears safer - if for any reason your one primary is the one that has old data, you loose everything since then with discard-secondary). Note that there is no safe sb-2pri setting to solve the split-brain automatically. You really do not *want* DRBD to try and fix itself in this situation. In a dual-primary setup, a sufficiently bad network hiccup will cause this split brain situation. That's why you want stonith to make sure you don't end up with actually diverged datasets. Long story short - if you have two primaries that disagree about history, you want to handle this manually. As far as I know, the number of bits that are set in the quicksync bitmap is a helpful clue that tells you which node has had more changes written. > Are there any mechanisms that would be capable of > synchronizing the nodes (when node-node communication is up again) on > filesystem level? Tools like unison or rsync spring to mind. Still, even if you find a sane way of doing a merge with those, there will be a lot of block-level syncing to do *after* the merge. Cheers, Felix