Ces questions d'entretien pour un DBA MySQL / MariaDB partent du travail courant. Le DBA règle InnoDB, surveille la réplication et les GTID, exploite des clusters Galera ou Group Replication, place ProxySQL ou MaxScale devant les bases et sauvegarde avec XtraBackup ou mariadb-backup. En ESN et chez les infogérants, il gère souvent un parc mêlant MySQL, MariaDB et parfois SQL Server ou PostgreSQL, avec astreinte. Chez un éditeur ou un site à fort trafic, il travaille au plus près des développeurs sur les requêtes et les changements de schéma.
Deux moteurs, un seul intitulé de poste. MySQL et MariaDB ont divergé : GTID, outils de sauvegarde et haute disponibilité ne s'exploitent plus de la même façon. Un CV qui écrit « MySQL/MariaDB » peut cacher une seule des deux pratiques. Les profils venus du développement connaissent bien les index et l'EXPLAIN, beaucoup moins la reprise d'un cluster après une coupure. MySQL 8.0 est en fin de vie depuis avril 2026, et beaucoup d'équipes préparent leur passage à 8.4.
Le moteur réellement en production et sa version sont la première information à obtenir avant l'entretien. Une billetterie bloquée pendant une ouverture de ventes fournit le cas de 20 minutes.
MySQL, MariaDB et leurs outils d'exploitation
MySQL et MariaDB
MariaDB est née d'un fork de MySQL en 2009. Les deux restent compatibles pour une application simple, mais leurs fonctions avancées diffèrent : GTID, type JSON, authentification, haute disponibilité. Côté MySQL, les versions LTS sont 8.4 et 9.7 ; côté MariaDB, 10.11, 11.4, 11.8 et 12.3. Demandez sur quel moteur et quelle version la personne a travaillé en dernier.
InnoDB
Le moteur de stockage par défaut des deux bases, transactionnel et verrouillé à la ligne. Le réglage du buffer pool, du redo log et de la durabilité des commits pèse directement sur les performances et sur la sécurité des données. Un DBA expérimenté sait lire SHOW ENGINE INNODB STATUS.
Réplication et GTID
Le primaire écrit chaque modification dans ses binlogs, que les réplicas relisent et appliquent. Les GTID numérotent chaque transaction, ce qui facilite les bascules et le montage de nouveaux réplicas. Le retard de réplication est l'incident le plus courant du poste.
Galera Cluster
Une réplication synchrone multi-nœuds, intégrée à MariaDB et utilisée dans Percona XtraDB Cluster. Chaque nœud peut écrire, mais un nœud lent ralentit tout le cluster. La reprise après une panne complète est une compétence à vérifier en entretien.
Group Replication et InnoDB Cluster
L'offre de haute disponibilité d'Oracle pour MySQL. InnoDB Cluster associe Group Replication, MySQL Router et MySQL Shell pour gérer la bascule automatique. On la rencontre surtout sur MySQL 8 et chez les clients qui veulent rester sur l'édition d'Oracle.
ProxySQL et MaxScale
Deux proxys placés entre l'application et les bases. Ils répartissent lectures et écritures, mutualisent les connexions et suivent les changements de primaire. ProxySQL est open source et très répandu ; MaxScale est l'outil de MariaDB plc, sous licence BSL.
XtraBackup et mariadb-backup
Les deux outils de sauvegarde physique à chaud. XtraBackup, de Percona, sert pour MySQL ; mariadb-backup, dérivé de XtraBackup, est obligatoire pour les MariaDB récents. Avec les binlogs, ils permettent de restaurer à une minute précise.
Percona Toolkit et gh-ost
Une boîte à outils en ligne de commande : pt-query-digest pour analyser les requêtes lentes, pt-table-checksum pour comparer primaire et réplicas, pt-online-schema-change pour modifier une grosse table sans blocage. gh-ost, de GitHub, fait la même chose sans triggers en lisant les binlogs.
Supervision : PMM, Zabbix, Prometheus
Percona Monitoring and Management (PMM) regroupe métriques MySQL et analyse des requêtes. Beaucoup d'équipes utilisent aussi Zabbix ou Prometheus avec mysqld_exporter, et Grafana pour les tableaux de bord. Les offres françaises citent souvent Ansible pour automatiser l'ensemble.
Le poste prend des formes variées. En ESN ou chez un infogérant, le DBA MySQL / MariaDB gère des dizaines d'instances pour plusieurs clients, souvent dans un parc multi-moteurs avec SQL Server ou PostgreSQL, et assure des astreintes. Les offres de DBA de production demandent Linux, du scripting shell ou Python, Ansible et un outil de supervision comme Zabbix, Dynatrace ou Grafana. Chez un éditeur SaaS ou un site à fort trafic, le DBA travaille sur la réplication à grande échelle, les changements de schéma sans coupure et les requêtes des développeurs. Sur les services managés (Amazon RDS, Aurora, Azure Database for MySQL), l'hébergeur prend en charge une partie des sauvegardes et de la bascule. Le travail se déplace alors vers la performance et la configuration. Les certifications Oracle MySQL et MariaDB existent. Elles attestent la connaissance du produit, pas une reprise de cluster déjà menée.
Les compétences à contrôler chez un DBA MySQL / MariaDB
- Réplication MySQL et GTID
- Clusters Galera et Group Replication
- Réglage et verrous InnoDB
- Analyse des requêtes et index
- Changements de schéma en ligne
- Sauvegarde, PITR et montées de version
Cinq questions à poser à un DBA MySQL ou MariaDB
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un réplica affiche Seconds_Behind_Source à 3 000 et le chiffre ne baisse pas. Que regardez-vous ?
Une bonne réponseSHOW REPLICA STATUS d'abord, pour savoir quel thread est en cause : le thread de réception (réseau, primaire) ou le thread d'application. Le plus souvent, le réplica rejoue une grosse transaction ou un ALTER d'une traite, ou applique en ROW des modifications sur une table sans clé primaire, ce qui force un parcours complet par ligne. La personne vérifie la réplication parallèle (replica_parallel_workers, dépendances par writeset), les E/S disque du réplica et les requêtes de reporting qui le chargent. Elle sait aussi que Seconds_Behind_Source peut afficher 0 alors que la réception est coupée.
Signal d'alerte« Je redémarre la réplication » ou « je saute l'erreur », sans jamais distinguer les deux threads. Aucune idée de ce que coûte une table sans clé primaire en réplication ROW.
Question 2 · senior
Après une bascule, un ancien réplica refuse de suivre le nouveau primaire à cause d'une transaction GTID que celui-ci ne connaît pas. Que s'est-il passé, et comment corrigez-vous ?
Une bonne réponseUne transaction errante : quelqu'un a écrit directement sur le réplica, faute de super_read_only. On la trouve avec GTID_SUBTRACT entre le gtid_executed du réplica et celui du primaire. Si elle n'a pas d'effet métier, on injecte sur le primaire une transaction vide portant le même GTID. Sinon, on reconstruit le réplica. Pour l'éviter, super_read_only est activé sur tous les réplicas et vérifié par la supervision. Un profil MariaDB précise que le GTID de MariaDB a un autre format (domaine, serveur, séquence) et se règle avec gtid_strict_mode.
Signal d'alerteUn RESET des journaux binaires sur le primaire pour « repartir propre », qui casse tous les autres réplicas. Ou aucune notion de transaction errante.
Question 3 · confirmé
Sur un cluster Galera à trois nœuds, les écritures se figent par moments en pleine journée. Quelle est votre piste ?
Une bonne réponseLe contrôle de flux. Un nœud lent, à cause d'un disque saturé, d'une sauvegarde ou d'une requête lourde, remplit sa file de réception et met tout le cluster en pause. La personne regarde wsrep_flow_control_paused et wsrep_local_recv_queue sur chaque nœud. Elle cite aussi les DDL en mode TOI, qui bloquent le cluster entier, et les conflits de certification (wsrep_local_cert_failures) quand l'application écrit sur plusieurs nœuds à la fois. La réponse type : un seul nœud d'écriture désigné par ProxySQL ou MaxScale.
Signal d'alerte« On ajoute un quatrième nœud », alors qu'un nœud de plus ne règle pas un nœud lent. Aucune mention du contrôle de flux.
Question 4 · junior à confirmé
Comment dimensionnez-vous innodb_buffer_pool_size sur un serveur de 64 Go dédié à MySQL, et comment savez-vous que le réglage est bon ?
Une bonne réponseUn point de départ autour de 70 à 75 % de la RAM sur un serveur dédié, en gardant de la marge pour les buffers par connexion et pour le système. Ensuite, on mesure : lectures disque (Innodb_buffer_pool_reads) rapportées aux lectures logiques, pages libres, taille réelle des données chaudes, absence de swap. La personne sait que le buffer pool se redimensionne à chaud et que innodb_dedicated_server peut le calculer. Elle pense aussi à la capacité du redo log (innodb_redo_log_capacity), réglée en même temps.
Signal d'alerteUne configuration copiée d'un blog, ou 95 % de la RAM jusqu'au swap et à l'OOM killer. Parler du query cache, supprimé dans MySQL 8.0.
Question 5 · confirmé
Il faut ajouter une colonne et un index sur une table de 200 millions de lignes en production, sans couper le site. Comment procédez-vous ?
Une bonne réponseD'abord vérifier ce que le moteur sait faire : ajout de colonne en ALGORITHM=INSTANT (MySQL 8.0, MariaDB 10.3 et après), création d'index en INPLACE avec LOCK=NONE. Le DDL reste rejoué d'un bloc sur les réplicas, d'où un retard à prévoir. Sinon, pt-online-schema-change ou gh-ost, avec leurs contraintes (clé primaire, triggers existants, clés étrangères), une limitation sur le retard des réplicas et deux fois l'espace disque. La personne parle du verrou de métadonnées : une transaction longue bloque l'ALTER, et l'ALTER bloque toutes les requêtes qui suivent. Sur Galera, elle évite le mode TOI.
Signal d'alerteUn ALTER direct en heure de pointe, sans avoir entendu parler du metadata lock. Ou « on coupe le site le dimanche » comme seule réponse.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recruter un DBA MySQL / MariaDB : vos questions
Un DBA MySQL sait-il administrer MariaDB ?
Pour les bases, oui : SQL, InnoDB, index et réplication classique se ressemblent. Les écarts apparaissent sur la haute disponibilité, les GTID et les sauvegardes. Un DBA formé sur MySQL 8 et Group Replication devra apprendre Galera, le GTID de MariaDB et mariadb-backup, et l'inverse vaut aussi. Si votre parc est surtout MariaDB, demandez une reprise de cluster Galera vécue plutôt qu'une simple mention sur le CV.
Quelles compétences attendre d'un administrateur MySQL confirmé ?
La réplication avec GTID et le diagnostic d'un retard, une solution de haute disponibilité exploitée en production (Galera, Group Replication ou bascule avec Orchestrator), le réglage d'InnoDB, l'analyse des requêtes avec pt-query-digest ou le performance_schema, la sauvegarde physique et la restauration à un instant donné. S'ajoutent Linux, le scripting et Ansible, qui reviennent dans la plupart des offres de DBA de production.
Comment organiser le test technique d'un DBA MySQL ?
Un serveur de test avec une réplication cassée ou une requête lente fonctionne mieux qu'un questionnaire. Donnez un SHOW REPLICA STATUS en erreur, un EXPLAIN ou un extrait de slow query log, et demandez à la personne de raisonner à voix haute. En trente minutes, vous voyez si elle cherche la cause ou si elle applique des recettes. La grille du PDF permet de noter chaque axe de la même façon pour tous les candidats.
Faut-il encore un DBA quand les bases tournent sur Amazon RDS ou Aurora ?
Le besoin change. L'hébergeur gère les sauvegardes, les correctifs et une bonne partie de la bascule. Restent la performance des requêtes, les index, les changements de schéma sur de grosses tables, le dimensionnement des instances et le coût. Il reste aussi la restauration après une erreur humaine, que l'équipe doit savoir lancer. Pour ce périmètre, un DBA cloud ou un profil DBRE convient souvent mieux qu'un DBA de production classique.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
