Haute disponibilité MySQL en 2026 — Galera, InnoDB Cluster ou réplicas async ?

La haute disponibilité MySQL se divise en trois vraies options en 2026 : réplication async avec failover manuel ou orchestré, multi-primary basé sur Galera (Percona XtraDB Cluster / MariaDB Galera), ou MySQL Group Replication via InnoDB Cluster. Chacun fait un compromis différent entre latence de commit, conflits d'écriture et complexité opérationnelle.

La mauvaise réponse est « on va juste mettre CHANGE MASTER TO et croiser les doigts ». Nous voyons ça partout. Ça ne survit pas à une panne du primary avec une histoire d'intégrité de données défendable.

Un bootstrap InnoDB Cluster fonctionnel

-- sur chaque nœud
SET PERSIST group_replication_local_address='node1:33061';
SET PERSIST group_replication_group_seeds='node1:33061,node2:33061,node3:33061';
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
 
-- sur un nœud
SET PERSIST group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET PERSIST group_replication_bootstrap_group=OFF;

MySQL Router en façade, configuré pour suivre le primary. Le failover est sous 15 secondes.

L'article complet couvre :

• Réplication async : quand elle suffit vraiment, et les orchestrateurs (Orchestrator, MHA) qui la font survivre à une panne
• Trade-offs Galera : certification synchrone, la taxe des conflits d'écriture, et le dimensionnement de gcache que personne ne planifie
• InnoDB Cluster : plus simple que Galera, mais avec ses propres quirks de failover
• L'arbre de décision que nous appliquons aux clients (ratio lecture/écriture, concurrence d'écriture, étalement géographique)
• Interaction avec les backups : XtraBackup sur nœuds Galera vs InnoDB Cluster
• Pièges côté application (offsets d'auto-increment, cohérence read-after-write)

Nous déployons ceci pour chaque client MySQL managé qui a besoin de HA.