ProxySQL meltdown → reroute live

Situation initiale

Client e-commerce, Black Friday, 23h. Le ProxySQL principal commence à refuser des connexions. Les règles de routage statiques ne supportent pas le pic de trafic.

Symptômes :

• max_connections atteint sur le writer
• Requêtes SELECT routées vers le writer au lieu des readers
• Temps de réponse > 5 secondes

L'intervention

L'agent Alex de PmaControl a détecté l'anomalie et généré un diagnostic en 8 secondes :

[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

L'opérateur a validé la suggestion. La règle a été appliquée en 30 secondes via l'interface PmaControl, sans redémarrage de ProxySQL.

Résultat

• Temps de réponse : 5.2s → 180ms
• Connexions writer : 98% → 34%
• Zero downtime

Ce qu'on retient

Les règles de routage ProxySQL doivent être dynamiques. Un pic de trafic ne prévient pas, et des règles statiques deviennent un single point of failure.

PmaControl + l'agent Alex permettent de diagnostiquer et corriger en temps réel, sans attendre l'escalade.