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: