Re: Scalability Design Questions - Mailing list pgsql-general
From | novnov |
---|---|
Subject | Re: Scalability Design Questions |
Date | |
Msg-id | 12580273.post@talk.nabble.com Whole thread Raw |
In response to | Re: Scalability Design Questions ("Trevor Talbot" <quension@gmail.com>) |
Responses |
Re: Scalability Design Questions
Re: Scalability Design Questions |
List | pgsql-general |
OK, this has been very informative and I'd like to thank the three of you. Asynchronous replication to readonly slaves is something I will look into. I've never touched posgtres replication; and Scott mentioned that he was not familiar with PGCluster, so there must be some other replication system he's referencing, maybe Slony-I? Trevor Talbot-2 wrote: > > On 9/8/07, novnov <novnovice@gmail.com> wrote: > >> But basically, it seems that the answer to one of my questions is that >> there >> is currently no way with postgres to spread a single database over >> multiple >> servers, ala a loadbalanced apache cluster, where requests are forwarded >> to >> different boxes. > > Actually, that's essentially the same thing. Whether it's the front > end or middleware, something splits the requests apart before they're > processed. > > The asynchronous replication to readonly slaves Scott mentioned > earlier would be roughly equivalent to having several identical apache > boxes that have their own local copies of files that you periodically > rsync/ftp/whatever to them from a single place. Partitioning data > would be roughly equivalent to having one apache box for images, one > for ads, etc. > > From what I've seen people mention of RAC, it provides strong > guarantees about server consistency -- all of them have the changes or > none of them do -- but you need to go to great effort to achieve the > same thing on a set of apache boxes too. I mean, you don't have each > box accepting file uploads via the web and assume the others will > magically see the same file at exactly the same time, right? Unless, > of course, you're using them purely for CPU reasons and have a single > shared storage pool. > > Whatever is splitting the requests may do it on a "session" level too, > which makes it easier for the backend clusters. E.g. if a given user > always hits a given apache box, that file upload situation isn't a > problem as long as you can rsync faster than the sessions time out. > Often you need to load balance this way anyway if you have a web app > using an internal notion of sessions -- session data isn't replicated > to other apache boxes. (If you need it to be replicated, you're > already in special design territory, not just easy load balancing.) > > It all varies depending on the details of what you're doing. Even > that seemingly straightforward question isn't specific enough :( > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > > -- View this message in context: http://www.nabble.com/Scalability-Design-Questions-tf4406693.html#a12580273 Sent from the PostgreSQL - general mailing list archive at Nabble.com.
pgsql-general by date: