On Wed, Aug 16, 2017 at 07:05:41PM +0200, pub...@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
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user
