Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Lars, On 27/02/15 16:36, Lars Ellenberg wrote: > 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. Understood :-) Thanks. All the best, Giles -- Giles Thomas <giles at pythonanywhere.com> PythonAnywhere: Develop and host Python from your browser <https://www.pythonanywhere.com/> A product from PythonAnywhere LLP 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number OC378414. Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK