[DRBD-user] Snapshot with DRBD
drbd at bobich.net
drbd at bobich.net
Thu Feb 14 15:06:09 CET 2008
On Thu, 14 Feb 2008, H.D. wrote:
>> I disagree. It's not a solution because syncing the FS isn't sufficient.
>> With LVM you still get the FS level consistency as it is at the time of the
>> snapshot. The problem is that applications like DBs maintain their internal
>> buffers and caches, and these will not necessarily be consistent with the
>> data on disk, FS freeze or not.
>
> Syncing the FS _is_ sufficient. That is why DBMS implement write ahead logs.
> Recovering from a snapshot is the same as recovering from a power failure.
> And if a DBMS can't do that, it doesn't conform to ACID, and no one serious
> would use it. There is no serious DBMS out there that is unhappy with FS
> snapshots, even MySQL / innoDB is fine.
Syncing the FS is sufficient for data safety on the level of journalling
that keeps the FS consistent after a power failure. It is NOT sufficient
for data consistency I would expect from a proper backup.
> In case of XFS it's actually better than a power failure, both meta data and
> data is flushed, as well as an umount record written.
Many file systems have data AND metadata journalling available, including
ext3 (even if ext3 by default only journals metadata).
> Have you ever tried running a DBMS on copyfs? There is a reason why no one is
> doing that. First there is no reason to do it, second performance is
> unacceptable.
No, it never occured to me to run a DBMS on CopyFS. As you quite rightly
point out, there is no point in doing it. As for DB backups, backup up a
replicated server is a much safer and more sensible option than
snapshotting. Even if snapshotting provided consistent images (which it
doesn't), it still impairs the performance of a live server (it
effectively does the same thing CopyFS does). Having a separate replicated
DB server gives you both the guaranteed consistency and doesn't have a
serious performance hit on the master server.
Hmm... I think we've drifted a tad far off the DRBD topic...
Gordan
More information about the drbd-user
mailing list