Re: Is there a peer-to-peer server solution with PG?
От | Jan Wieck |
---|---|
Тема | Re: Is there a peer-to-peer server solution with PG? |
Дата | |
Msg-id | 420526A8.6050004@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Is there a peer-to-peer server solution with PG? (Mike Nolan <nolan@gw.tssi.com>) |
Ответы |
Re: Is there a peer-to-peer server solution with PG?
Re: Is there a peer-to-peer server solution with PG? |
Список | pgsql-general |
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. Jan > > The Slony-1 approach will work, assuming I've got suffient network > bandwidth to support it plus the traffic from the remote office plus > exixting outside traffic from our public website. > > That's one of those things you just don't know will work until you > have it built, so I'm looking for other options now while I have time > to consider them. Once I get on-site in two weeks it'll a lot more hectic. > -- > Mike Nolan > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-general по дате отправления: