Re: Is there a peer-to-peer server solution with PG? - Mailing list pgsql-general

From Christopher Browne
Subject Re: Is there a peer-to-peer server solution with PG?
Date
Msg-id m3acqijyxs.fsf@knuth.knuth.cbbrowne.com
Whole thread Raw
In response to Re: Is there a peer-to-peer server solution with PG?  (Mike Nolan <nolan@gw.tssi.com>)
List pgsql-general
Quoth JanWieck@Yahoo.com (Jan Wieck):
> On 2/4/2005 5:56 AM, Mike Nolan wrote:
>
>>> If you have so much update load that one server cannot accomodate that
>>> load, then you should wonder why you'd expect that causing every one
>>> of these updates to be applied to (say) 3 servers would "diminish"
>>> this burden.

>> The update/query load isn't the real issue here, it's that these two
>> servers will be 800 miles apart and there are some advantages in having
>> each office connect to its local database rather than having one of
>> them connect to the remote master.
>
> You do realize that any multimaster replication system, that is
> designed to avoind complex business process structure based conflict
> resolution mechanisms, necessarily has to be based on 2 phase commit
> or similar? So your global write transaction throughput will be
> limited by the latency of your WAN, no matter what bandwidth you
> have. And as per RFC 1925: No matter how hard you push and no matter
> what the priority, you can't increase the speed of light.
>
> I think what you are really looking for is an application internal
> abstraction layer based multmaster replication approach.

Note also that there can be some "embarassingly parallel" systems that
can scale _perfectly well_ given some reasonable 'global sequencing
system.'  ("Global sequences" seemed to be the only 'surprise' that
popped up at the conference, which surprised me because it was one of
the few things I was entirely certain needed discussion ;-).)

Consider a general ledger transaction system for a retail operation
with 200 stores.

Each accounting transaction actually is pretty independent of the
others; with suitable application design, it's perfectly reasonable to
generate transactions locally at each site and [somehow; there lies
the grand detail] roll those together into the central G/L at the end.

Purely accounting transactions don't usually have any need to conflict
with anything at all.

Of course, as soon as you have _shared_ objects in your business, such
as account balances [that people can lay claim to], inventory [that we
can promise to customers], and 8 people that want to change prices,
then comes the trouble of conflict resolution.

You've got to think about which of these sorts of conflicts do and do
not exist before heading down any of the "multimaster" roads otherwise
trouble awaits...

It's quite likely for reality to need to be a mix.  For account
balances, you more than likely need to go to only ONE source;
"conflict resolution" would be liable to 'break the bank.'  For
inventory, it's probably not unreasonable for different sites to fight
over it :-).
--
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/slony.html
What's another word for synonym?

pgsql-general by date:

Previous
From: Jonel Rienton
Date:
Subject: Re: Help with sorting (ie. ORDER BY expression)
Next
From: Ron Peterson
Date:
Subject: security