Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Digimer, Thanks for your reply! Yes, I understand fencing can prevent split-brains. But in my case it maybe not sufficient. Let me clarify my use case. Basically, you can get the architecture from http://ibin.co/2YoKo5VOmRYn The app on each client server will do I/O via block interface directly instead using a cluster file system. Every client server need write access to all drdb volumes to build a VG group. But the application can guarantee that no two servers write to the same data area at the same time because it just writes to the data belonging to itself even when spli-brain happens. So merging data I mentioned before means just pull all newest data from different volumes together. For the suggestion of fencing, I think it still can cause somehow out-of-sync because the fencing is invoked by cluster management software, but in data plane the I/O could be done before the fencing happens. my understanding is that fencing is invoked by the cluster management software asynchronously. On Wed, Mar 2, 2016 at 1:07 AM, Digimer <lists at alteeve.ca> wrote: > On 01/03/16 09:43 AM, Mark Wu wrote: > > Hi guys, > > > > According to > > http://drbd.linbit.com/users-guide-9.0/s-dual-primary-mode.html, > > DRBD-9.1 will support multiple primaries. I am wondering if it can > > also enhance the auto reovery from split brain. It seems that currently > > we don't have a good solution of recoverying from split brain without > > data loss when dual primary is configured. I think it will be good to > > have a policy to merge all up-to-date data. > > > > I am considering to build a storage pool by aggregating remote drbd > > volumes into a VG and then any client can write to LV created in the VG. > > This solution can remove the limitation of single host's storage > > capacity when thin provisioning is enabled. > > If thin-provisioning is enabled with drbdmanage, the new-added storage > > servers can't help the node which runs out of storage space. > > > > > > That's why I care about the case of multiple primaries. Thanks for any > > feedback! > > Fencing prevents split-brains in the first place, use it. > > As for auto-recovery in dual-primary; > > Consider that DRBD is not aware of data structures. So there is no safe > way to say how to merge data back. It would have to be done at the > FS-layer. If you simply said "well, sync over the node with older data", > or "sync over the node with fewer changes", consider this scenario; Your > accounting data is updated on one node, then sometime later, an ISO > image is written to the other node. I am pretty sure that the older, > smaller changes are a lot more valuable. > > -- > Digimer > Papers and Projects: https://alteeve.ca/w/ > What if the cure for cancer is trapped in the mind of a person without > access to education? > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20160302/524a16c9/attachment.htm>