Miles Nordin wrote:
gp> Performing a checkpoint will perform such tasks as making sure
gp> that all transactions recorded in the log but not yet written
gp> to the database are written out and that the system is not in
gp> the middle of a write when you grab the data.
great copying of buzzwords out of a glossary,
Wasn't copied from a glossary, I just tried to simplify it enough for
you to understand. I apologize if I didn't accomplish that goal.
but does it change my
claim or not? My claim is:
that SQLite2 should be equally as tolerant of snapshot backups as it
is of cord-yanking.
You're missing the point here Miles. The folks weren't asking for a
method to confirm their database was able to perform proper error
recovery and confirm it would survive having the cord yanked out of the
wall. They were asking for a reliable way to backup their data. The best
way to do that is not by snapshotting alone. The process of performing
database backups is well understood and supported throughout the industry.
Relying on the equivalent of crashing the database to perform backups
isn't how professionals get the job done. There is a reason that
database vendor do not suggest you backup their databases by pulling the
plug out of the wall or killing the running process. The best way to
backup a database is by using a checkpoint. Your comment about
checkpoints being for systems where snapshots are not available is not
accurate. That is the normal method of backing up databases under
Solaris among others. Checkpoints are useful for all systems since they
guarantee that the database files are consistent and do not require
recovery which doesn't always work no matter what the glossy brochures
tell you. Typically they are used in concert with snapshots. Force the
checkpoint, trigger the snapshot and you're golden.
Let's take a simple case of a transaction which consists of three
database updates within a transaction. One of those writes succeeds, you
take a snapshot and then the two other writes succeed. Everyone
concerned with the transaction believes it succeeded but your snapshot
does not show that. When the database starts up again, the data it will
have in your snapshot indicates the transaction never succeeded and
therefore it will roll out the database transaction and you will lose
that transaction. Well, it will assuming that all code involved in that
recovery works flawlessly. Issuing a checkpoint on the other hand causes
the database to complete the transaction including ensuring consistency
of the database files before you take your snapshot. NOTE: If you issue
a checkpoint and then perform a snapshot you will get consistent data
which does not require the database perform recovery. Matter of fact,
that's the best way to do it.
Your dismissal of write activity taking place is inaccurate. Snapshots
take a picture of the file system at a point in time. They have no
knowledge of whether or not one of three writes required for the
database to be consistent have completed. (Refer to above example) Data
does not hit the disk instantly, it takes some finite amount of time in
between when the write command is issued for it to arrive at the disk.
Plainly, terminating the writes between when they are issued and before
it has completed is possible and a matter of timing. The database on the
other hand does understand when the transaction has completed and allows
outside processes to take advantage of this knowledge via checkpointing.
All real database systems have flaws in the recovery process and so far
every database system I've seen has had issues at one time or another.
If we were in a perfect world it SHOULD work every time but we aren't in
a perfect world. ZFS promises on disk consistency but as we saw in the
recent thread about "Unreliable for professional usage" it is possible
to have issues. Likewise with database systems.
Regards,
Greg
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
