[DRBD-user] Question about using DRBD to do snapshots on AWS EBS volumes

Giles Thomas giles at pythonanywhere.com
Thu Mar 5 17:40:04 CET 2015

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 Thomas <giles at pythonanywhere.com>

PythonAnywhere: Develop and host Python from your browser

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

More information about the drbd-user mailing list