Hostgroups and monitoring
Define writers, readers, backups, weights, limits, connect and ping checks, read-only detection, lag thresholds, and shun behavior for the topology.
DBRE-led proxy and pooling engineering
ProxySQL engineering for controlled MySQL traffic
In short: ProxySQL is a programmable proxy for MySQL and MariaDB traffic. JusDB DBRE services design hostgroups, health checks, ordered query rules, connection pools, multiplexing, security, statistics, configuration persistence, and proxy availability while testing transaction state, replica lag, read-after-write behavior, driver compatibility, and rollback before routing production queries.
ProxySQL can centralize useful traffic controls, but a proxy rule can also change database correctness or amplify an incident. JusDB combines traditional MySQL DBA knowledge with DBRE testing, observability, failure analysis, and change control. Performance, savings, routing, and failover outcomes are measured in the actual environment.
Fit and boundaries
What ProxySQL can—and cannot—own
Query rules
Use ordered digest or query matches for explicit routing, logging, caching, rewriting, mirroring, or blocking with test cases and ownership.
Pooling and multiplexing
Measure frontend and backend pools, session-state constraints, prepared statements, transactions, temporary tables, wait time, and connection churn.
Runtime and persistence
Control the memory, runtime, and disk configuration layers; define review, LOAD, SAVE, drift detection, backup, and rollback procedures.
Security
Review users, passwords, TLS, administrative access, logging, firewall rules, secret distribution, least privilege, and audit requirements.
Availability boundary
Separate configuration synchronization from endpoint availability, backend failover, consistency, capacity during failure, and application retry behavior.
A controlled implementation path
- 01
Observe traffic
Inventory drivers, transactions, session features, query digests, topology, replication behavior, connections, latency, errors, and objectives.
- 02
Test rules and failure
Replay representative traffic, validate routing and consistency, measure multiplexing, inject backend and proxy failures, and rehearse rollback.
- 03
Stage and operate
Roll out reviewed configuration gradually, monitor query and pool signals, preserve a bypass path, and hand off runbooks and ownership.
Production safeguards
The proxy is part of the database failure path. Configuration is reviewed together with drivers, application state, database topology, health signals, rollback, and operator access.
- Rule ordering, match scope, apply behavior, and negative test cases
- Transaction, session-state, temporary-table, and prepared-statement checks
- Replica-lag and read-after-write correctness controls
- Runtime-to-disk persistence and configuration-drift monitoring
- Independent proxy endpoint, capacity, and failure testing
- Bypass, rollback, access, audit, and incident runbooks
ProxySQL questions
What is ProxySQL used for?
ProxySQL sits between applications and MySQL or MariaDB backends. It maintains hostgroups and connection pools, monitors backend state, records query digests, and applies ordered query rules for routing, caching, rewriting, mirroring, logging, or blocking. The safe feature set depends on transactions, session state, consistency requirements, drivers, and topology.
Does ProxySQL always reduce backend connections?
No. Multiplexing lets frontend sessions reuse backend connections only while those sessions are safe to share. Active transactions, locks, temporary tables, user variables, some prepared-statement behavior, and other session state can disable multiplexing. JusDB measures actual multiplexing status and pool use instead of applying a fixed client-to-backend reduction claim.
Can ProxySQL safely split reads and writes?
Read/write splitting requires application and consistency analysis. Query rules, transaction state, temporary tables, locking reads, stored routines, session variables, replica lag, and read-after-write expectations can invalidate a broad SELECT-to-replica rule. We classify query digests, protect transactions, define lag behavior, and test correctness before enabling production routing.
Does ProxySQL Cluster make the proxy highly available?
ProxySQL Cluster synchronizes selected configuration across ProxySQL peers; it does not by itself provide an application endpoint, traffic failover, or identical runtime state. Multiple proxy instances still need independent health checks, load balancing or endpoint failover, capacity, configuration safeguards, and failure testing. Database failover behavior must also be integrated with the actual MySQL topology.
How is ProxySQL monitored?
The administration interface exposes runtime and statistics tables for backends, connection pools, query digests, process lists, errors, and monitor checks. JusDB defines signals for reachability, read-only state, replication lag, shunning, pool saturation, client wait, query latency, errors, configuration drift, and proxy health, then maps alerts to tested operator actions.
Technical review and primary sources
ProxySQL guidance checked against official documentation
Review scope: MySQL and MariaDB hostgroups, monitoring, query rules, connection pooling and multiplexing, session-state constraints, configuration persistence, security, observability, and proxy availability. Recommendations and outcomes remain specific to the exact tool and database versions, drivers, workload, topology, infrastructure, and engagement scope.
Technically reviewed by the JusDB Database Reliability Engineering team. Last reviewed: . See the team and roles.
- ProxySQL documentation
Official documentation index for configuration, administration, query handling, security, and monitoring.
- ProxySQL architecture
Primary overview of hostgroups, backend pools, query processing, digests, and configuration layers.
- ProxySQL multiplexing
Official constraints for transactions, session state, prepared statements, temporary tables, and connection reuse.