From: | novnov <novnovice(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Scalability Design Questions |
Date: | 2007-09-09 16:11:17 |
Message-ID: | 12580273.post@talk.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Schröder | 2007-09-09 16:41:46 | Re: Query with "like" is really slow |
Previous Message | Tom Lane | 2007-09-09 14:54:27 | Re: Checking is TSearch2 query is valid |