Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Feb 27, 2015 at 04:16:00PM +0000, Giles Thomas wrote: > Hi Lars, > > On 19/02/15 11:53, Lars Ellenberg wrote: > >On Fri, Feb 06, 2015 at 07:45:49PM +0000, Giles Thomas wrote: > >>Are we right in thinking that the purpose of using LVM [on the secondary during backups] is purely to > >>get a mountable device that you can run the backup from? After all, > >*AND* it keeps you from introducing data divergence aka > >split-brain, which you would later need to clean up. > > So just to make sure I understand that correctly -- you're saying it > stops us from accidentally writing to the secondary while it's > disconnected from the primary. Makes sense, that would obviously be > a Bad Thing. > > [Out of interest, would it be technically feasible for a future > version of DRBD to make the disk available on the secondary in a > read-only state? I assume it wouldn't be easy (as otherwise it > would probably have been done), and I'm not necessarily advocating > it as a new feature -- but I am wondering if there are any deep > technical barriers that would make it completely impossible.] We have that already. But it does not help you much, unless you have some layer that deals with cache coherency issues. People already repeatedly had the impression that DRBD would make their not even crash-safe application suddenly both crash-safe and cluster aware, or magically turn ext4 into a cluster file system or similar. Making it too obvious how to access a secondary read-only would make them believe that, ok, I cannot turn ext4 into a cluster filesystem, but at least I can mount it read-only ... Yes you can. But, due to cache consistency issues, it will lead to corruption, and eventually even kernel panics -- if you are lucky. There is only one valid use case I know of, and that is some sort of proprietary database replication using DRBD as an on-disk ring-buffer write-ahead journal, which is obviously aware of the cluster, DRBD, and any cache coherency issues. Ok, and with DRBD 9 and drbd-manage, drbd-manage itself is an other use case. But that's slightly different, using the auto-promote feature of DRBD 9, and would only allow RO open on a secondary that does not see any primaries. (Which would cover your use case of disconnect, then open RO). Any other use case can be handled just fine without this, and in fact most likely can be handled *better* without this. So you really don't want to know how to enable it. Thanks, -- : Lars Ellenberg : http://www.LINBIT.com | Your Way to High Availability : DRBD, Linux-HA and Pacemaker support and consulting DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed