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, 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