MariaDB vs Percona Server : Remplacement « drop-in » ou piège de compatibilité ?

Ce que « remplacement drop-in » signifie réellement (et pourquoi ça mord)

Pour les opérations, « remplacement drop-in » ne veut dire qu’une chose : votre application se connecte, exécute les migrations, sert le trafic, survit au basculement, et vous pouvez la sauvegarder et la restaurer sous pression. Pas « ça démarre » et pas « ça passe les tests unitaires ».

MariaDB et Percona Server portent tous deux le badge « compatible MySQL », mais ils sont compatibles dans des directions et à des couches différentes :

• Compatibilité de protocole : les clients peuvent généralement se connecter. « Généralement » cache des nuances d’authentification et de TLS.
• Compatibilité du dialecte SQL : le SQL courant fonctionne, mais les cas limites (JSON, fonctions de fenêtre dans les versions plus anciennes, hints d’optimiseur) peuvent diverger.
• Compatibilité comportementale : même schéma et même requête peuvent retourner les mêmes lignes… avec des performances et des verrouillages différents.
• Compatibilité opérationnelle : les outils de sauvegarde, la sémantique de réplication et les tables système comptent plus que la plupart des équipes ne l’admettent.

Si vous échangez entre MariaDB et Percona Server, le piège est de supposer qu’ils sont tous deux « juste MySQL ». Percona Server tend à suivre de près MySQL en amont (parce que c’est fondamentalement MySQL avec des extensions). MariaDB a pris sa propre voie forkée il y a longtemps et a continué d’évoluer en gardant le label « MySQL » tout en modifiant les internes et les fonctionnalités.

Blague n°1 : « Remplacement drop-in » c’est comme « hot swap » dans une demande de changement : ça signifie que vous allez le remplacer alors que c’est chaud.

Voici la posture qui sauve les équipes : considérez un passage MariaDB ↔ Percona Server comme une migration majeure de moteur, pas un patch mineur. Planifiez-la comme vous le feriez pour PostgreSQL ↔ MySQL ? Non. Mais plus proche que vous ne voudriez le croire.

Généalogie et contexte historique (les faits qu’on oublie)

Un peu d’histoire courte, parce que ça explique les champs de mines de compatibilité actuels. Ce ne sont pas des anecdotes ; elles prédisent comment votre mise à niveau/migration se comportera.

1. MariaDB a forké MySQL en 2009 suite aux inquiétudes concernant l’acquisition d’Oracle sur Sun Microsystems et la gouvernance de MySQL.
2. Percona Server a commencé comme une distribution axée sur la performance qui reste proche de MySQL en amont tout en ajoutant de l’instrumentation et des fonctionnalités de type entreprise.
3. MariaDB a divergé volontairement : elle a gardé la compatibilité du protocole client MySQL mais introduit ses propres fonctionnalités et moteurs de stockage (notamment Aria) et son propre travail d’optimiseur.
4. GTID n’est pas « un seul GTID » : l’implémentation GTID de MariaDB diffère de celle de MySQL/Percona, ce qui impacte les outils de basculement et les topologies mixtes.
5. Mariabackup est une branche de la lignée XtraBackup, mais le comportement, l’accouplement des versions et les cas limites diffèrent suffisamment pour que « utilisez n’importe lequel » soit risqué.
6. Les tables système et le dictionnaire de données ont évolué différemment : MySQL 8 a introduit des changements majeurs du dictionnaire ; MariaDB a pris une route différente. Les outils qui scrutent mysql.* peuvent casser.
7. Le JSON est un point douloureux récurrent : MariaDB a historiquement implémenté JSON comme une chaîne avec des fonctions ; MySQL le traite comme un type natif avec une sémantique d’indexation différente.
8. Les plugins d’authentification ont divergé : MySQL/Percona sont passés par caching_sha2_password ; MariaDB a préféré différents ensembles de plugins et des valeurs par défaut variables selon la version.
9. Les chemins de l’optimiseur ne sont pas interchangeables : les deux ont des modèles de coût et des heuristiques qui changent les plans de requête de façons « légales » mais opérationnellement explosives.

Ces différences ne signifient pas que l’un est « mauvais ». Elles signifient que le même plan ne fonctionnera pas toujours. Votre travail est de savoir quelles hypothèses vous faites, puis d’abattre celles qui ne sont pas vraies.

Une citation à agrafer sur chaque plan de migration : « L’espoir n’est pas une stratégie. » — James Cameron.

Carte de compatibilité : où MariaDB et Percona Server divergent

1) Versionnement et ciblage des fonctionnalités

Percona Server suit généralement les sorties MySQL en amont (et leurs sémantiques), donc son objectif de compatibilité est « comportement MySQL + extras ». MariaDB cible le « comportement MariaDB », tout en restant MySQL-esque pour les cas d’usage courants.

Si votre fournisseur d’applications dit « compatible MySQL 8 », cela correspond habituellement plus naturellement à Percona Server pour MySQL 8 qu’à MariaDB. Si votre fournisseur dit « supporte MariaDB », n’interprétez pas cela comme « supporte MySQL ». Ce sont deux promesses différentes.

2) Tables système, métadonnées et hypothèses d’outillage

Beaucoup de scripts d’entreprise commettent des crimes contre la base de données mysql. Ils interrogent des tables système héritées directement. Ou ils parsèment la sortie de SHOW PROCESSLIST comme si c’était une API stable. Ou ils supposent que les colonnes de information_schema existent de la même façon partout.

Ça marche—jusqu’à ce que ça ne marche plus. Dans les migrations, c’est souvent l’outillage qui casse en premier, pas la base de données.

3) Plugins et fonctionnalités qui semblent similaires mais ne le sont pas

Plugins d’authentification, plugins d’audit, validation des mots de passe, chiffrement — les noms se chevauchent, le comportement non. « Nous utilisons le plugin d’audit » n’est pas une exigence ; c’est une faille de spécification à moins que vous puissiez nommer lequel, quels événements et où vont les logs.

4) InnoDB : « même nom d’engin », patches différents

Les deux mondes utilisent InnoDB, mais avec des séries de patches, des valeurs par défaut et parfois une instrumentation différente. Percona est célèbre pour ses métriques supplémentaires et ses changements orientés performance. MariaDB a historiquement livré XtraDB dans certaines versions, puis est revenue vers InnoDB. Opérationnellement, cela se traduit par des valeurs par défaut différentes, des zones de réglage différentes, et des seuils « tout va bien » distincts.

Conclusion pratique : n’assumez pas que votre fichier de tuning InnoDB est portable. Vous pouvez garder l’esprit, pas les valeurs littérales.

Réplication et haute disponibilité : GTID, basculement et les arêtes vives

GTID : la grande bifurcation de compatibilité

Si vous ne retenez qu’une chose de cet article, retenez-la : le GTID de MariaDB et le GTID de MySQL/Percona sont des systèmes différents. Ils résolvent des problèmes similaires avec des formats et des comportements opérationnels différents.

Cela importe pour :

• Automatisation de basculement : les outils qui supposent la sémantique GTID MySQL peuvent faire des promotions dangereuses sur MariaDB, et vice versa.
• Clusters mixtes : « Nous ferons des répliques MariaDB d’un primaire Percona pour un temps » n’est pas une décision anodine. C’est généralement un pont de courte durée avec des contraintes strictes, pas une architecture d’état stable.
• Restauration point-in-time : votre workflow de récupération basé sur les binlogs peut exiger des ajustements, surtout autour de la rigidité et de la consistance des GTID.

Filtres de réplication et comportement en mode row

La réplication basée sur les instructions est le terrain où les fantômes vivent. Si vous migrez, forcez-vous à utiliser la réplication en mode row sauf si vous avez une raison solide de ne pas le faire. Les différences de déterminisme des fonctions, de comportement de collation ou de mode SQL peuvent rendre la réplication par instruction « techniquement réussie » tout en corrompant lentement les données.

Group replication et attentes Galera

Percona Server est souvent déployé avec des topologies de réplication de style MySQL ou Percona XtraDB Cluster (basé sur Galera). MariaDB a aussi des variantes Galera. La similarité s’arrête quand vous réalisez que chaque écosystème a ses propres valeurs par défaut, son outillage opérationnel, et sa gestion des cas limites.

Si votre histoire de haute disponibilité dépend de « Galera s’en chargera », vous externalisez la justesse à un système qui a toujours besoin que vous définissiez le comportement en cas de conflit, les modèles d’écriture, et les décisions de quorum.

Sauvegarde et restauration : XtraBackup vs mariabackup et la réalité de la restauration

Les sauvegardes sont l’endroit où les affirmations de compatibilité meurent en silence. La base démarre, les requêtes fonctionnent, tout le monde se détend — jusqu’à ce qu’un test de restauration révèle que votre outillage de sauvegarde était « principalement compatible » avec le serveur effectivement exécuté.

XtraBackup (Percona) vs mariabackup (MariaDB)

Opérationnellement, les deux visent à faire des sauvegardes physiques à chaud d’InnoDB. En pratique :

• Couplage de versions : les outils de sauvegarde sont pointilleux sur les versions du serveur. « Assez proche » devient « ne prépare pas la sauvegarde ».
• Différences de chiffrement/compression : les options et valeurs par défaut varient ; les pipelines de restauration cassent si vous supposez que les flags sont portables.
• Incrémentales : ça marche, jusqu’à ce que ça ne marche plus — surtout lors des montées de version ou de changements de paramètres du redo log.

Ma règle d’or : les tests de restauration font partie de la migration. Pas après. Pas « on le fera plus tard ». Si vous ne pouvez pas restaurer, vous n’avez pas une base de données, vous avez une rumeur.

Blague n°2 : Les sauvegardes sont comme les parachutes : si vous ne les testez qu’une fois, c’est généralement la dernière fois où vous en aurez besoin.

Sécurité et authentification : plugins, TLS et surprises côté client

Les plugins d’authentification peuvent faire échouer des clients « compatibles »

Les bibliothèques clientes intègrent souvent des hypothèses sur les plugins d’auth par défaut. Quand MySQL a changé ses valeurs par défaut (notamment autour de caching_sha2_password dans MySQL 8), cela a déclenché un cortège d’incidents de connexion sur plusieurs années à travers langages et paquets OS.

MariaDB a fait des choix différents et proposé d’autres plugins. Percona suit de près le comportement de MySQL. Cela signifie que la même image de conteneur d’application peut se connecter à l’un et échouer à l’autre — sans aucun changement de code.

TLS et politiques de chiffrement incompatibles

TLS « fonctionne » jusqu’à ce que votre équipe conformité impose de nouveaux suites de chiffrement ou des versions minimales. Différentes builds serveur et paquets de distribution peuvent lier OpenSSL différemment, avoir des valeurs par défaut différentes, et accepter des jeux de chiffres différents.

Rendez la sécurité explicite : définissez la version TLS, les suites de chiffrement attendues, et les versions des bibliothèques clientes dans votre runbook.

Optimiseur et performance : le problème « même requête, plan différent »

Les pannes les plus coûteuses sont celles où rien n’est cassé. C’est juste plus lent. Assez lent pour provoquer un effet domino.

Pourquoi les plans dérivent

Même quand la syntaxe SQL est supportée, l’optimiseur peut choisir des ordres de jointure, des index et des stratégies de table temporaire différents. Les raisons incluent :

• Différents modèles de coût et gestion des statistiques
• Différentes valeurs par défaut pour les tables temporaires, limites mémoire et buffers de tri
• Différentes interprétations des hints ou syntaxes de hint disponibles
• Différent comportement de collation affectant l’utilisation des index

Conseils pratiques

Avant la migration, capturez les plans de requêtes représentatifs et le comportement d’exécution réel. Pas seulement EXPLAIN — aussi la distribution des latences, les lignes examinées et la contention. Après la migration, comparez de nouveau avec la même forme de jeu de données.

Si vous n’allez pas faire cela, soyez honnête : vous jouez à la roulette, pas à l’ingénierie.

Observabilité et outillage : ce que vos tableaux de bord ne vous diront pas

La plupart des configurations de « monitoring MySQL » sont un amas d’hypothèses : quelles variables de statut existent, quelles tables du performance_schema sont activées, à quoi ressemble le slow log, et quel utilisateur a les permissions pour tout lire.

Les écosystèmes Percona s’appuient souvent sur les conventions de Percona Toolkit et des métriques étendues. Les environnements MariaDB peuvent avoir des valeurs par défaut d’instrumentation différentes et une maturité du performance_schema variable selon la version. Les deux peuvent être rendus observables, mais pas en supposant que la config de votre exporter est portable.

Et : vérifiez vos scripts d’admin. Tout ce qui scrute SHOW ENGINE INNODB STATUS et cherche des chaînes en anglais est une responsabilité. Ça marchera jusqu’à ce que ça ne marche plus, et alors il vous appellera à 03:12 avec des absurdités.

Playbook de diagnostic rapide

Ceci est la procédure « nous venons de migrer et maintenant c’est lent/instable ». L’objectif est de trouver le goulot en minutes, pas de gagner une dispute sur lequel des deux serveurs est meilleur.

Première étape : identifier si la limite est CPU, IO, verrous ou réplication

• CPU : CPU utilisateur élevé, de nombreux threads exécutable, plans de requête changés, index manquants, ou nouveau comportement sort/temporaire.
• IO : temps d’attente élevés, défauts de buffer pool, pression redo/flush, stockage lent, innodb_flush_method incorrect.
• Verrous : pics de waits de verrou, deadlocks, transactions longues, valeurs par défaut d’isolation différentes.
• Réplication : retard de réplique, goulot d’application du relay log, incompatibilité GTID, changements de format de ligne.

Deuxième étape : vérifier les 3 requêtes principales et leurs plans

Ne parcourez pas mille métriques. Identifiez les principaux coupables (par temps total et p95). Comparez les plans par rapport à la référence.

Troisième étape : valider les bases opérationnelles

• Les binlogs sont-ils configurés comme prévu ?
• Le serveur est-il dans le bon mode SQL ?
• Des changements d’authentification ont-ils forcé des tempêtes de reconnexions côté clients ?
• Le chemin sauvegarde/restaure a-t-il changé la disposition des données (par ex., paramètres file-per-table différents) ?

Quatrième étape : décider de rollback, tuner ou patcher les requêtes

Rollback n’est pas un échec ; c’est du contrôle. Si votre restauration et votre nouvelle coupe sont répétées, rollback est une opération routinière. Si ce n’est pas le cas, vous êtes condamné à « tuner en direct » en perdant du sang.

Erreurs courantes : symptômes → cause racine → correction

1) L’application ne peut plus se connecter après la migration

Syndromes : « Plugin d’authentification non supporté », échecs de handshake, ou erreurs TLS depuis les clients.

Cause racine : valeurs par défaut d’auth plugin différentes ; bibliothèque cliente trop ancienne ; politique TLS incompatible.

Correction : alignez le plugin d’auth sur ce que les clients supportent ; mettez à jour les libs clients ; configurez TLS explicitement et vérifiez avec un client connu bon.

2) Les requêtes sont correctes mais 5–50× plus lentes

Syndromes : pics de latence p95, CPU en hausse, slow log rempli de requêtes qui allaient bien avant.

Cause racine : dérive du plan d’optimiseur ; différences de stats ; comportement de table temporaire différent ; collation/utilisation d’index modifiée.

Correction : capturez et comparez EXPLAIN/EXPLAIN ANALYZE (quand disponible), mettez à jour les statistiques, ajoutez ou ajustez les index, envisagez les hints uniquement en dernier recours.

3) La réplication « marche » mais le basculement casse

Syndromes : l’outil de basculement refuse de promouvoir, ou promeut mais les répliques ne se réattachent pas proprement.

Cause racine : incompatibilité sémantique GTID ; topologie en mode mixte ; paramètres binlog différents.

Correction : choisissez un seul univers GTID ; standardisez les paramètres de réplication ; testez la promotion et la réintégration sous charge en staging.

4) Les sauvegardes réussissent, les restaurations échouent

Syndromes : job de sauvegarde vert ; test de restauration échoue à la phase de prepare ou le serveur ne démarre pas.

Cause racine : mismatch versions outil/serveur ; mauvais flags ; mismatch chiffrement/compression ; attentes de redo logs manquantes.

Correction : bloquez les versions des outils de sauvegarde sur les versions serveur ; faites des répétitions périodiques de restauration ; validez que la backup préparée démarre proprement.

5) Contention de verrous soudaine après migration

Syndromes : hausse des waits de verrou, deadlocks, chute du débit malgré un mix de requêtes similaire.

Cause racine : valeurs par défaut différentes (isolation, autocommit exposé), plans d’exécution changés provoquant plus de lignes scannées/verrouillées, transactions longues issues de jobs batch.

Correction : identifiez les transactions bloquantes, raccourcissez les scopes de transaction, ajoutez des index pour réduire les lignes scannées, révisez le niveau d’isolation et les patterns de charge.

6) Le monitoring casse ou affiche des absurdités

Syndromes : tableaux de bord manquant de métriques, exporters en erreur, spam d’alertes sur « unknown variable ».

Cause racine : noms et disponibilité des métriques différents ; configuration du performance_schema différente ; différences de privilèges.

Correction : mettez à jour exporters et requêtes ; activez l’instrumentation requise de façon intentionnelle ; arrêtez de scruter des internes instables.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire 1 : l’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a décidé de « standardiser » les bases. Un produit utilisait MariaDB, un autre Percona Server. Le plan semblait simple : tout migrer vers un seul moteur pour que l’équipe on-call arrête de changer de contexte.

L’équipe de migration s’est concentrée sur le schéma et le déplacement des données. Ils ont validé que l’application démarrait, que le CRUD fonctionnait, et que les tests de fumée passaient. Ils ont supposé que le basculement de réplication se comporterait de la même façon parce que « c’est du MySQL ».

Deux semaines plus tard, un nœud primaire est mort. L’automatisation de basculement a promu une réplique, et l’app est revenue. Puis l’ancien primaire est revenu, et sa réintégration a échoué d’une façon que l’automatisation ne traitait pas. Le cluster s’est scindé en camps « je crois que j’ai avancé » et l’équipe a découvert que leurs hypothèses GTID n’étaient pas portables entre les moteurs qu’ils avaient mélangés pendant la transition.

La correction n’a pas été un tuning héroïque. Ce fut de l’honnêteté architecturale : ils ont gelé les topologies mixtes, reconstruit des répliques depuis des sauvegardes propres, et n’ont autorisé qu’un seul modèle GTID par domaine de réplication. La vraie leçon n’était pas la syntaxe GTID. C’était de ne pas traiter la sémantique HA comme un détail d’implémentation.

Mini-histoire 2 : l’optimisation qui a mal tourné

Une grande entreprise a migré d’une variante MySQL à une autre pour obtenir une meilleure instrumentation de performance et une latence plus faible. Après le cutover, ils ont constaté une IO plus élevée et des latences de queue pires. Ils ont fait ce que font beaucoup d’équipes : ils ont tourné des boutons.

Quelqu’un a augmenté les tailles de buffers et relevé des paramètres liés à la concurrence parce que « plus de threads égalent plus de débit ». Ils ont aussi ajusté le comportement de flush pour réduire la fréquence des fsync. Sur le papier, c’était du tuning classique.

Pendant environ une journée, le débit s’est amélioré. Puis ils ont subi un pic de trafic. Le serveur a commencé à bloquer par rafales : de courtes périodes normales suivies de pauses désagréables où tout s’accumulait. La cause racine était un schéma de pression flush/redo : ils avaient troqué une latence cohérente contre des chutes périodiques. Le tuning avait amplifié le pire moment de l’engin au lieu de le lisser.

Ils ont annulé les changements, profilé à nouveau, et découvert la vraie régression : une poignée de requêtes avaient basculé vers des plans utilisant de grandes tables temporaires. Corriger les index et les modèles de requête a réduit l’IO plus que n’importe quel changement de buffer. L’« optimisation » avait été une distraction, et elle a failli devenir la config permanente parce qu’elle avait brièvement bien paru.

Mini-histoire 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise liée à la finance avait une règle qui agaçait tout le monde : des exercices trimestriels de restauration, pas optionnels. Chaque exercice incluait la restauration d’une sauvegarde complète, l’application de binlogs jusqu’à un timestamp cible, et l’exécution d’une petite suite de vérifications de cohérence.

Lorsqu’ils ont migré de MariaDB à Percona Server, l’exercice a mis au jour un problème subtil tôt. Leur job de sauvegarde était vert, mais la backup préparée échouait de manière intermittente à démarrer après restauration à cause d’un mismatch de version entre le conteneur de l’outil de sauvegarde et la version du serveur en production.

Parce que l’exercice a eu lieu avant le cutover, la correction a été banale : bloquer les versions, préparer une image de sauvegarde testée, et ajouter un contrôle de compatibilité dans le CI qui exécutait un petit cycle backup/prepare/restore à chaque montée de version.

Des mois plus tard, ils ont eu un incident réel : suppression accidentelle de données. L’équipe a restauré proprement, appliqué les binlogs à la minute, et rendu le service sans improvisation. Personne n’a célébré, parce que c’était ennuyeux. C’est le compliment le plus élevé en ops.

Tâches pratiques (commandes + sorties + décisions)

Voici des tâches réelles que vous pouvez exécuter sur des hôtes Linux et dans la base de données. Chaque tâche inclut ce que la sortie signifie et quelle décision prendre ensuite. Exécutez-les avant et après une migration, et lors du diagnostic d’anomalies en production.

Task 1: Confirm server identity and version lineage

cr0x@server:~$ mysql -NBe "SELECT VERSION(), @@version_comment, @@version_compile_machine;"
10.11.6-MariaDB MariaDB Server x86_64

What it means: This tells you which family you’re actually running. @@version_comment often includes “Percona Server” or “MariaDB Server”.

Decision: Map your compatibility target. If you expected MySQL/Percona semantics and you see MariaDB, stop and re-check GTID, JSON, and plugin assumptions.

Task 2: Check SQL mode drift (silent behavior changer)

cr0x@server:~$ mysql -NBe "SELECT @@sql_mode;"
STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

What it means: SQL mode affects data validation, implicit conversions, and error handling.

Decision: Align SQL mode across old and new servers before comparing behavior. If you change it during migration, you’re changing app semantics.

Task 3: Verify default authentication plugin

cr0x@server:~$ mysql -NBe "SHOW VARIABLES LIKE 'default_authentication_plugin';"
default_authentication_plugin	mysql_native_password

What it means: Different defaults can break old clients.

Decision: If clients are legacy, keep a compatible plugin or upgrade clients first. Don’t “fix” production by weakening auth without tracking it.

Task 4: Inspect user plugins actually in use

cr0x@server:~$ mysql -NBe "SELECT user, host, plugin FROM mysql.user ORDER BY plugin, user LIMIT 10;"
app	%	mysql_native_password
repl	10.%	mysql_native_password

What it means: Even if the default is safe, specific users may be using incompatible plugins.

Decision: If you see plugins not supported on the target engine, you need a credential migration plan (and likely a client library audit).

Task 5: Check InnoDB and redo/flush basics

cr0x@server:~$ mysql -NBe "SHOW VARIABLES WHERE Variable_name IN ('innodb_flush_method','innodb_flush_log_at_trx_commit','innodb_buffer_pool_size');"
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	1
innodb_flush_method	O_DIRECT

What it means: These settings heavily influence latency, durability, and IO behavior.

Decision: Do not copy configs blindly. Re-evaluate per engine and per storage. If you change durability (innodb_flush_log_at_trx_commit), document the risk and get explicit sign-off.

Task 6: Validate binlog format and row image

cr0x@server:~$ mysql -NBe "SHOW VARIABLES WHERE Variable_name IN ('log_bin','binlog_format','binlog_row_image');"
log_bin	ON
binlog_format	ROW
binlog_row_image	FULL

What it means: These influence replication safety and compatibility.

Decision: For migrations, ROW + FULL is the conservative default. If you change to MINIMAL for performance, test downstream consumers and replication carefully.

Task 7: Check GTID mode indicators

cr0x@server:~$ mysql -NBe "SHOW VARIABLES LIKE '%gtid%';" | head
gtid_domain_id	0
gtid_strict_mode	ON
gtid_binlog_pos	0-1-12345

What it means: These variables are MariaDB-flavored GTID indicators (domain/server/sequence style).

Decision: If you’re moving to/from MySQL/Percona GTID, plan for GTID translation or a topology reset. Don’t wing it during a failover event.

Task 8: Spot replication lag and the reason (IO vs SQL thread)

cr0x@server:~$ mysql -e "SHOW SLAVE STATUS\G" | egrep "Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master|Last_SQL_Error|Retrieved_Gtid_Set|Executed_Gtid_Set" -n
3:Slave_IO_Running: Yes
4:Slave_SQL_Running: Yes
32:Seconds_Behind_Master: 18
48:Last_SQL_Error:
78:Retrieved_Gtid_Set:
79:Executed_Gtid_Set:

What it means: If IO and SQL threads run but lag increases, apply is slow or workload spikes. Error fields help detect incompatibilities.

Decision: If lag is persistent post-migration, inspect disk IO and query patterns on replicas; consider parallel replication settings appropriate to your engine/version.

Task 9: Capture top waits quickly (InnoDB mutex/lock pressure proxy)

cr0x@server:~$ mysql -NBe "SHOW GLOBAL STATUS LIKE 'Innodb_row_lock%';"
Innodb_row_lock_current_waits	3
Innodb_row_lock_time	89123
Innodb_row_lock_time_avg	1123
Innodb_row_lock_time_max	9000
Innodb_row_lock_waits	79

What it means: Rising waits/time indicate contention, often from plan changes or long transactions.

Decision: If this jumped after migration, find the blocking transactions and compare execution plans for the hot tables.

Task 10: Identify the longest running transactions

cr0x@server:~$ mysql -e "SELECT trx_id, trx_started, trx_mysql_thread_id, trx_rows_locked, trx_rows_modified FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 5;"
+--------+---------------------+--------------------+----------------+------------------+
| trx_id | trx_started         | trx_mysql_thread_id| trx_rows_locked| trx_rows_modified|
+--------+---------------------+--------------------+----------------+------------------+
| 123ABC | 2025-12-30 01:12:09 | 9821               | 44012          | 12               |
+--------+---------------------+--------------------+----------------+------------------+

What it means: Long transactions hold locks and inflate undo/redo work.

Decision: If you see long-lived transactions post-migration, hunt the application code path or batch job. Sometimes a changed plan makes a transaction take 10× longer and everything else looks “mysteriously locked.”

Task 11: Compare query plans for a known hot query

cr0x@server:~$ mysql -e "EXPLAIN SELECT * FROM orders WHERE customer_id=123 AND status='OPEN' ORDER BY created_at DESC LIMIT 50;"
+----+-------------+--------+------+------------------------+--------------------+---------+-------+------+-----------------------------+
| id | select_type | table  | type | possible_keys          | key                | key_len | ref   | rows | Extra                       |
+----+-------------+--------+------+------------------------+--------------------+---------+-------+------+-----------------------------+
|  1 | SIMPLE      | orders | ref  | idx_customer_status_dt | idx_customer_status_dt | 8   | const | 120  | Using where; Using filesort |
+----+-------------+--------+------+------------------------+--------------------+---------+-------+------+-----------------------------+

What it means: “Using filesort” might be fine—or it might be your new bottleneck if it wasn’t there before.

Decision: If plan changed, consider a covering index that supports the ORDER BY. Validate with real latency and rows examined, not just EXPLAIN aesthetics.

Task 12: Check temporary table behavior and spills

cr0x@server:~$ mysql -NBe "SHOW GLOBAL STATUS LIKE 'Created_tmp%';"
Created_tmp_disk_tables	12409
Created_tmp_tables	70211
Created_tmp_files	88

What it means: Disk temp tables and tmp files often correlate with sudden slowdowns after optimizer changes.

Decision: If disk temp tables spike after migration, focus on query plans and indexes first. Only then consider temp table sizing changes.

Task 13: Confirm character set and collation defaults

cr0x@server:~$ mysql -NBe "SHOW VARIABLES WHERE Variable_name IN ('character_set_server','collation_server');"
character_set_server	utf8mb4
collation_server	utf8mb4_general_ci

What it means: Collation changes can break uniqueness assumptions and index usage.

Decision: If defaults differ from your baseline, set them explicitly and verify app expectations (especially around sorting and case sensitivity).

Task 14: Validate storage and filesystem IO latency (host-side reality)

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server) 	12/30/2025 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          32.10    0.00    6.20    7.80    0.00   53.90

Device            r/s     w/s   r_await   w_await   aqu-sz  %util
nvme0n1         220.0   480.0     2.10     8.70     4.20   92.0

What it means: High w_await and %util point to write pressure. Migrations often change write patterns (different redo/log behavior, different temp table usage).

Decision: If storage is saturated, stop “database tuning” and fix IO capacity or reduce write amplification (query/index fixes, batching, flush settings only with durability awareness).

Task 15: Quick check for filesystem mount options that sabotage databases

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS /var/lib/mysql
/var/lib/mysql ext4 rw,relatime

What it means: Some mount options can impact latency. relatime is generally fine; other options (or exotic setups) may not be.

Decision: If you see surprising options (or network filesystems), treat that as a primary suspect for performance and durability issues.

Task 16: Validate backup tool version and server version alignment

cr0x@server:~$ xtrabackup --version
xtrabackup version 8.0.35 based on MySQL server 8.0.35 Linux (x86_64)

What it means: Backup tools advertise their compatibility target. Mismatch is a restore failure waiting to happen.

Decision: Pin the tool version to what you run. If you’re on MariaDB, prefer mariabackup aligned to that MariaDB major line.

Checklists / plan étape par étape

Plan A : Vous voulez Percona Server parce que vous avez besoin d’une compatibilité MySQL vraie

1. Inventoriez les attentes applicatives : matrice de support du fournisseur, fonctionnalités SQL utilisées (JSON, fonctions fenêtres, colonnes générées), et versions des bibliothèques clientes.
2. Standardisez le SQL mode et l’encodage : définissez des valeurs explicites ; n’héritez pas des valeurs par défaut.
3. Décision sur le modèle de réplication : choisissez la sémantique GTID et tenez-vous-y. Ne mélangez pas GTID MariaDB avec GTID MySQL en état stable.
4. Audit d’outillage : exporters de monitoring, scripts de sauvegarde, automatisation de basculement, outils de migration de schéma — testez-les sur le moteur cible.
5. Baseline performance : capturez les requêtes principales, latence p95/p99, lignes examinées, taux de tables temporaires, taux de hit du buffer pool.
6. Restauration à blanc : effectuez une restauration complète depuis des sauvegardes dans un environnement isolé et exécutez des checks de cohérence.
7. Coupe progressive : écriture duale si vous pouvez le justifier ; sinon utilisez la promotion de réplique et un rollback répété et rodé.

Plan B : Vous voulez MariaDB parce que vous vous engagez dans son écosystème

1. Cessez de l’appeler « MySQL » en interne : marquez-le MariaDB dans les runbooks et tableaux de bord. Ça réduit les mauvaises hypothèses.
2. Confirmez l’usage des fonctionnalités : si vous dépendez de sémantiques spécifiques à MySQL 8, soyez prudent. Testez la version exacte de MariaDB que vous exécuterez.
3. Adoptez l’outillage natif MariaDB : surtout pour la sauvegarde/restauration et l’automatisation basée sur GTID.
4. Validez l’utilisation de JSON : vérifiez les types de colonnes et les attentes d’indexation ; n’assumez pas le comportement JSON natif si vous venez de MySQL.
5. Retunez pour votre stockage : en particulier le comportement des tables temporaires et les schémas de flush ; ne portez pas les configs comme si c’étaient des variables d’environnement de conteneur.
6. Répétition du basculement : simulez la perte d’un nœud, la promotion et la réintégration. Faites-le deux fois : une fois au calme, une fois sous charge.

Critères d’acceptation minimaux « sans surprises » pour une migration

• Vous pouvez restaurer sur un nouvel hôte et démarrer le serveur proprement.
• Le basculement fonctionne et les répliques se réattachent sans chirurgie manuelle.
• Les 20 requêtes principales ont des plans stables et une latence tail acceptable.
• Le monitoring et les alertes fonctionnent sans bruit « unknown variable ».
• L’authentification client et TLS fonctionnent pour toutes les variantes de clients en production.

FAQ

1) Percona Server est-il un remplacement drop-in pour MySQL ?

Généralement, oui — dans la même ligne majeure MySQL — parce qu’il suit de près MySQL en amont. Validez tout de même les plugins, les valeurs par défaut et l’outillage de sauvegarde.

2) MariaDB est-elle un remplacement drop-in pour MySQL ?

Parfois pour des applications basiques, mais c’est plus risqué au fur et à mesure que MySQL évolue. Si vous avez besoin du « comportement MySQL 8 », traitez MariaDB comme une base différente et testez en conséquence.

3) MariaDB est-elle un remplacement drop-in pour Percona Server ?

Pas de façon fiable. Le protocole peut fonctionner, mais le GTID, les tables système, les plugins et le comportement de l’optimiseur peuvent diverger suffisamment pour casser l’automatisation et les attentes de performance.

4) Puis-je répliquer de Percona Server vers MariaDB (ou l’inverse) ?

Parfois vous pouvez le faire comme pont temporaire avec des contraintes strictes (format de binlog, SQL supporté, planification GTID prudente). N’assumez pas que c’est sûr à long terme sans validation explicite.

5) Quel est le piège caché le plus important dans les migrations MariaDB ↔ Percona ?

Le GTID et la sémantique de basculement. Ce n’est pas le SQL. C’est ce qui arrive à 2h du matin quand un nœud meurt et que votre automatisation fait des hypothèses.

6) Dois-je copier mon tuning my.cnf de l’un à l’autre ?

Non. Commencez depuis une baseline conservatrice et ne portez que les paramètres que vous comprenez. Ensuite tunez avec des mesures. La copie aveugle est la cause des stalls périodiques et du « c’était bien avant ».

7) Lequel est plus rapide ?

Mauvaise question. La base la plus rapide est celle où vos requêtes chaudes utilisent de bons plans et où votre IO n’est pas saturé. N’importe quel moteur peut gagner ou perdre selon la charge et le tuning.

8) Ai-je besoin d’un outillage de sauvegarde différent ?

Oui, prévoyez-le. Utilisez l’outillage aligné à votre famille de serveurs et à votre version. Et faites des répétitions de restauration — car les affirmations de compatibilité ne restaurent pas les données.

9) Comment choisir si mon fournisseur ne supporte que « MySQL » ?

Demandez ce qu’il entend par MySQL : version, attentes sur le plugin d’auth, usage de GTID, attentes de sauvegarde. S’ils testent contre Oracle MySQL 8, Percona Server pour MySQL 8 est habituellement le choix le plus sûr.

10) Puis-je éviter ces problèmes en utilisant des conteneurs et Kubernetes ?

Non. Les conteneurs sont excellents pour empaqueter des surprises de façon cohérente. Vous avez toujours besoin de compatibilité comportementale, de sauvegardes testées, et de basculement répété.

Prochaines étapes réalisables cette semaine

1. Exécutez les tâches pratiques sur votre flotte actuelle et notez les résultats : version, SQL mode, plugins d’auth, format de binlog, variables GTID.
2. Choisissez une cible de compatibilité unique : « sémantiques MySQL 8 » (penchez Percona) ou « sémantiques MariaDB » (engagez-vous envers MariaDB). Arrêtez d’espérer obtenir les deux gratuitement.
3. Faites un exercice de restauration sur un hôte isolé et prouvez que le serveur démarre et que l’application peut exécuter une petite charge.
4. Répétez le basculement en staging avec la même automatisation que vous utiliserez en production. Si vous n’avez pas d’automatisation, votre premier basculement sera une expérience en direct.
5. Basez-vous et comparez les plans pour vos requêtes principales. Si vous trouvez des régressions, corrigez les requêtes et les index avant de toucher aux « boutons de tuning ».

Si vous voulez une règle simple : Percona Server est généralement le choix « MySQL-compatible » le plus sûr ; MariaDB est une base solide si vous la traitez comme MariaDB et cessez de prétendre que c’est MySQL avec un logo différent.