At the risk of repeating something mentioned last week on this thread. One tactic to reduce/avoid the no-directory sync problem is to use WAL mode. The commit in WAL is write to the WAL file, so the the directory sync problem goes away.
If you want to be in paranoid mode, don't trust others. Why not use the backup api before checkpointing and after the checkpoint has succeeded, check that both dbs have the same state before deleting (or archiving) the backup? Another tactic to handle that hasn't been discussed (if memory serves me) that I'm curious if the following would work to get around the directory sync issue: Separate Sqlite telling your program that the transaction is done from the program telling the user. Don't tell the *user* that the transaction is done until you have confirmed the .journal file that existed before your commit no longer exists after it, so a power off rollback can't happen. Could the OS lie and say the .journal file has been deleted only to have it re-appear if the power failure is at the 'wrong' time? The above about implementation of RAID is good. There were battery backed up caching controllers 20 years ago. In the event of a power loss, the cached writes could be completed later. regards, Adam On Mon, Feb 1, 2016 at 10:14 AM, Howard Chu <hyc at symas.com> wrote: > Stephen Chrzanowski wrote: >> >> @Rowan; >> >> First off, whether the OS or SQLite is ACID or not, if you pull the plug >> on >> your hardware, all bets are off on whether it'll BOOT, let alone recover a >> single transaction. I get that this could be a useful tool when doing >> disaster proofing, but, at that stage in the game of bulletproofing, you >> can't win every battle, and you're running into that at 100 miles an hour. > > > Your expectations are pretty low. On a properly configured Unix host, > there's no reason for a powerfail to prevent a successful reboot. E.g., if > you mount boot and root filesystems as read-only filesystems, they can never > get corrupted. If you're using modern filesystems for your writable > partitions (e.g., FSs with journaling) then there's also no reason for them > to fail to come back online. > > So it just comes down to your application code being reliable. > > I should note that SQLightning has none of the problems being described in > this thread - in its default mode, it is full-ACID and a powerfail cannot > lose data or corrupt the database. And it does all this while being at least > 30% faster on writes than vanilla SQLite. > > Yes, the OS could have bugs. Yes, the hardware could physically fail. That's > pretty rare though; HDDs R/W heads auto-retract on powerfail so unless the > entire mechanism actually jammed, there's no way for a powerfail to cause a > head crash or any other destructive event. > > Bottom line - if your OS reboots successfully, there's no excuse for your > database to not also come up successfully, fully intact. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users -- -------------- VerifEye Technologies Inc. 151 Whitehall Dr. Unit 2 Markham, ON L3R 9T1
