Re: PostgreSQL clustering VS MySQL clustering
От | Tatsuo Ishii |
---|---|
Тема | Re: PostgreSQL clustering VS MySQL clustering |
Дата | |
Msg-id | 20050124.103033.21930526.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: PostgreSQL clustering VS MySQL clustering (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: PgPool changes WAS: PostgreSQL clustering VS MySQL clustering
|
Список | pgsql-performance |
> Tatsuo, > > > I'm not clear what "pgPool only needs to monitor "update switching" by > > > > *connection* not by *table*" means. In your example: > > > (1) 00:00 User A updates "My Profile" > > > (2) 00:01 "My Profile" UPDATE finishes executing. > > > (3) 00:02 User A sees "My Profile" re-displayed > > > (6) 00:04 "My Profile":UserA cascades to the last Slave server > > > > I think (2) and (3) are on different connections, thus pgpool cannot > > judge if SELECT in (3) should go only to the master or not. > > > > To solve the problem you need to make pgpool understand "web sessions" > > not "database connections" and it seems impossible for pgpool to > > understand "sessions". > > Depends on your connection pooling software, I suppose. Most connection > pooling software only returns connections to the pool after a user has been > inactive for some period ... generally more than 3 seconds. So connection > continuity could be trusted. Not sure what you mean by "most connection pooling software", but I'm sure that pgpool behaves differently. -- Tatsuo Ishii
В списке pgsql-performance по дате отправления: