Thanks all for the responses. Just want to clarify the scenario one more time:-
-by syncing, I mean taking the modifications on the active machine and sending over wire to another machine(in some proprietary format) , where there is a similar sqlite application which receives the records and the records are written to a sqlite db residing on that machine using a sqlite apis. -when the two sqlite applications come up on the active and standby machines for the FIRST time, we ALSO do a rsync of the sqlite db from the active to standby to make them same and then subsequently sqlite applications keep in sync using the mechanism I highlighted in 1 above. In this process, when we do a rsync, does it make sense to copy the journal file which was created by the application, so that after the rsync is completed and the sqlite application on the standby side comes up, it can recover any lost transactions before it starts to receive record by record copies which it will write to its own db using sqlite apis. I hope I have not introduced more confusion. -mayank -----Original Message----- From: sqlite-users-bounces at sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of R.Smith Sent: Friday, February 13, 2015 1:15 AM To: sqlite-users at sqlite.org Subject: Re: [sqlite] sqlite journal file question This was my initial reading too Paul, but reading the OP post again it could be either - who knows what is meant by "syncing". I also think this is the main point for the OP - If by syncing he really means "copying the file" then Richard's advice, else if he means "adding via normal DB connection" then the other options. If the DB files are copied, it needs to be copied in perfect version sync, so the program/service filling the DB needs to be informed to wait a moment while copying. I still think for this scenario the backup API would be better. Otherwise, posting SQL to the second DB would require no such trickery, no wait-states and be a lot less IO intensive. On 2/13/2015 10:16 AM, Paul Sanderson wrote: > Richard > > I read that the db on the standby machine is being updated at a record > by record level, i.e. not copied in its entirety. In this scenario I > can't see the two db files being guaranteed binary compatible. Copying > the journal across in this scenario would imo be a mistake. > Paul > www.sandersonforensics.com > skype: r3scue193 > twitter: @sandersonforens > Tel +44 (0)1326 572786 > http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-To > olkit > -Forensic Toolkit for SQLite > email from a work address for a fully functional demo licence > > > On 13 February 2015 at 02:47, Richard Hipp <drh at sqlite.org> wrote: >> On 2/12/15, Mayank Kumar (mayankum) <mayankum at cisco.com> wrote: >>> Hi All >>> >>> We have two systems which are running in active/standby >>> configuration. The active machine, is actively writing sqlite transactions >>> to a file abcd.db. >>> The standby is syncing the abcd.db file from the active machine on >>> a communication channel and writing the delta records to the >>> abcd.db on the standby machine. >>> >>> Now my question is , lets say the active machine crashes in the >>> middle of the transaction and we have a hot journal created on the active >>> machine. >>> Does it make sense to copy the hot journal to the standby machine, >>> so that the sqlite application on the standby will notice this hot >>> journal and use it to recover any lost transactions >> Not only does it make sense - it is mandatory if you want to preserve >> the integrity of the database file. >> >> While a transaction is underway, the journal (either the *-journal >> file or the *-wal file) is part of the state of the database. If you >> fail to copy it over to another machine and then try to open that >> database on the other machine, the database will be incomplete and >> potentially corrupt. >> >> The journal files have a well-defined and documented format. They >> are independent of the byte-order and word-size of the machine they >> were created on. >> -- >> D. Richard Hipp >> drh at sqlite.org >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users at sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users at sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
