Up: Data Integrity [Contents][Index]
To keep the database on disk in an intended state at all times, nonblonde never overwrites existing data. Instead, when there’s data to be written, a new database state is formed next to the existing one. The difference between the states is the set of changes made by the transaction being committed. When the new state is on disk, nonblonde switches to it atomically.
nonblonde databases are organized into two sections (with currently one file per section): the data store proper and a page map, mapping page ids to file offsets.
When a transaction is committed to disk, the data store is written first. Then a record is added to the page map, which is organized as a log (for which reason periodic compacting is required).
The greatest risk of data corruption comes from data being written to disk in an order other than the one nonblonde required and having the writing interrupted midway. Again, power failures are the most likely cause of bad data.
To protect against corruption from inconsequentially written data, the application would synchronize the database files (though the operation is slow and damaging to overall performance). File synchronization is not a requirement, data is eventually written to disk, at the operation system discretion. Synchronization is just a mean to reduce the time during which the disk file does not reflect its intended content.
When nonblonde synchronizes the database files, it does so first on the data store file, and then on the page map, as a danger comes from the page map recording changes not yet on disk. A longer and possibly safer route to committing data is to write the data store first, synchronize the data file, write the page map and synchronize the page map file.
If the data had been indeed corrupted due to inconsequential disk writing, it should be possible to restore the pre transaction state by removing the last record in the page map. The latter can be achieved by removing a single byte at the end, with nonblonde removing the entire now incomplete record at database opening.
To give a better chance of recovering a proper database state and not having to synchronizes the database files too frequently, nonblonde keeps not two, but more (a few dozen) past states on disk. With the difference between the states given of course by the same number of past transactions.
Up: Data Integrity [Contents][Index]