Re: PostgreSQL clustering VS MySQL clustering
От | Josh Berkus |
---|---|
Тема | Re: PostgreSQL clustering VS MySQL clustering |
Дата | |
Msg-id | 200501201949.24292.josh@agliodbs.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL clustering VS MySQL clustering (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: PostgreSQL clustering VS MySQL clustering
Re: PostgreSQL clustering VS MySQL clustering |
Список | 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
В списке pgsql-performance по дате отправления: