Re: Asychronous database replication

Steve Manes wrote:
> Greg Stark wrote:
>
>> My first reaction to this description was to consider some sort of
>> model where
>> the master database publishes text dumps of the master database which are
>> regularly downloaded and loaded on the slaves. The slaves treat those
>> tables
>> as purely read-only reference tables.
>> If you need data to propagate from the clients back to the server then
>> things
>> get more complicated. Even then you could side step a lot of headaches
>> if you
>> can structure the application in specific ways, such as guaranteeing
>> that the
>> clients can only insert, never update records.
>
>
> It's the latter, I'm afraid. The master actually won't be modifying or
> inserting any data itself, just publishing it for the client databases
> in its domain. Almost all data inserts/updates/deletes will occur on
> the leaf nodes, i.e. at the remote health clinics and MMUs (mobile
> medical units). What we need to ensure is that if Patient X visits Site
> A on Monday that his records are there for a followup visit at Site B on
> Tuesday.
>
> Even this has salient problems: for instance, Patient X visits Site B
> before Site A has had time to replicate its current data back to the
> master and Site B has pulled those updates.

What about doing updates in a peer-to-peer style? Basically, each node
updates any others it comes in contact with (both with its local changes
and anything it's received from the master) and everyone pushes changes
back to the master when they can. Sort of the way airplanes crossing
the ocean pass radio messages for each other. I'm assuming two things:

1) Communication b/w local nodes is easier / occurs more frequently than
communicating with the master. It's easier for an MMU to make a local
call or visit a clinic than dial the sat phone.

2) Patients travel locally. Patient X might visit Sites A and B a day
apart, but he's unlikely to visit Site C which is a few countries away
any time soon. Basically, I don't think you need to update all nodes
with every record immediately.

For some early-morning reason, this made me think of distributed version
control, but I'm not entirely sure how one would use it in this case.
See svk.elixus.org.

--
Peter Fein pfein(at)pobox(dot)com 773-575-0694

Basically, if you're not a utopianist, you're a schmuck. -J. Feldman