Part 5 – MaxScale Multiplexing
This multi-part series breaks down each section into easy logical steps.
Part 1 – Complete Guide for High-Concurrency Workloads
Part 2 – Understanding MaxScale Thread Architecture
Part 3 – Backend Sizing and Connection Pooling
Part 4 – Tuning MaxScale for Real Workloads
Part 5 – MaxScale Multiplexing
Multiplexing allows multiple frontend client sessions to share fewer backend connections.
| Parameter | What It Does / Why It’s Important | Link to MariaDB Documentation |
|---|---|---|
max_routing_connections | Maximum number of routing (backend) connections that MaxScale can maintain to this server. This limits how many simultaneous backend connections are open, helping control resource usage. When connection sharing is enabled, if this limit is reached, new client sessions may wait for a free connection (or timeout). | MaxScale Configuration – max_routing_connections |
persistpoolmax | The maximum number of idle backend connections to keep in the persistent connection pool per thread. These are connections that have been detached from sessions and can be reused later, reducing the cost of reconnecting. | MaxScale Configuration – persistpoolmax |
persistmaxtime | How long (duration) a detached (pooled) backend connection is kept before it is closed. Helps balance keeping ready-to-use connections vs freeing unused ones. | MaxScale Configuration – persistmaxtime |
idle_session_pool_time | The amount of time a session must be idle before its backend connection(s) may be pooled (i.e., detached). | MaxScale Configuration – idle_session_pool_time |
multiplex_timeout | When connection sharing is in use: the timeout for a client session waiting to acquire a backend connection from the pool. If MaxScale is at its max backend connections (max_routing_connections), clients may have to wait, this parameter sets how long they’ll wait before erroring. | MaxScale Configuration – multiplex_timeout |
max_slave_connections | For read/write-split (replica) setups: how many connections MaxScale can open to slave (read) servers. Controls concurrency of read traffic going to replicas. | MaxScale Configuration – max_slave_connections |
lazy_connect | If set to true, MaxScale delays establishing backend connections until the first client query actually needs a backend. This avoids opening idle connections upfront, which is especially useful when multiplexing and when you have many servers, it prevents wasted backend resources. | Read-Write Split Router – lazy_connect |
Example Calculation:
- 8 threads, 3 servers, max_routing_connections=50 → total backend connections = 8×3×50 = 1200
Recommended Starting Configuration:
Bash
[maxscale]
threads=8
debug=allow-duplicate-servers
[server1]
type=server
address=10.0.0.1
port=3306
protocol=MariaDBBackend
max_routing_connections=50
persistpoolmax=50
persistmaxtime=300s
[server2]
type=server
address=10.0.0.2
port=3306
protocol=MariaDBBackend
max_routing_connections=50
persistpoolmax=50
persistmaxtime=300s
[server3]
type=server
address=10.0.0.3
port=3306
protocol=MariaDBBackend
max_routing_connections=50
persistpoolmax=50
persistmaxtime=300s
[MultiplexService]
type=service
router=readwritesplit
servers=server1,server2,server3
user=maxuser
password=maxpass
idle_session_pool_time=1s
multiplex_timeout=60s
max_sescmd_history=50
max_slave_connections=1
lazy_connect=true
[MultiplexListener]
type=listener
service=MultiplexService
protocol=MariaDBClient
port=4006
address=0.0.0.0Use Cases:
- Many idle connections
- Stateless queries
- High-concurrency events
Avoid:
- Long transactions
- Session variables or temp tables
- Multi-statement stateful queries
Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Page 8
Leave a Reply
You must be logged in to post a comment.