[DRBD-user] drbd or rsync?

Lars Ellenberg lars.ellenberg at linbit.com
Wed Apr 8 20:19:06 CEST 2009


On Wed, Apr 08, 2009 at 01:34:43PM -0400, Greg Freemyer wrote:
> On Wed, Apr 8, 2009 at 1:13 PM, Peter Sabaini <peter at sabaini.at> wrote:
> > On Wednesday 08 April 2009 18:38:54 you wrote:
> >> > A crucial factor is wether you can tolerate stale data. Running rsync
> >> > periodically will probably result in not-quite-uptodate replication when
> >> > the storm troopers come rushing in and cut your power. If that is not a
> >> > concern, eg. because your data doesn't change all that often, or you
> >> > simply don't care about a few lost updates, then rsync is IMHO simpler to
> >> > set up.
> >> >
> >> > In contrast, DRBD does real replication. Depending on your link/network
> >> > quality and the chosen protocol you can guarantee that local writes are
> >> > only considered complete if the remote side also has completed.
> >>
> >> Maybe it is a re-incarnation of executive order 6102, to melt down the
> >> servers for their gold content?
> >>
> >> Anyhow, provided the bandwidth is sufficient, I prefer the DRBD
> >> option.  However, will the backups be successful, if the backup drive
> >> is attached to the secondary?  Most of what I've read suggests that
> >> you shouldn't even mount the secondary in read-only mode (although
> >> maybe an LVM snapshot can be mounted for taking a backup).
> >
> > DRBD won't allow you to mount a secondary. This means you either have to use a
> > Dual Primary setup (requiring a cluster filesystem) or make a block-level
> > backup (don't know if thats adivsable). Maybe you can temporarily disconnect
> > DRBD for the backup, promote the secondary, mount + backup, demote again, and
> > reconnect -- Im not really sure if this would work though, you'd have to try.
> >
> > peter.
> 
> I also don't think a snapshot will work either.  The first step in
> creating a snapshot is to quiesce every thing, then create the
> snapshot.  Since the quiesce would have to happen on the primary, I
> don't think you could properly coordinate a snapshot being created on
> the secondary.
> 
> If tape is critical to your situation, you may need to stick to rsync.
> 
> FYI: I think this should be added to the drdb wishlist.  I think some
> commercial SAN devices that replicate have to ability to mount the
> remote copy by using snapshot technology on the remote.
> 
> And I know some support what Peter describes which is effectively:
> 
> quiesce primary

xfs_freeze -f  # or pick your favorite equivalent

but, you have to be aware that "quiesce filesystem" (which is what a
local lvm snapshot would implicitly try to do for you on recent Linux
OS), is _not_ the same as "quiesce primary".
you need to actually "quiesce" all applications as well...

[*] but see below.

> stop block transmissions from primary to secondary

drbdadm disconnect

> mount secondary in read-only form
> perform backup
> unmount secondary
> release drdb to continue updates

even mount -o ro _does_ rw access to the device in general (update
superblock, replay journal...).  and drbd does not and will not support
to mount a device in secondary role.

still, you can introduce an arbitrary "split brain" here,
make it primary, and mount -o ro that one,
then later connect --discard-my-data, to revert potential (minimal)
local changes and apply changes done on the remote "real/production"
primary since the disconnect.

> If drdb doesn't support that, I'd also like it to go on the wishlist.

[*] much easier, and already suggested:
just do an lvm snapshot below the drbd on secondary,
and mount that one readonly.

ignore the "quiesce" point, or replace it with a simple "sync;".
if your file system and applications are able to recover from
a crash, they are able to recover from a snapshot while taken
even when not "quiesce"d.
if they are not able to recover: don't use them.

of course, for any applications supporting "checkpoints",
it would shorten the necessary recovery time if you
set a checkpoint on the active node just before
you take the snapshot on the secondary.

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

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


More information about the drbd-user mailing list