Re: Disconnected editing - versioning of databases

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, William Temperley <willtemperley(at)gmail(dot)com>
Subject: Re: Disconnected editing - versioning of databases
Date: 2009-04-15 08:34:37
Message-ID: 200904151034.41615.dfontaine@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Le Wednesday 15 April 2009, Greg Smith a écrit :
> On Tue, 14 Apr 2009, William Temperley wrote:
> > I could potentially run a database in each of these countries and
> > provide 100% uptime, obviously raising the issue of version conflicts
> > that would require hand-merging.

Can you partition data on origin?
If that's possible, then do it and use a schema per origin to simplify the
administration thereafter, and "just" replicate some tables from orginin to UK
and central data from UK to editing countries.

> It sounds like you want an asynchronous master-slave database architecture
> where the slaves can also send changes back to the master, but didn't know
> that's what you should be looking for. A quick glance at
> http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection
>_Pooling suggests Bucardo and Londiste might be useful tools for you to
> investigate; I don't think Slony or Mammoth can handle slaves generating
> their own transactions and feeding them to the master, but given how
> complicated Slony is maybe I just don't know how to do it there.
>
> The Londiste tutorial at
> http://pgsql.tapoueh.org/site/html/londiste/londiste.html even starts out
> with a business situation that sounds similar to yours.

The updated Londiste Tutorial is now to be found on the PostgreSQL wiki, and
I've updated the Replication/Clustering page to add links to it:
http://wiki.postgresql.org/wiki/Skytools
http://wiki.postgresql.org/wiki/Londiste_Tutorial

> I would suggest that if you're new to the area of replication, do not
> assume that just because these tools look complicated that you'd be better
> off rolling your own. The reason they're complicated is because they're
> filled with solutions to hard problems most people never even think they
> need to solve, until they get bit by one.

If you're afraid about their complexity, try londiste and enjoy :)
--
dim

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Shug Boabby 2009-04-15 10:09:49 (P)SQL for a sum with constraints
Previous Message Fujii Masao 2009-04-15 07:42:43 Re: PITR - warm standby switchover question