Re: Connection pooler / LDAP auth / Load Balancing on read-only queries
От | Achilleas Mantzios - cloud |
---|---|
Тема | Re: Connection pooler / LDAP auth / Load Balancing on read-only queries |
Дата | |
Msg-id | 1e2678b7-8ab5-c2d4-89e1-bcfe7ea8ddcb@cloud.gatewaynet.com обсуждение исходный текст |
Ответ на | Re: Connection pooler / LDAP auth / Load Balancing on read-only queries (Scott Ribe <scott_ribe@elevated-dev.com>) |
Список | pgsql-admin |
On 7/4/24 15:47, Scott Ribe wrote: >> Hello >> >> pgpool does a great job at that. pgpool does load balancing to the first statement that is considered a write statement,for that point on, the rest of the transaction is routed to the primary. >> >> But the question here is how to achieve all of the aforementioned features, of all those great tools combined, or ideallycombined in one. > AFAIK, pgpool still doesn't do what I'd consider true pooling, that is MxN multiplexing of connections. (Every client connectionhas a connection from pgpool -> server, but the server connections become available for resuse when clients disconnect.) Yes, unfortunately, pgbouncer shines in this department. > > And to me, the mechanism for routing queries in a transaction is highly suspect, as the initial reads vs later writes couldpotentially be using different snapshots of the data. (There is a safeguard there, involving looking at replicationdelay, but that's not a transactional guarantee, just "here's how out of date the replica can be to get read queries".) It seems pgpool supports snapshot_isolation mode, which is similar to streaming_replication, + it adds visibility consistency, but at the expense of running with default_transaction_isolation = 'repeatable read' : https://www.pgpool.net/docs/latest/en/html/runtime-config-running-mode.html#GUC-SNAPSHOT-ISOLATION-MODE Read latency is an issue with asynchronous physical replication, but then again, the problem is there no matter the HA/pooling solution.
В списке pgsql-admin по дате отправления: