I don't think it can be done, and if it could be done, it would not be wise.
The journal is owned and specific to a connection. a hot Journal for connection A on DB 1 cannot ever be used to roll back or affect in any way connection B on DB 2.
However, when you say the "standby is syncing", I assume from your description it copies the file all the time? having an exact copy of the DB file and accompanying journal might work on a technical level, but how can you be sure you have the exact same moment in time files? The answer is easy: you can't. Especially not when one of the machines went down or hung up.
The best way to achieve your scenario (in my opinion, other people might come up with better best ways) is to either have a second connection to the DB which is updating new records to the second DB (which means the second DB will handle its own hot journals and back ups and the like.) with maybe a once-a-day copy of the full DB after possibly a vacuum or other maintenance routines. This all depends on your workload and implementation specifics.
Personally I would have System output any and all SQL that it writes to DB 1 to a file or pipe to the sync service/program which will then apply all the exact same SQL to the second DB, that way they are always in sync and they can't both fail. (Ok they /can/ technically, but the odds of that is negligible). This option also prevents re-copying insane amounts of data which are in both DBs already, all the time.
Another option is the backup API but if you don't have a relatively good space of time to make copies of the DB (i.e where there are no updates) then it will not work well.
On 2/12/2015 11:09 PM, Mayank Kumar (mayankum) 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 or the hot journal can only be used on the same db on which it was created. Remember , both the db on active and standby are same(maintained in sync and have same names), so can a hot journal from one db on active machine be used on standby machine to recover lost transactions. We are assuming that somehow the sqlite application on active is not able to use the journal file to recover from it, so as a fallback would copying it to standby make sense at all so that it can be used by the backup db ? Hope by question doesn't sound too absurd:) -Mayank _______________________________________________ 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
