[DRBD-user] Use DRBD and LVM Snapshots to create a point-in-timereplica
Ross S. W. Walker
rwalker at medallion.com
Fri Jan 12 00:53:19 CET 2007
> -----Original Message-----
> From: drbd-user-bounces at lists.linbit.com
> [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Lars
> Sent: Thursday, January 11, 2007 8:22 AM
> To: drbd-user at lists.linbit.com
> Subject: Re: [DRBD-user] Use DRBD and LVM Snapshots to create
> a point-in-timereplica
> / 2007-01-11 12:29:11 +0100
> \ Ralf Schenk:
> > Ross S. W. Walker schrieb:
> > > As the subject says I want to know if it is possible to
> use DRBD and LVM
> > > snapshots to create a point-in-time replica?
> > >
> > > This would allow me to rotate snapshots in a pattern that
> would provide
> > > the best consistency/coverage for my needs.
> > >
> > Hello !
> > I do this on a server pair with DRBD 8.0pre6 under XEN. I
> think you will
> > have to use DRBD 8.X because only later DRBD Versions claim to run
> > without problems on top of LVM Volumes.
> drbd 0.7 is also fine on top of lvm
> (thats our typical setup: md - lvm - drbd)
> or below lvm (as pv)
> or even (if you really want to have a headache) in some weird
> lower lv as storage of drbd as pv for some upper vg setup.
> > I snapshot the underlying LVM Volumes readonly and do rsync style
> > rotating Backups with the help of dirvish (http://www.dirvish.org/).
> you probably should snapshot them rw, so the file system is able to
> replay its journal. you obviously should mount them ro, of course.
> > To have consistent backups of my MySQL Databases I have a
> small perl-skript
> > that runs before the backup which commits a "FLUSH TABLES WITH READ
> > LOCK" to the MySQL Database. After the skript has taken the
> LVM Snapshot
> > via "system" calls I do "UNLOCK TABLES" so the tables are unlocked.
> right. so you know that at least the the mysql tables are consistent
> in the snapshot.
> > Usually this takes about 1-3 seconds and sessions that
> attempt to write
> > to MySQL wait longer for response so that only a short lock
> can be detected.
Sounds interesting, but I am hoping to take things 1 step further. The
drbd volumes will be exported via iSCSI to Windows hosts that will be
running Exchange, SQL server and MS Virtual Server off them. I currently
do not have a reliable way to put these volumes into a consistent state
before snapshotting them, so I am leaning towards using drbd for
Exchange and Virtual Machines full time using Prot A (asynchronous), and
using the SQL Server Log Shipping to keep backup databases current.
The replicas will be geographically disperse linked together over a
single T1 line. It's the T1 line that I am unsure about and will most
likely be the weakest link in this.
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.
More information about the drbd-user