On 9/17/09, Simon Slavin <slav...@hearsay.demon.co.uk> wrote:
>
> On 17 Sep 2009, at 4:54pm, Kelly Jones wrote:
>
>> I want to do multi-master sqlite3 replication by editing sqlite3.c to
>> log UPDATE/INSERT queries with timestamps, and then using another
>> program to run those queries on the other masters.
>
> Doesn't work.  Consider:  You have a database with three records:
>
> ID    object  colour
> --    ------  ------
> 1     car     red
> 2     coat    black
> 3     hat     green
>
> In database copy number 1 someone does
>
> UPDATE objects SET colour='green' WHERE id=1
>
> In database copy number 2 someone does
>
> UPDATE objects SET colour='purple' WHERE colour='green'
>
> Then you try to merge the databases by running everyone else's UPDATE
> commands against each copy.  Under your system copy 1 will still end
> up different copy 2.
>
> A better way is to hold just one 'master' copy of the database
> centrally, use everyone's queries to update that, then distribute
> copies of the master.  But even that won't have the results you might
> expect at first glance.  First you need to work out what you'd want to
> happen under those circumstances.  Then work out how to implement it.

Hmmm, good point. I always thought this was how MySQL did replication,
but maybe that's why MySQL's replication is unidirectional. Two comments:

 % 99+% of the time, there won't be two updates "at the same time". In
 other words, copy 1's change will almost always propagate to copy 2
 before copy 2 does another update.

 % In my app, almost all the UPDATEs are of the form "WHERE rowid IN
 (...)". I don't do global updates like "WHERE foo='bar'".

I read your other post as well, and still think this is worth
pursuing. Is there a place I can read up on proposed solutions and why
they fail?

I've considered other solutions (eg, triggers and iwatch/rsync), but
the query-logging one seems to have certain advantages.

One thought: backup the db before each INSERT/UPDATE (too ugly?) +
keep the backups for 5m (or whatever). If you get an update query from
a remote master w/ a timestamp older than your own most-recent update
query, restore the backup and re-run the queries in the correct order.

I'm trying to implement a redundant system of 4 VPSs, and want to
avoid having a single master.

-- 
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to