Vous ne changez pas de moteur de base de données pour le plaisir. Vous changez parce que le pager s’ennuie et réclame de l’attention, parce que les graphes de latence ressemblent à une chaîne de montagnes, ou parce que les sauvegardes prennent tellement de temps que vous ne pouvez pas l’expliquer sans perdre la face.
MySQL et Percona Server sont suffisamment proches pour que l’on appelle Percona un « remplaçant drop-in ». Cette expression peut être vraie — dangereusement vraie. En production, « drop-in » signifie vraiment « même protocole et mêmes formats sur disque, mais vous devez tout de même le prouver sous votre charge, sur votre matériel, avec vos habitudes opérationnelles ».
Ce que vous choisissez réellement (pas une marque)
« MySQL vs Percona Server » sonne comme un débat philosophique. Ce ne l’est pas. C’est une décision opérationnelle concernant :
- Observabilité : Pouvez-vous voir ce qui se passe avant que cela devienne un incident à 3h du matin ?
- Prédictibilité des performances : Disposez-vous de garde-fous contre les requêtes pathologiques, les blocages et les tempêtes de verrous ?
- Mode de support : Qui appelez-vous quand InnoDB commence à « aider » en flushant au pire moment possible ?
- Mécanique de mise à jour : À quelle vitesse pouvez-vous patcher des CVE critiques sans transformer votre déploiement en foire scientifique ?
Percona Server est un fork en aval de MySQL mettant fortement l’accent sur l’instrumentation et les réglages de performance. En pratique, il se comporte souvent comme « MySQL avec les lumières allumées ». Vous pouvez conserver les mêmes clients, le même protocole de réplication, et généralement le même format du répertoire de données pour une même famille de versions majeures.
Mais « généralement » n’est pas une stratégie. Votre travail est de transformer « généralement » en « prouvé ».
Historique et faits importants en production
Un peu de contexte aide à expliquer pourquoi Percona existe et pourquoi des équipes l’adoptent. Voici des faits qui influencent réellement les choix opérationnels :
- MySQL a changé de mains : MySQL AB a été acquis par Sun, puis Sun par Oracle. Cela a façonné la licence, le rythme des sorties et les fonctionnalités mises en avant.
- L’origine de Percona est le support : Percona a commencé en corrigeant des douleurs de production réelles pour de grands déploiements MySQL. Leur serveur est né de ce besoin « on en a besoin maintenant ».
- InnoDB est devenu le moteur par défaut : Une fois MySQL standardisé autour d’InnoDB, les performances et la fiabilité se sont liées au comportement interne d’un moteur unique — flushs, redo et contention sur mutex.
- Performance Schema a mûri lentement : Les premières versions étaient coûteuses et limitées ; les versions ultérieures sont devenues essentielles. Percona a adopté l’instrumentation plus tôt et de façon plus agressive.
- « Drop-in » concerne protocole et formats disque : La grande promesse est la compatibilité au niveau du protocole client et du format InnoDB sur disque dans une même ligne majeure. C’est pourquoi les migrations peuvent être rapides.
- La réplication a longtemps été un champ de mines : Statement-based vs row-based, GTID, et des cas limites avec des statements non déterministes ont causé de vraies pannes dans l’industrie.
- Les changements de schéma en ligne sont devenus une discipline : Des outils comme pt-online-schema-change ont émergé car « ALTER TABLE » sur un système chargé était autrefois une activité qui pouvait mettre l’entreprise à genoux.
- Le cloud a changé les modes de défaillance : Jitters de latence stockage, voisins bruyants et crédits de rafale ont transformé des systèmes MySQL « stables » en systèmes imprévisibles. L’instrumentation compte plus que jamais.
- MySQL 8 a beaucoup réorganisé : Dictionnaire de données, comportement des undo et valeurs par défaut ont évolué. C’est mieux à bien des égards, mais le chemin de mise à niveau mérite du respect.
Différences qui changent les résultats : instrumentation, comportement, valeurs par défaut
1) Observabilité : on ne peut pas corriger ce qu’on ne voit pas
Avec MySQL, vous pouvez absolument obtenir une excellente observabilité. Il faut juste travailler plus dur, et vous risquez d’installer des plugins, d’activer des fonctionnalités coûteuses ou de vous reposer sur des outils externes pour déduire ce qui se passe.
Le point fort de Percona Server est que beaucoup de réglages et métriques « nécessaires en production » sont intégrés ou plus faciles à activer. Cela change la chronologie d’un incident : moins d’hypothèses, moins d’archéologie de logs, et plus de preuves directes.
Si vous exécutez une charge sensible à la latence, la possibilité de mesurer la contention interne, les stalls d’E/S et les schémas de requêtes sans conjectures n’est pas un luxe. C’est la différence entre « on a réparé » et « on a empêché que cela se reproduise ».
2) Réglages de performance : les outils puissants coupent dans les deux sens
Percona Server expose généralement plus de paramètres (et parfois des valeurs par défaut différentes) autour de :
- Comportement de flush d’InnoDB et mécanismes adaptatifs
- Comportement du pool de threads (selon version/build)
- Instrumentation supplémentaire (statistiques utilisateur, état étendu)
Plus de réglages signifie plus de moyens de gagner et plus de façons de perdre. Le bon choix est de toucher aux réglages seulement après avoir mesuré, et de ne changer qu’une variable à la fois. Le mauvais choix est d’« appliquer le my.cnf du net » et d’espérer le meilleur.
3) Compatibilité : en grande partie oui, mais vérifiez les limites
La plupart des requêtes applicatives ne remarqueront pas la différence. Vos outils opérationnels, eux, peuvent la remarquer. Aussi, le comportement aux marges compte :
- Différences de valeurs par défaut ou dépréciations entre distributions et versions mineures
- Profils de coût d’instrumentation différents
- Plugins et méthodes d’authentification
- Quirks dans la topologie de réplication
Percona peut être « drop-in » au niveau du protocole et vous surprendre quand même au niveau des performances ou de l’opérationnel. C’est comme remplacer un moteur qui se boulonne correctement, puis découvrir que votre transmission devient le maillon faible.
4) Support et cadence des correctifs : ennuyeux, mais cela décide de vos week-ends
Quand un CVE arrive, vous voulez une voie de correctif prévisible. Vous voulez aussi de la clarté sur les lignes de versions et sur ce qui est sûr à mettre à jour. La vraie question n’est pas « quel serveur est meilleur ? » mais « quel modèle de fournisseur et quel processus de release s’alignent avec notre façon d’opérer ? »
Une idée paraphrasée de Werner Vogels (CTO d’Amazon) qui tient toujours : « Tout plante, tout le temps ; concevez et opérez en supposant la défaillance. » C’est la lentille à utiliser ici.
Quand Percona Server est le bon choix
Choisissez Percona Server quand votre douleur est opérationnelle, pas théorique. Plus précisément :
- Vous êtes aveugle pendant les incidents. Vous avez besoin de statuts/métriques plus riches sans bricoler des plugins et patches personnalisés.
- Vous êtes limité par l’I/O et ne comprenez pas pourquoi. Une meilleure visibilité sur les flushs et les stalls internes rapporte rapidement.
- Vous avez un mix de requêtes sérieux (joins complexes, pics d’écriture, jobs en arrière-plan) et vous avez besoin d’une latence stable.
- Vous exploitez de grandes flottes et voulez un tuning cohérent et de meilleurs signaux de diagnostic au niveau flotte.
- Vous devez effectuer des changements en ligne en toute sécurité et voulez l’écosystème qui part du principe des contraintes de production.
Conseil d’opinion : si vous êtes sur un déploiement MySQL 5.7/8.0 chargé avec des stalls « mystérieux » récurrents et que votre équipe a une maturité opérationnelle correcte, Percona Server rembourse souvent son coût rien qu’en diagnostic plus rapide.
Quand rester sur Oracle MySQL
Restez sur Oracle MySQL quand l’objectif principal est de minimiser la variance :
- Vous exécutez MySQL managé où vous ne contrôlez pas la distribution serveur sous-jacente de toute façon.
- Vous exigez des combinaisons certifiées par le fournisseur avec des outils d’entreprise, des exigences de conformité ou des audits qui nomment explicitement Oracle MySQL.
- Votre charge est simple et stable et vous disposez déjà d’une excellente observabilité et d’un chemin de mise à niveau propre.
- Vous manquez de temps opérationnel pour valider correctement un changement de serveur. « Drop-in » demande du travail ; ne faites pas semblant du contraire.
Aussi : si votre équipe a du mal à garder une instance MySQL saine, ajouter des réglages supplémentaires revient à donner une tronçonneuse à un enfant. Ce n’est pas un problème Percona ; c’est un problème de maturité.
Blague #1 : Appeler quelque chose « drop-in » en production, c’est comme appeler un parachute « clip-on ». Techniquement correct, émotionnellement imprudent.
Playbook de diagnostic rapide (chasse aux goulots)
Quand la production est lente, vous ne commencez pas par lire des billets de blog. Vous commencez par classifier le goulot en moins de 10 minutes. Voici l’ordre qui fonctionne quand vous êtes de garde et fatigué.
Première étape : confirmer que c’est la base de données (et pas l’application qui ment)
- Vérifiez le nombre de threads en cours et la saturation des connexions.
- Vérifiez si des requêtes attendent des verrous ou de l’E/S.
- Vérifiez si le retard de réplication provoque des lectures sur une réplique obsolète, entraînant des retries/timeouts.
Deuxième étape : classifier le chemin lent (CPU, I/O, verrous ou « c’est DNS »)
- CPU lié : CPU utilisateur élevé, nombreuses requêtes en cours, faible iowait.
- I/O lié : iowait élevé, longs temps de fsync/flush, accumulation de pages dirty.
- Verrous liés : nombreuses sessions en attente de verrous metadata, verrous de lignes, ou mutex/cond du buffer pool.
- Pression mémoire : activité de swap, buffer pool trop petit, amplification de lecture.
Troisième étape : décider l’atténuation immédiate
- Si c’est des verrous : tuez ou limitez le bloqueur, arrêtez le changement de schéma, ou redirigez le trafic.
- Si c’est de l’I/O : réduisez la pression d’écriture (regroupement, désactiver jobs non critiques), augmentez les réglages de durabilité seulement si vous acceptez le risque, déplacez les requêtes chaudes si possible.
- Si c’est du CPU : identifiez les requêtes les plus consommatrices et appliquez des limites temporaires, ajoutez des index uniquement si vous pouvez le faire en ligne, scalez les lectures.
Puis vous faites le vrai travail : collecter des preuves, reproduire, corriger la cause racine et consigner la leçon pour ne pas la revivre mardi prochain.
Tâches pratiques : commandes, sorties, décisions (12+)
Voici les tâches que vous exécutez réellement quand vous comparez MySQL à Percona Server, validez un swap « drop-in » ou diagnostiquez une mauvaise journée. Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie et la décision à prendre.
Task 1: Identify the server distribution and version
cr0x@server:~$ mysql --version
mysql Ver 8.0.36-28 for Linux on x86_64 (Percona Server (GPL), Release 28, Revision 0d1c3e3)Signification : Il s’agit de Percona Server, build compatible MySQL 8.0, avec la chaîne de release de Percona.
Décision : Confirmez que votre plan de test correspond exactement à cette version majeure/mineure. « 8.0 » n’est pas une seule chose ; les versions mineures changent le comportement.
Task 2: Confirm server variables that often differ
cr0x@server:~$ mysql -e "SHOW VARIABLES LIKE 'version%'; SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit'; SHOW VARIABLES LIKE 'performance_schema';"
+-------------------------+----------------------------------------------+
| Variable_name | Value |
+-------------------------+----------------------------------------------+
| version | 8.0.36-28 |
| version_comment | Percona Server (GPL), Release 28, Revision...|
+-------------------------+----------------------------------------------+
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| innodb_flush_log_at_trx_commit| 1 |
+-------------------------------+-------+
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| performance_schema | ON |
+--------------------+-------+Signification : La durabilité est stricte (1), et Performance Schema est activé.
Décision : Si vous migrez, alignez les variables critiques entre l’ancien et le nouveau pour garder des performances comparables pendant les tests.
Task 3: Check current load and whether you’re saturated
cr0x@server:~$ mysql -e "SHOW GLOBAL STATUS LIKE 'Threads_running'; SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW VARIABLES LIKE 'max_connections';"
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Threads_running | 54 |
+-----------------+-------+
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Max_used_connections | 980 |
+----------------------+-------+
+-----------------+------+
| Variable_name | Value|
+-----------------+------+
| max_connections | 1000 |
+-----------------+------+Signification : Vous frôlez le plafond de connexions. Ce n’est pas « correct ». C’est une future panne.
Décision : Ajoutez du pooling, réduisez le churn des connexions, ou augmentez max_connections seulement après avoir confirmé la marge mémoire et le comportement d’ordonnancement des threads.
Task 4: Find the worst offenders right now (processlist)
cr0x@server:~$ mysql -e "SHOW FULL PROCESSLIST;" | head
Id User Host db Command Time State Info
4123 app 10.0.2.19:53124 prod Query 42 Sending data SELECT ...
4177 app 10.0.2.20:49812 prod Query 41 Waiting for table metadata lock ALTER TABLE orders ...
4211 app 10.0.2.21:40210 prod Query 39 Updating UPDATE inventory SET ...Signification : Un ALTER TABLE attend un verrou metadata, susceptible de bloquer ou d’être bloqué.
Décision : Si c’est un pic de production, arrêtez la DDL ou migrez-la vers un outil de migration en ligne. Puis localisez le bloqueur (souvent une transaction longue).
Task 5: Confirm metadata lock contention (common during migrations)
cr0x@server:~$ mysql -e "SELECT object_schema, object_name, lock_type, lock_status, owner_thread_id FROM performance_schema.metadata_locks WHERE lock_status='PENDING' LIMIT 5;"
+---------------+-------------+-----------+-------------+-----------------+
| object_schema | object_name | lock_type | lock_status | owner_thread_id |
+---------------+-------------+-----------+-------------+-----------------+
| prod | orders | EXCLUSIVE | PENDING | 8821 |
+---------------+-------------+-----------+-------------+-----------------+Signification : Quelqu’un attend un verrou metadata exclusif sur prod.orders.
Décision : Identifiez la session tenant des verrous metadata partagés (souvent un long SELECT dans une transaction) et laissez-la finir ou tuez-la si justifié.
Task 6: Check InnoDB engine status for lock waits and flushing pressure
cr0x@server:~$ mysql -e "SHOW ENGINE INNODB STATUS\G" | egrep -i "LATEST DETECTED DEADLOCK|History list length|Log sequence number|Log flushed up to|Pending flushes|lock wait" | head -n 40
History list length 231455
Pending flushes (fsync) log: 37; buffer pool: 124
---TRANSACTION 824912, ACTIVE 58 sec
LOCK WAIT 45 lock struct(s), heap size 8400, 22 row lock(s)Signification : La history list length est élevée (retard de purge), et il y a des flushs en attente. Vous avez probablement une pression d’écriture et/ou des transactions longues.
Décision : Cherchez les transactions longues ; envisagez de réduire la charge d’écriture ; vérifiez la latence du stockage ; tunez purge et flush seulement après mesure de l’I/O.
Task 7: Spot long-running transactions that hold back purge
cr0x@server:~$ mysql -e "SELECT trx_id, trx_state, trx_started, trx_rows_locked, trx_query FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 5;"
+--------+----------+---------------------+----------------+------------------------------+
| trx_id | trx_state| trx_started | trx_rows_locked| trx_query |
+--------+----------+---------------------+----------------+------------------------------+
| 824901 | RUNNING | 2025-12-30 09:41:12 | 0 | SELECT * FROM big_table ... |
+--------+----------+---------------------+----------------+------------------------------+Signification : Une transaction longue empêche probablement la purge et fait gonfler les undo, ce qui finit par se traduire par des problèmes d’I/O.
Décision : Corrigez le périmètre des transactions dans l’application. À court terme, tuez-la si c’est sûr, puis surveillez la baisse de la history list length.
Task 8: Check replication lag and SQL thread state
cr0x@server:~$ mysql -e "SHOW REPLICA STATUS\G" | egrep -i "Seconds_Behind_Source|Replica_IO_Running|Replica_SQL_Running|Last_SQL_Error|Retrieved_Gtid_Set|Executed_Gtid_Set" | head -n 30
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 187
Last_SQL_Error:
Retrieved_Gtid_Set: 1-12345-67890:1-991223
Executed_Gtid_Set: 1-12345-67890:1-990812Signification : La réplique a plusieurs minutes de retard. Les lectures routées ici peuvent être obsolètes et provoquer des incohérences applicatives ou des retries.
Décision : Identifiez la cause du retard : grosse transaction, DDL, réplique liée à l’I/O, ou application mono-thread. Atténuez en re-planifiant des jobs lourds, en améliorant l’I/O de la réplique ou en ajustant la réplication parallèle.
Task 9: See what the kernel thinks (CPU vs I/O wait)
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (db01) 12/30/2025 _x86_64_ (16 CPU)
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 22.10 0.00 6.70 31.40 0.00 0.40 0.00 0.00 0.00 39.40Signification : iowait élevé. Votre CPU n’est pas le goulot ; c’est la chaîne de stockage.
Décision : Ne commencez pas par tuner les requêtes. Mesurez la latence du stockage, le comportement de flush et la pression de checkpoint.
Task 10: Measure disk latency and saturation
cr0x@server:~$ iostat -x 1 3
Device r/s w/s r_await w_await aqu-sz %util
nvme0n1 120.0 980.0 6.10 44.30 18.20 99.60Signification : Les écritures sont lentes (w_await ~44ms) et le device est saturé (%util ~100%).
Décision : Vous devez réduire la charge d’écriture, améliorer le stockage ou modifier les attentes de durabilité. Envisagez aussi si doublewrite, binlog sync et fréquence de fsync sont alignés avec votre matériel.
Task 11: Identify top wait events (Performance Schema)
cr0x@server:~$ mysql -e "SELECT event_name, count_star, round(sum_timer_wait/1000000000000,2) AS total_s FROM performance_schema.events_waits_summary_global_by_event_name ORDER BY sum_timer_wait DESC LIMIT 5;"
+----------------------------------------+------------+---------+
| event_name | count_star | total_s |
+----------------------------------------+------------+---------+
| wait/io/file/innodb/innodb_log_file | 122334 | 842.12 |
| wait/io/file/innodb/innodb_data_file | 99321 | 611.45 |
| wait/synch/mutex/innodb/buf_pool_mutex | 45433 | 210.33 |
+----------------------------------------+------------+---------+Signification : Le temps est dominé par l’I/O des logs et fichiers de données InnoDB, plus une certaine contention du buffer pool.
Décision : Concentrez-vous sur le débit du redo log, les paramètres de flush et la latence du device. Si vous envisagez Percona, validez si son instrumentation rend cette analyse plus simple et moins coûteuse à exécuter en continu.
Task 12: Turn on slow query logging safely (temporary)
cr0x@server:~$ mysql -e "SET GLOBAL slow_query_log=ON; SET GLOBAL long_query_time=0.2; SET GLOBAL log_queries_not_using_indexes=OFF; SHOW VARIABLES LIKE 'slow_query_log_file';"
+---------------------+--------------------------+
| Variable_name | Value |
+---------------------+--------------------------+
| slow_query_log_file | /var/lib/mysql/db01-slow.log |
+---------------------+--------------------------+Signification : Le slow query log est activé avec un seuil de 200ms ; vous avez un chemin de fichier à inspecter.
Décision : Collectez des échantillons pendant la fenêtre d’incident, puis revenez aux seuils normaux. Ne laissez pas « 0.2s pour toujours » à moins d’aimer les logs énormes et les rotations manquées.
Task 13: Verify table and index sizes to catch silent bloat
cr0x@server:~$ mysql -e "SELECT table_schema, table_name, round((data_length+index_length)/1024/1024,1) AS mb FROM information_schema.tables WHERE table_schema='prod' ORDER BY (data_length+index_length) DESC LIMIT 5;"
+-------------+------------+--------+
| table_schema| table_name | mb |
+-------------+------------+--------+
| prod | events | 84210.4|
| prod | orders | 22110.7|
| prod | users | 8110.2|
+-------------+------------+--------+Signification : Vous avez quelques très grandes tables. La maintenance des index et la résidence dans le buffer pool domineront le comportement.
Décision : Priorisez le tuning des requêtes/index sur les plus grandes tables ; envisagez le partitionnement seulement si vous en maîtrisez les conséquences opérationnelles.
Task 14: Validate backup usability (not just that it “completed”)
cr0x@server:~$ xtrabackup --prepare --target-dir=/backups/full-2025-12-29
xtrabackup: This target seems to be OK.
xtrabackup: completed OK!Signification : La sauvegarde peut être préparée (état crash-consistent) et est probablement restaurable.
Décision : Si vous ne pouvez pas la préparer, vous n’avez pas de sauvegarde. Corrigez le pipeline avant de toucher aux upgrades.
Task 15: Check configuration drift between MySQL and Percona nodes
cr0x@server:~$ mysqld --verbose --help 2>/dev/null | egrep -i "innodb_buffer_pool_size|innodb_log_file_size|innodb_redo_log_capacity|sync_binlog" | head
innodb_buffer_pool_size 34359738368
innodb_redo_log_capacity 8589934592
sync_binlog 1Signification : Vous pouvez analyser les valeurs par défaut effectives et garantir des réglages identiques entre nœuds.
Décision : Verrouillez la gestion de configuration. Si les nœuds diffèrent, vos benchmarks mentent et vos incidents deviennent « ça marche sur la réplique ».
Trois mini-récits du monde de l’entreprise
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
L’entreprise était en pleine migration d’un monolithe legacy vers des services. Comme d’habitude, la base de données était la dépendance partagée. Quelqu’un a proposé de passer de MySQL standard à Percona Server parce que l’équipe voulait une meilleure visibilité sur les stalls et les attentes de verrou. L’expression « remplaçant drop-in » a été répétée assez souvent pour devenir une politique par accident.
Ils ont effectué le swap en staging. L’application a démarré. Les tests de lecture/écriture de base ont passé. Tout le monde s’est tapé dans la main et a planifié un redémarrage en production en rolling derrière un load balancer. Tout semblait propre — jusqu’au premier pic de trafic.
La latence a grimpé. Puis le débit s’est effondré. Pas parce que Percona était plus lent, mais parce que l’équipe avait supposé que « même comportement binaire » signifiait « même comportement mémoire ». Sur les nouveaux nœuds, les consommateurs de Performance Schema étaient activés plus largement qu’avant, et quelques réglages d’instrumentation ont augmenté la consommation mémoire. Combiné à un max_connections agressif, les machines ont subi une pression mémoire et ont commencé à swapper. La base de données ne « plantait » pas. Elle est simplement devenue lente et énergivore.
La correction fut ennuyeuse : ajuster les consommateurs d’instrumentation, plafonner les connexions et standardiser la taille du buffer pool. La leçon fut plus nette : compatibilité n’est pas équivalence. Si vous ne validez pas la mémoire, vous ne faites pas une mise à niveau drop-in — vous menez une expérience non planifiée sur vos clients.
Mini-récit 2 : L’optimisation qui a retombé
Une autre organisation avait une charge write-heavy : commandes, événements et un job en arrière-plan qui batchait les mises à jour toutes les quelques minutes. Ils étaient I/O bound et fiers de l’être, parce que cela voulait dire « on utilise le matériel ». Ils sont passés à Percona Server pour obtenir plus de leviers autour des flushs et diagnostiquer la pression sur le redo log.
Pendant une session de tuning post-incident, quelqu’un a décidé de réduire la fréquence des fsync pour « débloquer les performances ». Ils ont modifié les paramètres liés à la durabilité pendant une période calme, exécuté un benchmark rapide et obtenu une belle amélioration. Les graphes semblaient plus sains. Ils ont mis en production.
Deux semaines plus tard, l’hyperviseur a subi un reboot non propre. La base a récupéré, mais l’entreprise a constaté un vide de transactions récentes que l’application avait pourtant confirmées. L’équipe avait effectivement troqué durabilité contre débit sans décision formelle. Personne n’avait consigné le risque. Personne n’en avait informé le produit. Tout le monde a appris la leçon en même temps, ce qui est la pire façon d’apprendre.
Ils ont rollbacké les réglages risqués, accepté la perte de performance et investi dans un meilleur stockage et un meilleur regroupement des écritures. Percona n’était pas la cause. La cause était l’habitude humaine de tuner pour des benchmarks en oubliant les modes de défaillance.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société liée aux paiements exécutait MySQL avec des exigences RPO/RTO strictes. Ils n’ont rien fait de spectaculaire. Ils traitaient simplement les sauvegardes comme du code : versionnées, testées et répétées. Ils maintenaient aussi une réplique chaude avec la même distribution serveur et la même configuration, régulièrement reconstruite à partir des sauvegardes.
Quand ils ont évalué Percona Server, ils ont fait de même. Ils ont construit des réplicas Percona, les ont laissés répliquer pendant des semaines et ont comparé compteurs de performance et plans de requêtes. Pas de grand lancement. Pas de basculement héroïque.
Puis un vrai incident est arrivé : un humain a exécuté une requête destructive dans la mauvaise session. Classique. Le rayon d’impact a été limité parce qu’ils avaient les binlogs et une reprise PITR répétée. Ils ont restauré dans un environnement scratch, vérifié les invariants applicatifs et promu une réplique propre. Le postmortem a été court parce que le système a réagi comme prévu.
La pratique qui les a sauvés n’était pas spécifique à Percona. C’était la discipline ennuyeuse : tests réguliers de restauration, cutovers contrôlés et cohérence de configuration. Les fonctionnalités avancées sont agréables. La prédictibilité est plus précieuse.
Erreurs courantes : symptôme → cause racine → correction
Ce ne sont pas des exercices académiques. Ce sont des pièges dans lesquels tombent les gens en traitant Percona comme « juste MySQL » ou MySQL comme « juste une base de données ».
1) Symptom: sudden spikes in query latency after “drop-in” swap
Cause racine : surcharge d’instrumentation + montée en connexions + pression mémoire (swap) ou contention due aux consommateurs activés.
Correction : mesurez le RSS et le swap ; ajustez les consommateurs Performance Schema ; imposez du pooling de connexions ; conservez la taille du buffer pool stable entre distributions.
2) Symptom: replica lag grows during peak writes, never fully recovers
Cause racine : application mono-thread, grosses transactions, ou stockage de réplique plus lent que le primaire ; parfois des événements DDL bloquent l’apply.
Correction : réduisez la taille des transactions ; activez/ajustez la réplication parallèle ; assurez des I/O comparables sur les répliques ; planifiez les DDL hors pics et utilisez des techniques de changement de schéma en ligne.
3) Symptom: “Waiting for table metadata lock” appears everywhere
Cause racine : transaction longue tenant des verrous metadata partagés pendant que la DDL attend ; ou outil de migration en ligne mal configuré.
Correction : trouvez et terminez le bloqueur ; gardez les transactions courtes ; utilisez correctement pt-online-schema-change ; évitez de laisser des sessions interactives ouvertes en transaction.
4) Symptom: high iowait, pending flushes, and throughput collapse under write bursts
Cause racine : stockage saturé ; coût des fsync redo/binlog trop élevé pour le device ; flushs qui prennent du retard.
Correction : améliorez la latence/IOPS du stockage ; ajustez la capacité du redo/log de façon appropriée ; lissez les pics d’écriture ; séparez le binlog sur un média rapide si l’architecture le permet ; vérifiez le système de fichiers et les options de montage.
5) Symptom: “deadlocks increased after upgrade”
Cause racine : la charge a changé (plus de concurrents), les plans de requêtes ont changé, ou les transactions sont devenues plus longues. Les mises à niveau mettent en lumière des problèmes de conception existants.
Correction : réduisez le périmètre des transactions ; ajoutez les index appropriés ; réordonnez les statements de façon cohérente ; envisagez une isolation inférieure si sûr ; traitez les deadlocks comme un signe de conception de schéma/requêtes à revoir.
6) Symptom: backups “succeed” but restores fail or are inconsistent
Cause racine : sauvegarde non préparée, binlogs manquants, rétention incorrecte, ou restauration non testée ; parfois problèmes d’encryption/permissions.
Correction : automatisez prepare+restore tests ; vérifiez la continuité des binlogs ; stockez les métadonnées de sauvegarde ; pratiquez la PITR mensuellement.
7) Symptom: performance regresses only for a specific query set
Cause racine : différences d’optimiseur entre versions mineures ou valeurs par défaut modifiées ; divergence des statistiques ; instabilité de plan.
Correction : comparez les plans EXPLAIN ; mettez à jour les statistiques ; utilisez les hints de l’optimiseur avec parcimonie ; fixez les plans seulement en dernier recours ; benchmarkez avec des données et paramètres proches de la production.
Blague #2 : L’optimiseur est comme un chat : il est sûr de lui, il est rapide, et il vous ignorera à moins que vous ne prouviez que vous êtes aux commandes.
Checklists / plan pas à pas (upgrade, validation, rollback)
Checklist A: Decide whether Percona is worth it
- Écrivez votre douleur primaire : requêtes lentes, stalls, manque de métriques, fenêtres de sauvegarde, retard de réplication.
- Inventoriez les contraintes : restrictions de service managé, exigences de conformité, attentes de support interne.
- Définissez des métriques de succès : latence p95/p99, débit maximal sur le même matériel, temps moyen de diagnostic, limites de retard de réplication.
- Identifiez les risques « no-go » : compatibilité des plugins d’authentification, hypothèses des outils, verrouillage de version.
Checklist B: Build a safe test environment (the part everyone skips)
- Clonez le schéma de production et un échantillon de données représentatif (ou une copie complète si faisable).
- Rejouez le trafic réel (replay de logs de requêtes, canary applicatif ou générateur de charge basé sur des patterns capturés).
- Assortez le kernel, le système de fichiers et la classe de stockage. Ne benchmarkez pas sur NVMe en test et déployez sur stockage réseau.
- Assurez-vous d’avoir la même configuration. Si vous changez innodb_buffer_pool_size pendant les tests, vous ne testez plus le swap de serveur.
Checklist C: Execute the “drop-in” swap with rollback discipline
- Choisissez la cible de compatibilité : même famille de version majeure (ex. MySQL 8.0 ↔ Percona Server for MySQL 8.0).
- Faites une sauvegarde vérifiée : préparez-la ; restaurez-la quelque part ; confirmez tables, comptes et invariants applicatifs.
- Provisionnez d’abord une réplique : déployez Percona comme réplique de MySQL (ou l’inverse) et laissez-la répliquer sous trafic réel pendant des jours.
- Comparez le comportement : retard, CPU, I/O, latence p95, attentes de verrou, comportement de flush en arrière-plan.
- Planifiez le cutover : bascule contrôlée avec un palier canary ; gardez l’ancien primaire prêt pour rollback.
- Plan de rollback : définissez ce que signifie « trigger de rollback » (taux d’erreur, p99, retard) et répétez les étapes.
Checklist D: Post-cutover hygiene (where production survives)
- Gelez les changements de schéma non essentiels pendant une semaine.
- Activez la surveillance ciblée pour les waits, la latence fsync, le retard de réplication et le churn de connexions.
- Examinez les slow logs et les top waits quotidiennement pendant la première semaine ; puis hebdomadairement.
- Effectuez un drill de restauration dans les 30 jours. Si cela fait 30 jours depuis le dernier test de restauration, votre sauvegarde est une rumeur.
FAQ
1) Is Percona Server really a drop-in replacement for MySQL?
Souvent, oui au niveau du protocole client et pour la compatibilité sur disque dans la même ligne majeure. Opérationnellement, vous devez quand même valider les valeurs par défaut, le coût de l’instrumentation et votre chaîne d’outils.
2) Will my application need code changes?
Généralement non. La plupart des changements sont opérationnels : configuration, monitoring, outils de sauvegarde et validation du comportement sous charge. Des cas limites existent avec des plugins d’authentification et des modes SQL.
3) Is Percona Server faster than MySQL?
Parfois. L’avantage le plus important est souvent la stabilité et la capacité de diagnostic, pas le débit brut. Si votre goulot est le stockage lent, aucune distribution serveur ne battra la physique.
4) Does enabling more instrumentation hurt performance?
Ça peut. L’instrumentation a un coût, et ce coût dépend des consommateurs activés et de votre charge. La bonne méthode est d’activer ce dont vous avez besoin, mesurer l’overhead et garder un « set minimal d’incident » que vous pouvez basculer rapidement.
5) What’s the safest migration path?
Réplique d’abord. Montez la nouvelle distribution comme réplique, laissez-la répliquer sous trafic réel, comparez les métriques, puis promouvez via un failover contrôlé. Les swaps in-place sont pour ceux qui aiment les surprises.
6) Can I mix MySQL and Percona Server in the same replication topology?
Couramment oui quand les versions sont compatibles. Mais vous devez tester le comportement de réplication, les réglages GTID et les différences de plugins. Traitez-le comme une topologie mixte : supporté ne signifie pas sans risque.
7) What if I’m already on MySQL 8 and things are stable?
Alors la règle par défaut : ne touchez à rien. Envisagez Percona seulement si vous avez des douleurs diagnostiques récurrentes, des stalls de performance inexpliqués ou un mauvais alignement du modèle de support.
8) Is Percona “more risky” because it’s a fork?
Le risque vient de l’incertitude opérationnelle, pas du mot « fork ». Si vous validez et standardisez, Percona peut réduire le risque en rendant les problèmes visibles plus tôt. Si vous improvisez, tout changement est risqué.
9) Do I need new backup tools if I switch?
Pas strictement, mais beaucoup d’équipes associent Percona Server à des outils de backup physiques parce que cela cadre avec leur modèle opérationnel. Quel que soit l’outil, la seule sauvegarde qui compte est celle que vous avez restaurée.
10) What’s the number-one reason “drop-in” upgrades fail?
Supposer l’équivalence. Les gens testent « est-ce que ça démarre ? » au lieu de « est-ce que ça se comporte de la même manière pendant notre pire journée ? » La production ne note pas sur une courbe d’indulgence.
Étapes suivantes réalisables cette semaine
- Exécutez le playbook de diagnostic rapide un jour normal. Les baselines permettent de détecter la dérive avant qu’elle ne fasse mal.
- Inventoriez vos 20 requêtes principales (par temps total, pas par nombre). Si vous ne les connaissez pas, vous faites du tuning à l’aveugle.
- Montez une réplique Percona (ou une réplique MySQL, si vous allez dans l’autre sens) et laissez-la mûrir sous réplication réelle.
- Comparez les profils d’attente et le comportement I/O en utilisant les tâches ci-dessus. Décidez avec des preuves, pas avec des impressions.
- Rédigez un trigger de rollback : « Si la latence p99 dépasse X pendant Y minutes » et « Si le retard de réplication dépasse Z. » Mettez-le dans votre runbook.
- Testez une restauration. Pas « on pourrait restaurer », mais « on a restauré et l’application a fonctionné ». C’est le meilleur gain de fiabilité le moins cher.
Si vous voulez la recommandation directe : si votre MySQL de production est critique et que vous perdez régulièrement du temps à cause de stalls mystérieux, exécutez une réplique Percona en parallèle et voyez ce qu’elle révèle. Si vous êtes stable, ne touchez pas au clavier et investissez dans les sauvegardes, le monitoring et l’hygiène des requêtes. Les deux choix sont respectables. Un seul est à la mode.