MySQL Replikation – Asynchron, Semi-Sync, GTID

Du willst MySQL ausfallsicher machen und gleichzeitig lesen skalieren. Replikation ist dafür das Standardwerkzeug. Eine Instanz schreibt, eine oder mehrere lesen mit und übernehmen bei Bedarf. Klingt einfach, wird aber schnell technisch, wenn es um Konsistenz, Lag und Failover geht.

In diesem Guide bekommst du die Grundlagen so erklärt, dass du loslegen kannst. Du verstehst den Unterschied zwischen asynchron und semi-synchron, lernst, warum GTID das Leben bei Failover massiv vereinfacht, und erhältst einen Schritt-für-Schritt Ablauf für ein kleines Setup inklusive typischer Stolpersteine.

Was Replikation dir bringt

Replikation kopiert Transaktionen von der Primary auf Replicas. Vorteile: Lese-Skalierung über Read-Replicas, schnelleres Recovery bei Ausfällen und die Möglichkeit, Backups von einer Replica zu ziehen. Wichtig: Replikation ersetzt kein Backup. Sie schützt nicht vor Löschen oder korrupten Writes.

So funktioniert MySQL Replikation intern

• Binary Log (binlog): Die Primary schreibt jede bestätigte Transaktion ins binlog.
• I/O Thread: Die Replica verbindet sich zur Primary, zieht das binlog und schreibt es in den relay log.
• SQL Thread: Die Replica replayed die Events in der gleichen Reihenfolge.
• Parallelisierung: Mit replica_parallel_workers können mehrere Schema- oder Transaktionsgruppen parallel laufen.

Binlog Format:

• ROW: speichert konkrete Zeilenänderungen – robust und heute Standard.
• STATEMENT: speichert SQL – schneller, aber fehleranfälliger.
• MIXED: mischt beides. Für Einsteiger ist ROW die sichere Wahl.

Asynchron vs Semi-Sync auf den Punkt

Asynchrone Replikation

Die Primary bestätigt einen Commit, sobald er lokal im binlog ist. Die Replica zieht danach nach.
Vorteil: sehr schnell, minimaler Overhead.
Nachteil: bei Ausfall der Primary kann Lag zu Datenverlust führen (die letzten Transaktionen haben die Replica noch nicht erreicht).

Semi-synchrone Replikation

Die Primary bestätigt erst, wenn mindestens eine Replica den Write empfangen und in den relay log geschrieben hat.
Vorteil: stark reduziertes Verlustfenster.
Nachteil: etwas mehr Latenz pro Commit, Abhängigkeit von der Erreichbarkeit einer Replica.

Semi-Sync bestätigt nicht erst nach Anwendung, sondern nach Empfang. Das ist ein wichtiger Unterschied zu echter Synchronität.

GTID – warum das dein Failover entspannt

GTID steht für Global Transaction ID. Jede Transaktion bekommt eine eindeutige ID. Damit kannst du Replicas fast ohne Nachdenken umbiegen: Statt Positionen in Dateien zu merken, sagst du einfach „folge ab der nächsten fehlenden GTID„. Auch Kaskaden und Promotion werden sauberer.

Kerneffekte:

• Einfaches Failover: SOURCE_AUTO_POSITION=1 statt Datei/Offset.
• Konsistenzen prüfen: Du siehst schnell, welche GTIDs fehlen.
• Weniger Handarbeit: Weniger Raum für Fehler bei der Einrichtung.

Schritt für Schritt: kleines Setup mit GTID

1) Voraussetzungen klären

• MySQL 8.x auf allen Knoten.
• Feste Server-IDs und saubere Uhren (NTP).
• Netzwerkzugriff von Replica zur Primary.

2) Primary konfigurieren (my.cnf)

server_id=1
log_bin=mysql-bin
binlog_format=ROW
gtid_mode=ON
enforce_gtid_consistency=ON
log_replica_updates=ON   # in älteren Versionen: log_slave_updates=ON
binlog_expire_logs_seconds=604800

Benutzer anlegen:

CREATE USER 'repl'@'10.%' IDENTIFIED BY 'starkesPasswort';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.%'; -- Alias: REPLICATION REPLICA
FLUSH PRIVILEGES;

3) Konsistenter Dump mit GTID

Variante A schnell und sicher:

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS; -- nur Info
-- getrenntes Terminal:
BACKUP mit mysqldump --single-transaction --set-gtid-purged=ON
UNLOCK TABLES;

Oder du nutzt einen physikalischen Snapshot/Backup-Tool, wichtig ist Konsistenz.

4) Replica vorbereiten (my.cnf)

server_id=2
relay_log=relay-bin
read_only=ON
super_read_only=ON
gtid_mode=ON
enforce_gtid_consistency=ON

Dump einspielen, dann Verbindung setzen:

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.0.10',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='starkesPasswort',
  SOURCE_AUTO_POSITION=1;
START REPLICA;
SHOW REPLICA STATUS\G

Achte auf Seconds_Behind_Source und Replica_IO/SQL_Running=Yes.

5) Optional: Semi-Sync aktivieren

Je nach Version heißen die Plugins master/slave oder source/replica:

INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_source_enabled=ON;
SET GLOBAL rpl_semi_sync_replica_enabled=ON;

Teste kurz unter Last, ob die Latenz akzeptabel ist.

Konsistenz und Lese-Skalierung

• Lag im Blick: Nutze Seconds_Behind_Source und Metriken wie Relay Log Bytes. Bei hohem Lag nicht von Replica lesen, wenn du frische Daten brauchst.
• Read-Your-Writes: Kritische Pfade lesen direkt von der Primary oder von Replicas mit geringem Lag.
• Parallelisierung:

  SET GLOBAL replica_parallel_workers=4; -- älter: slave_parallel_workers
  

  Erhöht Durchsatz bei vielen unabhängigen Transaktionen.

Failover und Promotion

• Geplant: Replica mit super_read_only=OFF promoten, alten Primary fixen und später als neue Replica anhängen (SOURCE_AUTO_POSITION=1).
• Ungeplant: Wähle die weiteste Replica (meiste GTIDs). Prüfe Integrität, dann DNS oder VIP umschwenken.
• Tooling: Später lohnt sich ein Orchestrierungs-Tool. Für Einsteiger reicht Dokumentation + kleine Runbooks.

Sicherheit und Good Practices

• ROW binlog verwenden, um Replikationsfehler zu vermeiden.
• Kein wildes Filtering wie binlog_ignore_db, solange du nicht genau weißt, was du tust.
• read_only und super_read_only auf Replicas aktiv, nur Replikations-Thread darf schreiben.
• Backups von der Replica ziehen, aber regelmäßig Restore testen.
• Monitoring: Fehlerlog, Performance Schema Repl.-Tabellen, Prometheus Exporter.
• Weniger Rechte: Repl-Benutzer nur mit REPLICATION Rechten anlegen.

Häufige Fehler und schnelle Lösungen

• Lag durch große Transaktionen: Große Batch-Writes splitten, innodb_flush_log_at_trx_commit=1 prüfen und binlog_group_commit nutzen.
• Mixed DDL/DML in einer Transaktion: Vermeiden oder getrennt ausführen, sonst knirscht es beim Replaying.
• Zeitdrift: Ohne NTP sind Logs schwer zu korrelieren.
• Semi-Sync bricht auf Async zurück: Netzwerk prüfen, mindestens eine Replica muss verlässlich ackn.

Mini-Checkliste zum Start

1. GTID aktivieren, ROW setzen.
2. Primary konfigurieren, Repl-User anlegen.
3. Konsistenten Dump ziehen, auf Replica einspielen.
4. Auto-Position aktivieren, Replikation starten.
5. Lag und Fehler monitoren, bei Bedarf Parallel-Workers erhöhen.
6. Optional Semi-Sync testen, wenn du weniger Datenverlust riskieren willst.

Fazit

Mit asynchroner Replikation bekommst du Tempo und einfache Skalierung, mit Semi-Sync reduzierst du das Verlustfenster. GTID macht Failover überschaubar und spart dir Positionsgefummel. Starte klein mit GTID + ROW, halte Lag im Blick, dokumentiere Promotion-Schritte und übe einmal die Woche einen Mini-Failover im Test. So wird dein MySQL Setup robust und bleibt beherrschbar.