[MXS-3265] Better Connection Pooling and multiplexing - Phase 1 Created: 2020-10-28  Updated: 2022-04-07  Resolved: 2022-04-07

Status: Closed
Project: MariaDB MaxScale
Component/s: mariadbbackend
Affects Version/s: None
Fix Version/s: 6.3.0

Type: Task Priority: Major
Reporter: Manjot Singh (Inactive) Assignee: Esa Korhonen
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
PartOf
includes MXS-3361 Rewrite ignorable query processing Closed
Relates
relates to MXS-3902 Limit total number of connections to ... Closed
Sprint: MXS-SPRINT-123, MXS-SPRINT-124, MXS-SPRINT-125

 Description   

Larger customers may have thousands or tens of thousands of connections to the database. To mitigate risk to the database from many active connections and still allow larger in-memory buffers, we should have maxscale pool connections to the backend databases.

Connection pooling could be implemented by multiplexing N client connections over M connections to a backend MariaDB server. After a client connection request completes successful authentication with a backend MariaDB server, the proxy severs the link between the backend connection and client connection and parks it in a connection pool for the backend server.

The server connection pool size should be configurable or dynamic, and typically a small number. Forks of MaxScale have leveraged the persistent connections feature to implement the server connection pool. When receiving a query on a client connection, MaxScale can pick a backend connection in the pool, link it with the client connection, and forward the query to the backend MariaDB server. MaxScale understands the transaction context of a client session and therefore it knows to keep the linked backend connection until transaction commits. The link must be kept and used for forwarding the query result back to the client.

One challenge in this connection pooling implementation is knowing when to unlink and return the backend connection to the pool. A query response consists of one or more MariaDB packets. Because MaxScale keeps one-to-one link between a client connection and a backend connection, it just forwards response packets as they come. In connection pooling mode, unlinking a backend connection prematurely would cause the client to wait indefinitely for the complete set of MariaDB packets. For correct query response forwarding, consider implementing packets by following the MariaDB client server protocol for COM_QUERY_RESPONSE. That way, MaxScale will not unlink a backend connection until it has seen the complete MariaDB packets of a query response. Aside from forwarding responses, it would allow us to measure query response size for monitoring.



 Comments   
Comment by Johan Wikman [ 2020-10-28 ]

When RWS is used MaxScale does not just forward response packets as they come, but is fully aware of response and transaction boundaries.

Comment by Manjot Singh (Inactive) [ 2020-10-28 ]

I copied the text from fixes based on MaxScale 1.3. Apologies if out of date.

Comment by Johan Wikman [ 2020-12-03 ]

What kind of limitations would be reasonable?

For instance, when taking a connection out from the pool, MaxScale would have to send a COM_CHANGE_USER to reset the connection for the current user. Unless we explicitly record and each time set the session state (user variables etc.), every transaction starts from a blank slate. Doing that adds overhead but not doing that means that applications need to be aware of this pooling.

Comment by markus makela [ 2020-12-03 ]

One benefit of connection sharing is the ability to share prepared statements. Currently, each connection will have their own set of compiled prepared statements in the server. By sharing the connection and the same prepared statement ID, we reduce the overall overhead of prepared statements compared to normal text protocol queries.

Generated at Thu Feb 08 04:20:09 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.