SQLite is file-based (no server behind DB), you must provide your own 
synchronization (copying file, executing SQL on both databases, etc).

I don't know if thereĀ“s an application/library that does it for you

-----Original Message-----
[mailto:[EMAIL PROTECTED] On Behalf Of Wade Williams
Sent: quinta-feira, 11 de dezembro de 2008 14:32
To: sqlite-users@sqlite.org
Subject: [sqlite] Sqlite replication

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.


sqlite-users mailing list

sqlite-users mailing list

Reply via email to