Re: Is there a peer-to-peer server solution with PG?
От
Tzahi Fadida
Тема
Re: Is there a peer-to-peer server solution with PG?
Дата
Msg-id
009801c50b31$428f7c90$0b00a8c0@llord
Ответ на
Re: Is there a peer-to-peer server solution with PG? (Mike Nolan)
Список
Дерево обсуждения
Re: Is there a peer-to-peer server solution with PG? Christopher Browne <cbbrowne@acm.org>
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? Tzahi Fadida <tzahi_ml@myrealbox.com>
Re: Is there a peer-to-peer server solution with PG? Jan Wieck <JanWieck@Yahoo.com>
Re: Is there a peer-to-peer server solution with PG? Robert Treat <xzilla@users.sourceforge.net>
Re: Is there a peer-to-peer server solution with PG? Pailloncy Jean-Gerard <jg@rilk.com>
Re: Is there a peer-to-peer server solution with PG? Marco Colombo <pgsql@esiway.net>
I am just a newbie but logically: Maybe the answer to that is much simpler. Ask your network officer to tell you whats the bandwidth you have on your current office and remote office. whats the avg: a. website bandwidth. b. current postgress office bandwidth. I never used replication but it seems to me you'll need a+2*b bandwidth at your current office and 2*b at your remote office for the period of transition. If your db size is C then you'll need (C/b)/3600 hrs in transition time. do the math and if it fits great. If not, well... Regards, tzahi. > -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Mike Nolan > Sent: Friday, February 04, 2005 12:57 PM > To: Christopher Browne > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Is there a peer-to-peer server > solution with PG? > > > > 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. > > 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 > >
В списке pgsql-general по дате отправления