although I'm not an sqlite expert (but using it since a few month) I'm wondering why you actually need that sqlite-internal recovery system: I understand that you have two servers running either parallel or one of them will switched on in case of a failure of the primary server, right ? I also have some customers that install my application in that way and they simply install the main database (i.e. the sqlite database file) on a iSCSI drive that will be switched automatically onto the fallback server. The only issue that I can imagine is what happends if the primary server fails during a transaction: In that case most likely a journal file will be seen by the fallback server (after he starts up) but sqlite will recover from that easily and just remove that journal (you can easyly simulate this during debugging and just stop your program during a critical transaction). If the fallback server should run in parallel you can't of course having both servers open the sqlite DB, in the above cernario the iSCSI drive is simply not visible to the fallback server and thus the application running there just waits until the sqlite dbfile becomes accessible. Beside this you may of course do some standard backups of the db-file as well...
Although this approach might not fit into your project, I would apprechiate any comment or concerns from the experts about such a fallback solution. kind regards Marcus Wade Williams wrote: > I'm looking for an honest assessment from someone that may have made > this decision in the past. > > I'm considering using an embedded database for an upcoming > application. Operation rate is high 20,000-60,000 per day. (Those > will mostly be selects, but some smaller percentage will be inserts). > > Our choices appear to be SQLite or Berkley DB. An RDBMS isn't really > an option due to the administrative cost. > > My first inclination was to use SQLite. From what I've seen of the > performance numbers, it should be able to support that rate without > much trouble. > > However, a key feature is disaster recovery. If the primary machine > goes down we've got to quickly switch to another machine (quickly > meaning within minutes if not seconds). > > In my research it appears SQLite may not be a good option, since the > only replication appears to be "lock the database and copy the file to > the new machine." Berkeley DB seems to have the advantage of having > replication built-in. However, I have no idea how useful the > replication is and of course the API is much more inscrutable. I've > also certainly heard all the Berkley DB corruption horror stories. > > I'm OK with stepping off the deep end into Berkeley DB, but I'd prefer > SQLite. However, I'm certainly not looking to shoot myself in the foot. > > I'd appreciate input from anyone on this subject, especially tales > from replication projects. > > Thanks, > > Wade > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Marcus Grimm, MedCom GmbH Darmstadt, Rundeturmstr. 12, 64283 Darmstadt Tel: +49(0)6151-95147-10 Fax: +49(0)6151-95147-20 -------------------------------------------------- MedCom slogans of the month: "Vacation ? -- Every day at MedCom is a paid vacation!" "Friday I have monday in my mind." "MedCom -- Every week a vacation, every day an event, every hour a cliffhanger, every minute a climax." "Damned, it's weekend again!" _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
