Re: Scalability Design Questions - Mailing list pgsql-general
From | Asko Oja |
---|---|
Subject | Re: Scalability Design Questions |
Date | |
Msg-id | ecd779860709120546j854480jd24ce281bd204897@mail.gmail.com Whole thread Raw |
In response to | Re: Scalability Design Questions (novnov <novnovice@gmail.com>) |
List | pgsql-general |
Hello
We plProxy to split our database into partitions. See Kristo's blog's about that at http://kaiv.wordpress.com/.
For replication we use Londiste in SkyTools package. SkyTools contains several more scripts that are useful when buildin large and complex systems running on large number of servers.
Asko
We plProxy to split our database into partitions. See Kristo's blog's about that at http://kaiv.wordpress.com/.
For replication we use Londiste in SkyTools package. SkyTools contains several more scripts that are useful when buildin large and complex systems running on large number of servers.
Asko
On 9/9/07, novnov <novnovice@gmail.com> wrote:
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.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
pgsql-general by date: