It would be a relatively minor job to make Sqlite replicate itself. The partitioning in its design seperates the i/o level.
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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
