MariaDB vs RDS MariaDB : Qui réserve le moins de surprises de compatibilité ?

La thèse : lequel vous surprendra le moins

Si vous voulez moins de surprises de compatibilité, la réponse dépend de ce que vous entendez par « compatibilité ».
Si vous entendez « la base de données se comporte exactement comme mon dernier serveur », MariaDB autogéré gagne — parce que vous contrôlez l’environnement entier.
Même paquets, même système de fichiers, mêmes plugins, mêmes scripts d’init, même noyau, mêmes réglages.

Si vous entendez « elle continue de tourner malgré les montées de version, les pannes matérielles et les sauvegardes sans que je doive inventer une nouvelle religion », RDS MariaDB
vous surprendra moins opérationnellement, car c’est un produit avec des garde-fous. Mais ces garde-fous forment eux-mêmes une surface de compatibilité :
groupes de paramètres, plugins restreints, comportement de stockage géré, mises à niveau gérées, privilèges SUPER restreints, et une approche différente de l’observabilité et de la récupération après crash.

Orientation pratique :

• Choisissez MariaDB autogéré lorsque votre charge dépend de plugins spécifiques, du comportement du système de fichiers,
  de builds personnalisés ou d’un réglage précis (et que vous avez des experts de garde capables de le maintenir).
• Choisissez RDS MariaDB lorsque votre douleur est principalement l’ennui opérationnel (patchs, sauvegardes, basculements, stockage),
  et que votre application est disciplinée sur le comportement SQL, les migrations et les tests.

Les surprises de compatibilité ne sont pas aléatoires. Elles se regroupent autour des privilèges, des plugins, des modes SQL, des réglages de réplication,
des valeurs par défaut de jeu de caractères/collation, et de l’infrastructure « invisible » : stockage, limites d’E/S et événements de maintenance.

Ce que « compatibilité » signifie vraiment en production

La compatibilité n’est pas seulement « est-ce que ça démarre » ou « est-ce que le schéma se charge ». Dans des systèmes réels, vous découvrez que vous n’étiez pas compatible quand :
des requêtes renvoient des résultats subtilement différents, la réplication diverge, une migration bloque sur des verrous de métadonnées, une nouvelle construction d’index fait exploser les I/O,
ou un correctif de sécurité change le comportement d’authentification et la moitié de vos clients s’écroule.

Je répartis les surprises de compatibilité en cinq catégories :

1. Sémantique SQL : modes SQL, changements d’optimiseur, collations par défaut, comportement JSON, fonctions fenêtrées, conversions limites.
2. Modèle de privilèges : équivalents SUPER, objets DEFINER, administration de réplication, installation de plugins, accès aux fichiers.
3. Fonctionnalités serveur : plugins, audit, chiffrement, hooks de sauvegarde, réglages de performance_schema.
4. Couplage infrastructurel : sous-système de stockage, comportement de fsync, plafonds IOPS, gigue réseau, comportement de basculement.
5. Événements de cycle de vie : montées de version, releases mineures, dérive des paramètres, fenêtres de maintenance, basculements automatisés.

La réalité brute : RDS MariaDB est « MariaDB avec un emballage produit ». MariaDB autogéré est « MariaDB avec ce que vous avez construit autour ».
Vos surprises viennent de l’emballage ou de votre propre code de colle — choisissez votre poison.

Contexte historique et faits qui expliquent les bizarreries d’aujourd’hui

Les surprises de compatibilité semblent personnelles jusqu’à ce que vous vous rappeliez les 15 dernières années de drames familiaux des bases de données et de décisions produit cloud.
Quelques faits concrets aident à prédire ce qui cassera avant que ça ne casse.

• Fait 1 : MariaDB a forké MySQL après qu’Oracle ait acquis Sun. Ce fork a créé une réalité « principalement compatible, jusqu’à ce que ce ne soit plus le cas ».
• Fait 2 : Les numéros de version MariaDB ne se mappent pas proprement à la chronologie des fonctionnalités de MySQL. « 10.x » n’est pas « MySQL 10 ». C’est sa propre lignée.
• Fait 3 : MariaDB a intégré au fil du temps des moteurs et des fonctionnalités alternatifs (par ex. Aria, travaux différents sur l’optimiseur). Cela compte pour les cas limites et les performances.
• Fait 4 : AWS RDS n’est pas une VM dans laquelle vous avez root. C’est un service managé avec un ensemble sélectionné de paramètres et de plugins supportés.
• Fait 5 : RDS a un « master » spécial qui ressemble à root mais ne l’est pas ; certains privilèges et opérations système sont intentionnellement bloqués.
• Fait 6 : MySQL 8 a changé l’authentification par défaut et les collations d’une façon qui a appris à toute l’industrie : « les valeurs par défaut sont des breaking changes déguisés ». MariaDB a ses propres changements de défauts à travers les versions majeures.
• Fait 7 : Le stockage RDS est abstrait ; vos performances E/S sont gouvernées par les types de volumes EBS, la provision d’IOPS, le comportement de burst et les voisins bruyants — pas votre carte RAID favorite.
• Fait 8 : Dans les services gérés, les patches de version mineure peuvent inclure des changements de comportement que vous n’avez pas demandés, parce que les correctifs de sécurité et de stabilité sont publiés quand AWS les certifie.
• Fait 9 : La réplication MariaDB a plusieurs modes et variantes de GTID ; mélanger les saveurs entre environnements peut créer des bizarreries de réplication qui ressemblent à de la corruption mais sont en réalité une dérive de configuration.

Une citation qui reste pertinente, parce que les bases de données ne sont que des systèmes distribués déguisés :
Espérer n’est pas une stratégie. —General Gordon R. Sullivan

D’où viennent les surprises de compatibilité (catégories réelles)

1) Privilèges : l’illusion « je suis root »

Sur MariaDB autogéré, si vous avez le root sur la machine et un utilisateur avec tous les privilèges, vous pouvez généralement tout faire :
installer des plugins, lire/écrire des fichiers pour LOAD DATA INFILE, définir des variables globales, tripoter les internals de réplication.

Sur RDS MariaDB, l’utilisateur master est puissant mais pas omnipotent. AWS bloque certaines opérations parce que des clients partageant
une infrastructure managée ne doivent pas pouvoir briquer l’hôte ou exfiltrer les données d’autres locataires. Vous verrez des erreurs comme :
« Access denied; you need (at least one of) the SUPER privilege » ou « File not found » alors même que le fichier « existe » dans votre tête.

2) Plugins : votre plugin préféré est l’incident de quelqu’un d’autre

MariaDB autogéré vous permet d’exécuter ce que vous voulez : plugins d’audit, plugins d’authentification personnalisés, helpers de sauvegarde/restauration,
instrumentation de performance supplémentaire.

RDS supporte un sous-ensemble. Ce sous-ensemble varie selon la version du moteur et la certification d’AWS. Si votre plan de compatibilité inclut
« il suffit d’installer le plugin », ce plan n’est pas un plan.

Blague n°1 (courte, pertinente) : Le cloud vous donne des petites roues, puis vous facture à l’heure le privilège de ne pas les retirer.

3) Modes SQL, collations et requêtes « ça marche sur mon laptop »

La plupart des explosions de compatibilité sont auto-infligées. Des valeurs par défaut différentes pour sql_mode, character_set_server
et collation_server peuvent transformer un comportement de développement permissif en échecs stricts en production — ou pire, en troncations silencieuses et
en différences de tri.

RDS peut être livré avec des valeurs par défaut différentes de vos paquets sur site. Et même si les valeurs par défaut sont identiques aujourd’hui, une montée de version du moteur peut les modifier.
Les environnements autogérés montent aussi en version, mais vous contrôlez généralement le moment et la validation de build autour de cela.

4) Sémantique de stockage : IOPS, fsync et la physique avec laquelle on ne négocie pas

Si vous exécutez MariaDB sur vos propres hôtes, vous contrôlez la disposition des disques sous-jacents, le système de fichiers, les options de montage,
la politique de cache RAID et si vos réglages de « durabilité » vous mentent. Vous possédez aussi les conséquences.

RDS tourne sur un stockage managé. Vous pouvez choisir des classes de volume et des IOPS, mais vous ne pouvez pas tuner le noyau hôte ou les profondeurs de file d’attente du stockage.
Les surprises de compatibilité apparaissent comme « même plan de requête, latence différente », ou « le comportement de checkpoint a changé après une montée en capacité ».

5) Maintenance et basculement : des événements planifiés qui se comportent comme des événements non planifiés

RDS fait de la maintenance. Parfois vous choisissez la fenêtre ; parfois AWS la choisit pour vous si vous êtes en retard sur les patchs de sécurité.
Vous vivez aussi avec la sémantique de basculement : coupures de connexion, changements DNS, et une petite fenêtre où votre appli se reconnecte correctement ou brûle.

L’autogéré peut être plus lisse si vous implémentez bien votre propre orchestration de basculement et de reconnexion. Ou cela peut être un projet artistique chaotique.

MariaDB autogéré : moins de garde-fous, moins de contraintes invisibles

Le profil de compatibilité de MariaDB autogéré est « ce que vous construisez est ce que vous obtenez ». C’est à la fois le meilleur et le pire.
Si votre application attend un ensemble précis de comportements — plugins personnalisés, certains schémas d’accès au système de fichiers, une configuration InnoDB réglée,
ou une topologie de réplication stricte — vous pouvez le réaliser.

Où l’autogéré a tendance à moins vous surprendre

• Disponibilité des plugins : vous pouvez installer ce dont vous avez besoin, le tester et figer les versions.
• Accès au système de fichiers : LOAD DATA INFILE, SELECT ... INTO OUTFILE et les workflows basés sur des fichiers locaux se comportent de manière prévisible.
• Réglages au niveau OS : paramètres THP, swappiness, ordonnanceur I/O, options de montage, pinning NUMA — tout cela peut compter pour des charges limites.
• Contrôle exact des versions : vous pouvez retenir des mises à jour « mineures » qui changeraient le comportement tant que vous n’avez pas validé.

Où les surprises en autogéré sont pires

Vous construisez vous-même le filet de sécurité : sauvegardes, PITR, tests de snapshot, exercices de basculement, couverture de monitoring.
Quand ça casse, ça casse un week-end. De plus, vous assumez les parties difficiles que les équipes sous-financent : remplacement de disque, bugs de firmware,
et « d’une manière ou d’une autre le système de fichiers est devenu en lecture seule ».

La surprise de compatibilité ici est souvent organisationnelle : les équipes supposent qu’une base de données est une « installation de paquet », pas un système opérationnel.
Cette supposition tient jusqu’au moment où elle ne tient plus.

RDS MariaDB : fiabilité gérée avec contraintes gérées

RDS MariaDB s’adresse aux équipes qui préfèrent arrêter de jouer le rôle du fournisseur de stockage. Sauvegardes, patching automatisé, intégration de monitoring
et basculement sont inclus. Cela élimine des classes entières de défaillances opérationnelles.

Où RDS vous surprend moins

• Flux de sauvegarde et restauration : la réalité basée sur des snapshots est cohérente et testée à l’échelle.
• Pannes matérielles et stockage : ce sont des problèmes d’AWS (même si votre outage reste votre problème).
• Monitoring de base : les métriques CloudWatch et les événements RDS vous donnent des signaux même si votre propre pile est mince.
• Gestion standardisée des paramètres : moins de configurations éditées à la main qui dérivent entre hôtes.

Où les surprises RDS sont plus fréquentes

• Privilèges : pas de vrai SUPER, pas d’accès OS, système de fichiers contrôlé.
• Plugins : « supporté » est une décision produit, pas une possibilité technique.
• Sémantique des paramètres : certaines variables sont dynamiques, d’autres nécessitent un redémarrage, certaines sont verrouillées ; parfois le nom existe mais se comporte différemment.
• Réalité des IOPS : la base n’est pas lente, le stockage est occupé — ou plafonné — ou à court de crédits.
• Mises à niveau : les montées de version peuvent être plus lisses, mais elles peuvent encore changer le comportement de l’optimiseur, les valeurs par défaut ou les sémantiques de cas limites.

Blague n°2 (courte, pertinente) : Rien ne vous fait apprécier les sauvegardes managées comme réaliser que votre « serveur de sauvegarde » est aussi l’hôte Minecraft du stagiaire.

Matrice de compatibilité : ce qui diffère le plus souvent

Compatibilité d’authentification et clients

La plupart des cassures côté client ne sont pas exotiques. Ce sont des connecteurs anciens, des réglages TLS, ou des valeurs par défaut d’authentification.
L’autogéré vous permet d’égaliser exactement votre ancien environnement ; RDS vous pousse vers les bases sécurisées préférées d’AWS, parfois plus rapidement que vos mises à jour d’application.

Règle de décision : si vous avez des clients legacy que vous ne pouvez pas mettre à jour rapidement, l’autogéré vous achète du temps. Si vous pouvez mettre à jour les clients et imposer TLS,
RDS réduit généralement le risque à long terme.

Réplication et saveur GTID

Le GTID de MariaDB n’est pas le GTID de MySQL. Et « compatible réplication » n’est pas la même chose que « identique en réplication ». Lors d’un déplacement entre
environnements, vous devez verrouiller : binlog_format, gtid_domain_id, gtid_strict_mode, sémantique row vs statement, et la façon dont vos outils lisent les positions.

RDS supporte des fonctionnalités de réplication, mais vous les pilotez via l’API et des procédures stockées plutôt que par un accès OS complet.
La forme du workflow opérationnel change, et les surprises viennent plus de ce changement que de MariaDB lui-même.

Modes SQL et strictesse

Les modes SQL stricts sont vos amis si vous aimez les données correctes. Ils sont vos ennemis si votre application reposait sur un comportement indéfini,
des troncations silencieuses ou des raccourcis de « group by ». La surprise n’est pas que le mode strict casse des choses ; c’est que le mode permissif ait jamais fonctionné.

Fuseaux horaires, locales et « hier ça allait »

Les instances RDS tournent sur des images OS gérées. Vos hôtes autogérés peuvent avoir un tzdata personnalisé ou un processus de chargement des tables de fuseaux horaires différent.
Les migrations qui touchent aux timestamps ou conversions de dates sont là où cela mord.

Caractéristiques de performance du stockage

En autogéré, vous pouvez surprovisionner la RAM, pinner des buffers, strier des disques et tuner la pile I/O. Sur RDS, vous achetez une classe d’instance
et un profil de volume. Les deux peuvent fonctionner ; les deux peuvent vous surprendre.

Le motif de surprise est constant : les charges de travail qui sont en rafales ou ont de gros bursts de checkpoint ont tendance à se comporter différemment selon les backends de stockage.
Si votre système est sensible à la latence de queue, testez sous charge, pas « smoke test avec cinq utilisateurs ».

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : Un incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a décidé de déplacer une charge de reporting de MariaDB autogéré vers RDS MariaDB. C’était « non critique ».
C’est ce que les gens disent juste avant que ça devienne critique.

Ils avaient un pipeline qui préparait des CSV sur l’hôte de base de données et utilisait LOAD DATA INFILE pour charger en masse dans des tables de staging.
Sur leurs propres serveurs, le processus de chargement écrivait dans un répertoire connu, et l’utilisateur DB avait le privilège FILE. C’était ennuyeux.

Sur RDS, la même approche s’est heurtée à un mur : la base ne pouvait pas lire des chemins arbitraires du système de fichiers hôte, et le « master user »
ne se comportait pas comme root. Ils ont essayé de forcer la main avec des grants et n’ont abouti à rien. Pendant ce temps, les tables de reporting ont pris du retard,
les tableaux de bord ont menti, et l’équipe commerciale a découvert que la « prise de décision basée sur les données » était surtout une impression.

La solution n’était pas brillante. Ils ont changé le mécanisme de chargement vers une voie supportée : importer côté application avec des inserts par lots
et des tailles de transaction raisonnables, puis ont refondu en job ETL qui déposait les données dans un stockage objet et chargeait via un workflow supporté.
La leçon n’était pas « RDS est mauvais ». La leçon était : si votre ingestion dépend de sémantiques fichiers OS, vous devez la redessiner avant de migrer.

Mini-récit 2 : Une optimisation qui s’est retournée contre eux

Une équipe fintech exécutait MariaDB sur RDS et a remarqué des pics de latence d’écriture occasionnels. Quelqu’un a suggéré d’augmenter le parallélisme en
lançant plus d’écrivains concurrents et en relevant plusieurs paramètres InnoDB dans le parameter group. Les graphiques ont paru meilleurs pendant un jour.

Puis les pics se sont aggravés, et un job nocturne a commencé à expirer. Qu’est-ce qui avait changé ? Le comportement de checkpointing et de flush en arrière-plan est devenu
plus bursty avec les nouveaux réglages, et le volume de stockage était déjà proche de son plafond IOPS réaliste pendant les pics.
Au lieu d’atténuer, ils ont amplifié la contention.

Leur postmortem a trouvé un piège classique : ils ont optimisé la base comme si elle tournait sur NVMe local dédié, alors qu’elle était sur un stockage réseau managé.
Les mêmes réglages peuvent se comporter différemment. De plus, ils n’ont pas testé le changement à une concurrence réaliste, juste « ça marche en staging ».
Le staging avait moins de données, moins d’index et aucun des vrais patterns de trafic.

La correction a été de revenir sur les réglages les plus agressifs, provisionner un stockage avec IOPS cohérents, et réduire la rafale d’écrivains
en changeant le batching applicatif et en isolant le job nocturne dans une fenêtre avec moins d’écritures concurrentes. Le « tuning DB » le plus efficace
a été en réalité la mise en forme de la charge.

Mini-récit 3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande plateforme B2B exploitait une flotte mixte : du MariaDB autogéré pour des charges spécialisées, et du RDS MariaDB pour la plupart des systèmes transactionnels.
Leur arme secrète n’était pas une architecture sophistiquée. C’était la discipline.

Chaque migration de schéma passait par un harnais de compatibilité : la migration s’exécutait contre deux environnements — un build autogéré « le plus proche possible »
et une instance RDS de test — puis exécutaient une suite de plans d’exécution et de vérifications de correction. Ils comparaient les sorties EXPLAIN,
vérifiaient la dérive de collation, et exécutaient une relecture minimale des requêtes de production.

Une semaine, une mise à jour mineure du moteur dans l’environnement de test RDS a changé le plan d’optimiseur pour une requête qui utilisait un index composite plus une condition de plage.
Ce n’était pas incorrect, juste plus lent. Le harnais l’a détecté, ils ont ajouté un index ciblé, et ont retardé la montée de version jusqu’à ce que le correctif soit appliqué.
La production n’a jamais vu la régression.

Personne n’a été promu pour « les tests ont tourné et rien n’a explosé ». Mais la rotation de garde est restée humaine, et c’est un meilleur KPI que ce que la plupart des entreprises méritent.

Diagnostics pratiques : commandes, sorties et décisions (12+)

Voici le type de vérifications que j’exécute réellement quand quelqu’un dit « RDS MariaDB se comporte bizarrement » ou « l’autogéré marche mais le cloud est maudit ».
Chaque tâche inclut : une commande, ce que la sortie signifie, et la décision que vous en tirez.

Tâche 1 : Identifier la version du moteur et la distribution

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SELECT VERSION(), @@version_comment;"
Enter password:
+---------------------+----------------------------------+
| VERSION()           | @@version_comment                |
+---------------------+----------------------------------+
| 10.6.16-MariaDB     | MariaDB Server                   |
+---------------------+----------------------------------+

Sens : Vous êtes sur MariaDB 10.6.x. @@version_comment aide à distinguer les builds fournisseur.
Sur RDS vous verrez souvent un commentaire à la sauce AWS.

Décision : Construisez une matrice de compatibilité autour du majeur/mineur exact. Ne discutez pas du « 10.6-ish ».

Tâche 2 : Vérifier la dérive de sql_mode

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SELECT @@GLOBAL.sql_mode, @@SESSION.sql_mode\G"
Enter password:
*************************** 1. row ***************************
@@GLOBAL.sql_mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
@@SESSION.sql_mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

Sens : Le mode strict est activé globalement et en session. Si le dev diffère, vous aurez des insertions « ça marche en dev ».

Décision : Alignez dev/test/prod sql_mode ; considérez les divergences comme un blocage de release.

Tâche 3 : Vérifier le charset/collation par défaut (les bugs silencieux vivent ici)

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SHOW VARIABLES LIKE 'character_set_%'; SHOW VARIABLES LIKE 'collation_%';"
Enter password:
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| character_set_client     | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database   | utf8mb4 |
| character_set_results    | utf8mb4 |
| character_set_server     | utf8mb4 |
| character_set_system     | utf8    |
+--------------------------+---------+
+----------------------+--------------------+
| Variable_name        | Value              |
+----------------------+--------------------+
| collation_connection | utf8mb4_general_ci |
| collation_database   | utf8mb4_general_ci |
| collation_server     | utf8mb4_general_ci |
+----------------------+--------------------+

Sens : Vous êtes en utf8mb4 avec une collation spécifique. Le tri et les comparaisons peuvent différer selon les collations.

Décision : Figez charset/collation au niveau du schéma et de la connexion ; ne comptez pas sur les défauts serveur.

Tâche 4 : Détecter les privilèges restreints (commun sur RDS)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GRANTS FOR CURRENT_USER();"
Enter password:
+--------------------------------------------------------------------------------------------------+
| Grants for admin@%                                                                                |
+--------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER... |
+--------------------------------------------------------------------------------------------------+

Sens : Vous voyez ce que vous avez réellement, pas ce que vous supposez avoir. L’absence de pouvoirs de type SUPER compte.

Décision : Si votre runbook requiert SUPER, réécrivez-le pour les workflows RDS (groupes de paramètres, procédures, API).

Tâche 5 : Confirmer le format de binlog et les paramètres critiques de réplication

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format'; SHOW VARIABLES LIKE 'server_id';"
Enter password:
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 12345 |
+---------------+-------+

Sens : Le binlogging est activé, le format est ROW (généralement le plus sûr pour la compatibilité), et server_id est défini.

Décision : Si vous migrez des topologies de réplication, standardisez sur ROW sauf si vous avez une raison forte de ne pas le faire.

Tâche 6 : Identifier les longues transactions et la contention de verrous

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW FULL PROCESSLIST;"
Enter password:
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+
| Id | User | Host              | db   | Command | Time | State                | Info                                      |
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+
| 88 | app  | 10.0.1.22:51344   | prod | Query   | 312  | Waiting for metadata | ALTER TABLE orders ADD COLUMN foo INT     |
| 91 | app  | 10.0.2.18:60112   | prod | Query   | 305  | Sending data         | SELECT ... FROM orders JOIN ...           |
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+

Sens : DDL en attente de verrous de métadonnées pendant que des requêtes longues tournent. Ça ressemble à un « migration bloquée ».

Décision : Tuez le blocant ou replanifiez les migrations ; implémentez des outils de changement de schéma en ligne pour les grandes tables.

Tâche 7 : Vérifier l’état du moteur InnoDB pour deadlocks et pression de flush

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,120p'
Enter password:
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2025-12-30 10:12:41 0x7f8c1c1
LATEST DETECTED DEADLOCK
------------------------
...snip...
LOG
---
Log sequence number          8876543210
Log flushed up to            8876543210
Last checkpoint at           8876400000
0 pending log flushes, 0 pending chkp writes

Sens : Les deadlocks et l’état des checkpoints vous disent si vous êtes lié par les I/O ou par les verrous.

Décision : Si les checkpoints accusent du retard et que les flushs en attente augmentent, concentrez-vous sur le stockage/IOPS et les schémas d’écriture — pas seulement l’optimisation des requêtes.

Tâche 8 : Trouver les principaux waits et statements (Performance Schema)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 AS seconds_waited FROM performance_schema.events_waits_summary_global_by_event_name ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;"
Enter password:
+----------------------------------------+------------+----------------+
| EVENT_NAME                             | COUNT_STAR | seconds_waited |
+----------------------------------------+------------+----------------+
| wait/io/file/innodb/innodb_data_file   |   18233412 |          913.2 |
| wait/io/file/innodb/innodb_log_file    |    8234411 |          402.7 |
| wait/synch/mutex/innodb/buf_pool_mutex |    2234410 |          188.5 |
| wait/lock/table/sql/handler            |     834411 |           72.1 |
| wait/synch/mutex/sql/LOCK_open         |     244110 |           41.0 |
+----------------------------------------+------------+----------------+

Sens : Des waits I/O lourds suggèrent un goulot d’E/S ; des waits de mutex suggèrent une contention interne.

Décision : Si l’I/O domine, arrêtez de changer bêtement les index ; augmentez les IOPS ou réduisez l’amplification d’écriture d’abord.

Tâche 9 : Valider les paramètres qui diffèrent souvent entre environnements

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_flush_log_at_trx_commit','sync_binlog','innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size');"
Enter password:
+--------------------------------+------------+
| Variable_name                  | Value      |
+--------------------------------+------------+
| innodb_buffer_pool_size        | 17179869184|
| innodb_flush_log_at_trx_commit | 1          |
| max_connections                | 2000       |
| max_heap_table_size            | 67108864   |
| sync_binlog                    | 1          |
| tmp_table_size                 | 67108864   |
+--------------------------------+------------+

Sens : Les réglages de durabilité à 1/1 sont plus sûrs mais peuvent être plus lents sur un I/O contraint. Les tailles de tables temporaires affectent les spills disque.

Décision : Ne « optimisez » pas la durabilité pour la performance à moins d’être prêt à expliquer une perte de données à la direction.

Tâche 10 : Repérer les spills de tables temporaires (plans de requêtes qui se comportent différemment)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Created_tmp%tables';"
Enter password:
+-------------------------+--------+
| Variable_name           | Value  |
+-------------------------+--------+
| Created_tmp_disk_tables | 123456 |
| Created_tmp_files       | 8421   |
| Created_tmp_tables      | 987654 |
+-------------------------+--------+

Sens : Un grand nombre de tables temporaires sur disque signifie que des requêtes déversent sur disque — souvent à cause d’opérations de tri/group et de tailles tmp insuffisantes.

Décision : Optimisez les requêtes et les index ; augmentez les tailles temporaires avec précaution ; vérifiez que le stockage peut gérer les patterns de spill sur RDS.

Tâche 11 : Vérifier l’état du slow query logging (attraper les régressions)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'slow_query_log%'; SHOW VARIABLES LIKE 'long_query_time';"
Enter password:
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| slow_query_log      | ON    |
| slow_query_log_file | /rdsdbdata/log/slowquery/mysql-slowquery.log |
+---------------------+-------+
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 1.000 |
+-----------------+-------+

Sens : Le slow query log est activé, le seuil est 1s, le chemin de fichier indique un emplacement de stockage géré sur RDS.

Décision : Si vous êtes à l’aveugle, activez le slow logging en fenêtres non-critiques et échantillonnez ; ne devinez pas.

Tâche 12 : Vérifier le comportement des connexions et les connexions avortées

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Aborted_connects'; SHOW GLOBAL STATUS LIKE 'Threads_connected'; SHOW GLOBAL STATUS LIKE 'Max_used_connections';"
Enter password:
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_connects | 4821  |
+------------------+-------+
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 412   |
+-------------------+-------+
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 1987  |
+----------------------+-------+

Sens : Beaucoup de connexions avortées peuvent signifier dérive d’identifiants, mismatch TLS, tempêtes de connexions pendant un basculement, ou pression sur max_connections.

Décision : Si les connexions montent en flèche pendant des déploiements ou basculements, mettez en place du pooling de connexions et du backoff ; ne scalez pas max_connections en premier réflexe.

Tâche 13 : Confirmer les tables de fuseaux horaires et le fuseau serveur

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'time_zone'; SELECT CONVERT_TZ('2025-12-30 12:00:00','UTC','America/Los_Angeles') AS converted;"
Enter password:
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| time_zone     | SYSTEM |
+---------------+--------+
+---------------------+
| converted            |
+---------------------+
| 2025-12-30 04:00:00 |
+---------------------+

Sens : La conversion de fuseau fonctionne ; les tables sont chargées. Si CONVERT_TZ retourne NULL, vos tables de fuseau ne sont pas chargées.

Décision : Corrigez le chargement des tables tz en autogéré ; sur RDS, utilisez les procédures/chemins supportés et testez explicitement les calculs temporels.

Tâche 14 : Comparer les DEFINERs des objets de schéma (générateur de surprises de migration)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SELECT ROUTINE_SCHEMA, ROUTINE_NAME, DEFINER FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA='prod' LIMIT 5;"
Enter password:
+---------------+-------------------+----------------+
| ROUTINE_SCHEMA| ROUTINE_NAME      | DEFINER        |
+---------------+-------------------+----------------+
| prod          | refresh_rollups   | root@localhost |
| prod          | prune_sessions    | root@localhost |
| prod          | calc_tax          | app@%          |
| prod          | rebuild_summary   | root@localhost |
| prod          | rotate_partitions | dba@%          |
+---------------+-------------------+----------------+

Sens : Les routines définies par root@localhost poseront problème sur RDS et tout environnement où cet utilisateur n’existe pas.

Décision : Standardisez les utilisateurs DEFINER et reconstruisez les objets lors de la migration ; n’importe pas un dump à l’aveugle en espérant le meilleur.

Mode d’emploi pour un diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Quand la plainte est « surprise de compatibilité », les gens poursuivent souvent le mauvais lapin. Ce playbook vous amène rapidement au goulot.

Premier : confirmez que c’est réellement la même charge et les mêmes sémantiques

1. Dérive de version et de paramètres : comparez VERSION(), sql_mode, charset/collation, et les variables InnoDB clés.
   Si elles diffèrent, arrêtez. Vous déboguez deux bases de données différentes.
2. Vérifications privilèges et DEFINER : exécutez SHOW GRANTS et scannez les divergences de DEFINER. Si des privilèges manquants font échouer des outils, vous perdrez des heures à blâmer « RDS bizarre ».
3. Comportement client : contrôlez les erreurs de connexion et les réglages TLS. Les basculements exposent des clients fragiles plus qu’ils n’exposent des bugs DB.

Deuxième : décidez si c’est CPU-bound, I/O-bound, ou lock-bound

1. Lock-bound : processlist montre « Waiting for metadata lock », « Waiting for table lock », ou deadlocks dans InnoDB status.
2. I/O-bound : Performance Schema montre des waits fichier dominants ; InnoDB status montre du retard de checkpoint ou de la pression de flush ; les tables temporaires disque grimpent.
3. CPU-bound : les requêtes sont rapides individuellement mais la concurrence s’effondre ; la contention de mutex augmente ; les métriques CPU (hors DB) sont saturées.

Troisième : isolez si la différence vient du wrapper RDS ou du cœur MariaDB

1. Contraintes du wrapper : absence de SUPER, plugins non supportés, restrictions système de fichiers, limitations de parameter group.
2. Comportement du cœur : changements de plan d’optimiseur, sémantiques de collation, strictesse, différences de format de réplication.
3. Infrastructure : débit de stockage/caps IOPS, crédits de burst, voisins bruyants, événements de maintenance, basculements.

Si vous pouvez nommer lequel de ces trois seaux vous concerne en 20 minutes, vous êtes déjà en avance sur la plupart des « salles de guerre ».

Erreurs courantes : symptômes → cause racine → correctif

1) « Ça marchait en autogéré, RDS le rejette »

Symptômes : erreurs mentionnant SUPER, privilège FILE, échecs d’installation de plugin, ou incapacité à lire/écrire des fichiers locaux.

Cause racine : supposer que RDS est une VM avec accès root et privilèges complets.

Correctif : repensez les workflows pour éviter la dépendance au système de fichiers ; utilisez des patterns d’import/export supportés ; remplacez les opérations privilégiées par des groupes de paramètres et des mécanismes fournis par AWS.

2) « Même requête, ordre des résultats différent »

Symptômes : pagination instable, égalités ORDER BY fluctuantes, comportement de tri textuel différent.

Cause racine : différences de collation ou dépendance à un ordre non défini sans ORDER BY explicite.

Correctif : figez les collations explicitement ; ajoutez des colonnes ORDER BY déterministes ; stabilisez la pagination.

3) « La réplication a cassé pendant la migration »

Symptômes : le réplica s’arrête avec des erreurs sur GTID, format de binlog, ou clés dupliquées qui « ne devraient pas arriver ».

Cause racine : mismatch de binlog_format (STATEMENT/MIXED vs ROW), paramètres GTID différents, ou statements non déterministes.

Correctif : standardisez sur ROW ; alignez la configuration GTID ; auditez les fonctions et triggers non déterministes.

4) « Les migrations DDL restent bloquées pour toujours »

Symptômes : ALTER TABLE bloqué, accumulation d’applications en attente, timeouts soudains.

Cause racine : verrous de métadonnées bloqués par des requêtes ou transactions longues ; outils de migration non safe-online.

Correctif : implémentez des approches de changement de schéma en ligne ; réduisez la durée des transactions ; planifiez des fenêtres DDL ; détectez les bloqueurs via processlist.

5) « Les performances ont régressé après une mise à jour ‘mineure’ »

Symptômes : latence en hausse, plans de requête modifiés, augmentation des tables temporaires disque.

Cause racine : changements d’optimiseur, différences de statistiques, ou dérive des paramètres.

Correctif : comparez les plans EXPLAIN avant/après ; rafraîchissez les statistiques ; ajoutez des index ciblés ; gatez les montées de version avec un test de diff de plan.

6) « Les connexions montent en flèche pendant le basculement et l’application fond »

Symptômes : Aborted_connects élevé, tempêtes de connexions, timeouts après un basculement RDS ou une maintenance.

Cause racine : les clients ne se reconnectent pas proprement ; pas de pooling ; boucles de retry agressives.

Correctif : ajoutez du pooling de connexions ; backoff exponentiel ; réduisez le churn des connexions ; validez le comportement de basculement lors d’exercices.

Listes de contrôle / plan étape par étape

Checklist A : Choisir entre MariaDB autogéré et RDS MariaDB (compatibilité d’abord)

1. Listez vos dépendances : plugins, UDF, chargements basés sur le système de fichiers, authentification personnalisée, scripts OS.
2. Classifiez chaque dépendance : « indispensable », « agréable à avoir », « legacy à supprimer ».
3. Vérifiez les besoins en privilèges : tout ce qui nécessite SUPER/FILE/accès OS est un élément de redesign pour une migration vers RDS.
4. Figez le comportement SQL : sql_mode, charset, collation, comportement des fuseaux horaires.
5. Définissez le plan de réplication : format binlog, mode GTID, approche de basculement, stratégie de rollback.
6. Définissez la stratégie de montée de version : qui approuve, comment tester les diffs de plan, et quels sont vos métriques « no-go ».

Checklist B : Plan de migration pour minimiser les surprises de compatibilité (fonctionne dans les deux sens)

1. Inventoriez les variables serveur source et cible ; diffuez-les et résolvez les différences intentionnelles.
2. Exportez uniquement le schéma et scannez les DEFINER et SQL SECURITY ; normalisez les utilisateurs/definers.
3. Exécutez une relecture représentative de requêtes et comparez résultats et temps, pas seulement « sans erreurs ».
4. Validez les jeux de caractères et collations au niveau table et colonne ; corrigez la dérive avant le déplacement des données.
5. Validez le comportement des fuseaux horaires en utilisant CONVERT_TZ et des dates limites.
6. Testez le basculement/reconnect avec l’application réelle et les réglages du pooler.
7. Entraînez la restauration à partir d’un snapshot/chaîne de logs dans un environnement de test ; mesurez le RTO et vérifiez la correction.
8. Coupez en prévoyant un rollback : écritures duales si possible, ou cutover basé sur réplication avec un plan de revert clair.

Checklist C : Opérations day‑2 qui réduisent la fréquence des surprises

• Exécutez des diffs périodiques des variables critiques entre environnements (dev/stage/prod).
• Automatisez les contrôles de « régression de plan » pour les requêtes principales après les montées de version.
• Gardez le slow query logging et Performance Schema utilisables (l’échantillonnage vaut mieux que l’aveuglement).
• Testez régulièrement la restauration et un basculement contrôlé, même si c’est inconfortable.

FAQ

1) Lequel a globalement le moins de surprises de compatibilité ?

Si votre appli attend un contrôle total (plugins, système de fichiers, opérations privilégiées), MariaDB autogéré vous surprendra moins.
Si votre application est portable et disciplinée, RDS vous surprendra moins opérationnellement — mais vous devez accepter des contraintes managées.

2) RDS MariaDB est‑il du « vrai MariaDB » ?

C’est le moteur MariaDB enveloppé dans un modèle de service managé. Le moteur SQL est réel ; l’environnement n’est pas votre serveur.
Les problèmes de compatibilité viennent généralement de l’enveloppe : privilèges, paramètres, plugins et comportement du stockage.

3) Quel est le principal piège lors d’une migration vers RDS MariaDB ?

Les workflows qui supposent un accès OS : imports/exports basés sur des fichiers, scripts personnalisés sur l’hôte DB, installation de plugins, ou opérations nécessitant SUPER.
Redessinez-les tôt, avant de toucher aux données.

4) Puis‑je compter sur « les montées mineures sont sûres » sur l’une ou l’autre plateforme ?

Non. Les montées mineures peuvent changer les choix d’optimiseur, les défauts et les comportements de cas limites. Elles sont généralement plus sûres que les majeures,
mais « généralement » n’est pas un contrat. Gatez les montées avec des diffs de plan et des relectures de requêtes.

5) Les modes SQL importent‑ils vraiment autant ?

Oui. Les modes SQL décident si des données incorrectes sont rejetées bruyamment ou acceptées silencieusement et stockées incorrectement.
Les surprises de compatibilité ressemblent souvent à « la DB a changé », alors qu’en fait elle est juste devenue plus stricte sur la correction.

6) Pourquoi les performances semblent‑elles différentes sur RDS même avec la même taille d’instance ?

Parce que le stockage et la sémantique I/O sont différents. Le stockage managé a des plafonds, un comportement de burst et des effets de voisins bruyants.
De plus, des contraintes de paramètres et la maintenance de fond peuvent modifier la distribution de latence.

7) Comment éviter les échecs liés aux DEFINER lors des migrations ?

Standardisez les definers sur un compte de service réel qui existe dans chaque environnement, et recréez routines/vues/triggers avec ce definer.
N’importez pas un dump rempli d’objets root@localhost dans un environnement où cette identité est dénuée de sens.

8) Devrais‑je utiliser le format binlog ROW ?

Dans la plupart des systèmes de production, oui. ROW réduit la non‑déterminisme et rend la réplication plus prévisible.
Il peut augmenter le volume du binlog, donc planifiez le stockage en conséquence, mais c’est généralement le choix de compatibilité le plus sûr.

9) L’autogéré est‑il toujours plus « compatible » parce que vous contrôlez tout ?

Vous contrôlez tout, y compris la capacité à créer accidentellement des configurations snowflake qui ne marchent que sur un hôte.
L’autogéré réduit les « contraintes du service managé », mais augmente la « dérive opérationnelle propriétaire » à moins que vous n’automatisiez et standardisiez.

10) Quelle est la meilleure façon de tester la compatibilité avant de basculer ?

Construisez un harnais qui valide : variables serveur, definers de schéma, correction représentative des requêtes, plans de requête,
et un test de charge incluant la concurrence et les jobs en arrière-plan. Ensuite, testez le basculement avec des clients réels.

Conclusion : étapes pratiques suivantes

Si vous décidez uniquement sur « fewer weird compatibility surprises », MariaDB autogéré est le choix le plus sûr lorsque vous avez besoin d’une parfaite parité fonctionnelle
avec une configuration on‑premise ou sur mesure existante. Vous pouvez recréer l’environnement précisément. Vous pouvez aussi recréer exactement les mêmes erreurs,
ce qui est une forme de cohérence.

RDS MariaDB est le choix le plus sûr quand le vrai problème est l’entropie opérationnelle : sauvegardes, patching, pannes de stockage et maintenance routinière.
Vous échangez du contrôle contre moins de catastrophes maison, et vous acceptez une surface de compatibilité différente : paramètres, privilèges et stockage managé.

Étapes suivantes qui réduisent réellement les surprises :

1. Différenciez vos variables serveur (sql_mode, charset/collation, réglages binlog, knobs de durabilité InnoDB) entre source et cible.
2. Scannez le schéma pour les mines DEFINER et normalisez‑les avant de migrer les données.
3. Choisissez une stratégie de réplication (ROW + stratégie GTID alignée) et répétez le cutover ainsi que le rollback.
4. Exécutez un harnais de plan et de correction avant les montées de version et avant les déplacements de plateforme. Rendez‑le ennuyeux. L’ennui est l’objectif.
5. Exercez l’échec : testez la restauration et le basculement avec l’application réelle. Si votre logique de reconnexion client est fragile, RDS l’exposera.

La meilleure façon d’obtenir moins de surprises n’est pas de choisir la plateforme « parfaite ». C’est d’arrêter de laisser les valeurs par défaut et les hypothèses diriger votre comportement en production.
Les bases de données ne récompensent pas l’ingénierie basée sur la foi.