-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wade Williams wrote:
> 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."
Others have pointed out the simplicity of doing that. It is r
I would think that it would be even easier than that -- simply write a
separate 20-line python script that starts a transaction (thus assuring
that no one else is writing to the db while the file is being copied),
then forks an rsync to copy the single database file to another file on
the local
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 fo
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
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
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).
6 matches
Mail list logo