On 12/10/2014 05:06 AM, Simon Slavin wrote:
On 9 Dec 2014, at 8:57pm, Nick <maill...@css-uk.net> wrote:
Environment is Linux with multiple (c. 4-6) processes accessing a single sqlite database
named "test.db".
Backup:
- New process started using cronjob to initiate application checkpoint until
completion.
- rsync diff the file "test.db" to another drive/location (specifically ignoring the
"-shm" and "-wal" file).
- exit process
Restore:
- rsync the file "test.db" from another drive/location.
Will not be trustworthy if the database is being written to during the rsync
operations.
Strictly speaking the database file may not be well-formed even if there
is no ongoing checkpoint. If:
a) process A opens a read transaction,
b) process B opens and commits a write transaction to the database,
c) process C checkpoints the db,
then the db file considered without the *-wal file may be corrupt. The
problem comes about because process C can only checkpoint frames up
until the start of B's transaction. And there is an optimization that
will prevent it from copying any earlier frames for which there exists a
frame in B's transaction that corresponds to the same database page. So
it effectively copis only a subset of the modifications made by earlier
transactions into the db file - not necessarily creating a valid db file.
Dan.
A) Ensure all processes besides the backup process have the database closed
while it is being copied. Establish some kind of semaphore so they can tell
when it's safe to open the database again.
B) Use the SQLite Backup API which was invented to do what you want.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
