ProxySQL meltdown → live reroute

Initial situation

E-commerce client, Black Friday, 11 PM. The primary ProxySQL starts refusing connections. The static routing rules can't handle the traffic spike.

Symptoms:

• max_connections reached on the writer
• SELECT queries routed to the writer instead of readers
• Response time > 5 seconds

The intervention

PmaControl's Alex agent detected the anomaly and generated a diagnostic in 8 seconds:

[ALEX] ProxySQL hostgroup 10 (writer): 98% connection usage
[ALEX] Recommendation: split reads to hostgroup 20 (3 readers available)
[ALEX] Suggested rule: ^SELECT.*FOR UPDATE → HG10, ^SELECT → HG20

The operator validated the suggestion. The rule was applied in 30 seconds through the PmaControl interface, without restarting ProxySQL.

Result

• Response time: 5.2s → 180ms
• Writer connections: 98% → 34%
• Zero downtime

Takeaway

ProxySQL routing rules must be dynamic. A traffic spike doesn't give notice, and static rules become a single point of failure.

PmaControl + the Alex agent enable real-time diagnosis and correction, without waiting for escalation.