On Fri, Feb 01, 2013 at 07:24:52PM -0500, Digimer wrote: > The need for a resync is because you didn't have a fence device setup so > it split-brained. If you use it with the 'crm-fence-peer.sh' fence > handler this would not happen.
Even if DRBD "split-brained" (experienced data divergence), there won't be a need for "full sync". As each node tracks which block was modified without being replicated, at a granularity of 4kB, even after data-divergence (split brain), you just have to tell them the direction of the resync. > Even without DRBD you will need fencing in a cluster to maintain sanity > and avoid losing data. That is true. > On 02/01/2013 06:39 PM, Paul Archer wrote: > > Thanks so much for the quick, detailed, and informative answer! > > I'll definitely go with building the latest and greatest of corosync > > and pacemaker. > > As far as the cluster I already have setup, I'll have to get those > > configs on Monday. Oh, and FWIW, I tried using DRBD with KVM, but > > found it too fragile. If I lost a node, the whole block device > > needed to be synced. That would be *very* unexpected. "Whole block device", or "full" resyncs should be really rare with DRBD, and usually are a result of either a conceptually broken setup, or indication of a bug in DBRD. Sometimes, it was just a misunderstanding, because /proc/drbd shows something about some 100% ... but those are the 100% of the to-be-resynced blocks in this particular resync, not the 100% of the device... > > I settled on the latest version of gluster instead. Resyncing is > > faster, as the files for the individual VMs can be synced. Whatever works best for you. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
