[DRBD-user] Response to Mr. Ellenberg's answer to: "Warning: If using drbd; data-loss / corruption is possible; [...]"

Lars Ellenberg lars.ellenberg at linbit.com
Thu Aug 17 11:04:04 CEST 2017

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Wed, Aug 16, 2017 at 07:05:41PM +0200, public at thomas-r-bruecker.ch wrote:
> Dear Mr. Ellenberg,
> 
> I thank you for the profound explanation of the issues of my settings.
> 
> Ok. at the moment, the scope where I am using this configuration is either
> experimental, and I use it as a replacement of transferring date by "rsync"
> (with "rsync", I had to wait about 6h till my data has been synchronized,
> with drbd at about 20 min to 1h; so 'drbd is much better' anyway.).


> Because you advise me against using the drbd-device as I intended, I have
> to discuss it with my boss if we at all ...; so I allow myself, to cc.
> this mail to my boss (blind carbon copy), and attach "your response to my
> former letter" to this mail.

You may want to forget about "ahead",
and just do a scheduled "connect ; wait sync; disconnect",
if that is really what you want.

Given your context knowledge,
you can even do that during "convenient" times.


Actually what we (and others) have done in production for a long time:
Have a drbd 8.4 "protocol C" production cluster for on-site redundancy,
with stacked "protocol A" replication to an other two node off-site cluster.

One of those would be scheduled to disconnect,
take a new snapshot and delete old snapshots as per retention policies
(using lvm thin in this case, but technology does not matter).

We'd then use these snapshots as base images for point-in-time recovery
of data bases, or to (test) drive reports, or to test changes,
with a data set that is as close to production as possible.

Perfectly good use case for DRBD.

Just the "ahead/behind" stuff is only really useful with a "huge"
buffer, and even then should be considered an emergency break.
It is NOT a "beam my TiB/s change rate over a GSM link without
production impact".
It is not meant to be "normal processing for every request", either.


And yes, we obviously have bugs in that ahead/behind code,
you hit (some of?) them. But when using it "in spec",
they don't trigger (or we'd had a lot of angry customers).


That being said,
again,

> > If you want snapshot shipping,
> > use a system designed for snapshot shipping.
> > DRBD is not.

Cheers,

-- 
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker

DRBD® and LINBIT® are registered trademarks of LINBIT
__
please don't Cc me, but send to list -- I'm subscribed



More information about the drbd-user mailing list