On 09/11/2012 01:21 PM, Keith Chew wrote:
Hi Dan

In both NORMAL mode, we do the following:

   1. Write a bunch of transactions into the WAL file.
   2. fsync() the WAL file.
   3. Copy the data from the WAL file into the database file.
   4. fsync() the database file.

If a power failure occurs at any time, the next process to read the
database scans the WAL file and attempts to read as many transactions
as possible. If the checksum fails at any point, it stops reading.

So you can lose data. Say a power failure occurs between steps 1
and 2 above. If your WAL had 5 unsynced transactions in it then
following recovery you may find that none, some or all of them have
survived, depending on how much of the WAL file actually made it
to disk before the power failed.


Thank you very much for the explanation, it is very clear! I have one
last question.

In my ext3 file system, I have set barrier=1, disables write cache,
and also set commit=1 for per second disk sync from the kernel. In
your opinion, if I used NORMAL, would it mean:
(1) The most number of transactions I can lose in the WAL file is 1
second's worth?
(2) If the WAL contained say 10 seconds worth of transactions (1
transaction per second) before the power failure, and the 11th second
the transaction failed to make it, ie stuck between your step 1 and 2,
will the first 10 seconds worth of transactions still make it? I
presume yes, since you have checksums in the WAL file?

That sounds right to me. The first 10 seconds worth of transactions
and their checksums will have made it to disk so SQLite will be able
to recover them the next time the db is opened.

(3) If there is a power failure anywhere between steps 2, 3, and 4, I
presume that will be OK, since the recovery will be done on next
startup.

Right. Once step 2 has taken place your transactions have been synced
to disk. So even if a power failure occurs before they are copied into
the db file, they can't get lost.

Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to