Thinking about this a bit more, would a setup with btrfs on top of DRBD be a setup that comes in the neighboorhood of what SnapMirror provides? DRBD does replication at the blocklevel, without any notion of a filesystem on top of it (as I understand this). So, if I make a snapshot on a DRBD'ed btrfs filesystem, this snapshot would also get replicated at the DRBD level. Provided I put the DB in a consisted state before making the snap, I have a remote consistent copy of this DB. This copy can be used as a failover target or as a basis for restore.
Am I correct? On Tue, Aug 31, 2010 at 8:30 AM, Simon Kirby <s...@hostway.ca> wrote: > On Mon, Aug 30, 2010 at 11:14:51AM -0700, K. Richard Pixley wrote: > >> On 20100830 10:59, Roy Sigurd Karlsbakk wrote: >>>> I think drbd does precisely what you want. >>>> >>>> It's not useful for fault tolerance, nor for load balancing, but it >>>> will >>>> produce a remote block copy that can be used as a sort of "hot >>>> backup". >>> drbd with heartbeat/pacemaker can provide fault tolerance... >> I think that's a matter of semantics. >> >> Once you've failed over from the primary system to the secondary, >> changes to your block device are terminal. It's not easy to produce a >> system which can manage those changes and "heal" in the sense of >> allowing the primary system to return to service. In effect, returning >> the primary system to service requires taking both systems down and >> copying the block device from the secondary back to the first. > > This is totally incorrect. DRBD replicates in both directions quite > well, in fact. I've been using it on about 60 machines for many years, > and I have never had to do what you mention. > > What it does not help with is avoiding corruption that occurs above the > block layer; eg, if your file system or your database on top of it barfs, > there is no other "good copy". fsck or repair is still required in these > cases. It is just like local RAID 1 in this respect -- you still need a > backup and/or copy at the file level, which is closer to what is needed > here. > > Simon- > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
