MySQL-Hochverfügbarkeit 2026 — Galera, InnoDB Cluster oder asynchrone Replicas?

MySQL-Hochverfügbarkeit teilt sich 2026 in drei echte Optionen: asynchrone Replikation mit manuellem oder orchestriertem Failover, Galera-basiertes Multi-Primary (Percona XtraDB Cluster / MariaDB Galera) oder MySQL Group Replication via InnoDB Cluster. Jeder macht einen anderen Trade-off zwischen Commit-Latenz, Schreibkonflikten und operativer Komplexität.

Die falsche Antwort ist „wir richten einfach CHANGE MASTER TO ein und hoffen". Wir sehen das überall. Es übersteht keinen Primary-Ausfall mit einer Datenintegritäts-Story, die Sie verteidigen wollen würden.

Ein funktionierender InnoDB-Cluster-Bootstrap

-- auf jedem Knoten
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';
 
-- auf einem Knoten
SET PERSIST group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET PERSIST group_replication_bootstrap_group=OFF;

MySQL Router davor, konfiguriert, dem Primary zu folgen. Failover unter 15 Sekunden.

Der vollständige Beitrag behandelt:

• Asynchrone Replikation: wann sie tatsächlich genug ist, und die Orchestratoren (Orchestrator, MHA), die sie Ausfälle überstehen lassen
• Galera-Trade-offs: synchrone Zertifizierung, die Write-Conflict-Steuer, und die gcache-Dimensionierung, die niemand plant
• InnoDB Cluster: einfacher als Galera, aber mit eigenen Failover-Eigenheiten
• Der Entscheidungsbaum, den wir mit Kunden durchgehen (Lese-/Schreibverhältnis, Schreibkonkurrenz, geografische Verteilung)
• Backup-Interaktion: XtraBackup auf Galera-Knoten vs InnoDB Cluster
• Anwendungsseitige Stolperfallen (Auto-Increment-Offsets, Read-after-Write-Konsistenz)

Wir deployen das für jeden gemanagten MySQL-Kunden, der HA braucht.