Re: PostgreSQL clustering VS MySQL clustering

Tatsuo Ishii <t-ishii@sra.co.jp>

From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: josh@agliodbs.com
Cc: pgsql-performance@postgresql.org, darcy@wavefire.com, jd@www.commandprompt.com, sfrost@snowman.net, herve@elma.fr
Date: 2005-01-21T08:07:31Z
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.

Can I ask a question?

Suppose table A gets updated on the master at time 00:00. Until 00:03
pgpool needs to send all queries regarding A to the master only. My
question is, how can pgpool know a query is related to A?
--
Tatsuo Ishii

> 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
>