Search Postgresql Archives

Re: Asychronous database replication

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx                 773-575-0694

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
       message can get through to the mailing list cleanly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux