Re: PostgreSQL clustering VS MySQL clustering

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, darcy(at)wavefire(dot)com, jd(at)www(dot)commandprompt(dot)com, sfrost(at)snowman(dot)net, herve(at)elma(dot)fr
Subject: Re: PostgreSQL clustering VS MySQL clustering
Date: 2005-01-21 03:49:24
Message-ID: 200501201949.24292.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tatsuo,

> Yes. However it would be pretty easy to modify pgpool so that it could
> cope with Slony-I. I.e.
>
> 1) pgpool does the load balance and sends query to Slony-I's slave and
> master if the query is SELECT.
>
> 2) pgpool sends query only to the master if the query is other than
> SELECT.
>
> Remaining problem is that Slony-I is not a sync replication
> solution. Thus you need to prepare that the load balanced query
> results might differ among servers.

Yes, please, some of us are already doing the above ad-hoc.

The simple workaround to replication lag is to calculate the longest likely
lag (<3 seconds if Slony is tuned right) and have the dispatcher (pgpool)
send all requests from that connection to the master for that period. Then
it switches back to "pool" mode where the slaves may be used.

Of course, all of the above is only useful if you're doing a web app where 96%
of query activity is selects. For additional scalability, put all of your
session maintenance in memcached, so that you're not doing database writes
every time a page loads.

--
Josh Berkus
Aglio Database Solutions
San Francisco

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-01-21 06:02:59 Re: column without pg_stats entry?!
Previous Message Joshua D. Drake 2005-01-21 03:16:15 Re: PostgreSQL clustering VS MySQL clustering