MySQL-Replikation verstehen

Die MySQL-Replikation ermöglicht es, Daten von einem Datenbankserver (dem Primären, historisch als “Master” bezeichnet) automatisch auf einen oder mehrere zusätzliche Server (Replikate, historisch als “Slaves” bezeichnet) zu kopieren. Dieser Mechanismus bietet kritische Vorteile: Hochverfügbarkeit, Lese-Skalierung, geografische Verteilung und Backup-Entlastung.

Trotz ihrer Reife ist die MySQL-Replikation weit davon entfernt, ein “Einrichten und Vergessen”-System zu sein. Konfigurationsabweichungen, Schema-Änderungen, Hardware-Diskrepanzen und Netzwerkinstabilitäten wirken zusammen, um Replikationsfehler zu verursachen, die zu Dateninkonsistenzen, Anwendungsfehlern und sogar Ausfallzeiten führen können.

Dieser Leitfaden behandelt die häufigsten MySQL-Replikationsprobleme, ihre Ursachen und schrittweise Lösungen für sowohl traditionelle Binärlog- als auch GTID-basierte Replikationstopologien.

Voraussetzungen

  • Eine funktionierende MySQL Primär/Replikat-Konfiguration (MySQL 5.7+ oder MySQL 8.0+).
  • Shell-Zugang zu beiden Servern, Primär und Replikat.
  • Ausreichende Berechtigungen (SUPER oder REPLICATION CLIENT) zur Ausführung von SHOW SLAVE STATUS.
  • Vertrautheit mit grundlegendem SQL und Linux-Kommandozeilentools.
  • Optional: Percona Toolkit installiert für erweiterte Diagnose.

Häufige Replikationsprobleme

Die folgenden fünf Fehlermodi machen die große Mehrheit der MySQL-Replikationsprobleme aus:

  1. Replikat-Verzögerung (Seconds_Behind_Master > 0): Das Replikat kann Binärlog-Ereignisse nicht so schnell anwenden, wie der Primärserver sie produziert.
  2. Duplicate-Key-Fehler (Error 1062): Eine Zeile, die bereits auf dem Replikat existiert, wird erneut durch eine replizierte Transaktion eingefügt.
  3. Fehlende-Zeile-Fehler (Error 1032): Ein repliziertes UPDATE oder DELETE referenziert eine Zeile, die auf dem Replikat nicht existiert.
  4. Relay-Log-Beschädigung: Die Relay-Log-Datei auf dem Replikat wird aufgrund von Festplattenfehlern, Abstürzen oder unsachgemäßen Abschaltungen unlesbar.
  5. GTID-Divergenz: Bei GTID-basierter Replikation bildet der ausgeführte GTID-Satz des Replikats keinen zusammenhängenden Obersatz mehr von dem, was der Primärserver erwartet.

Schritt-für-Schritt-Lösung

1. Aktuellen Replikationsstatus bewerten

Beginnen Sie immer mit der Inspektion der Replikat-Gesundheit. Auf dem Replikat-Server führen Sie aus:

SHOW REPLICA STATUS\G

Für MySQL-Versionen vor 8.0.22 verwenden Sie SHOW SLAVE STATUS\G.

Wichtige Felder zur Inspektion:

FeldGesunder WertBedeutung
Replica_IO_RunningYesDer I/O-Thread ist mit dem Primären verbunden und liest Binärlogs
Replica_SQL_RunningYesDer SQL-Thread wendet Ereignisse aus dem Relay-Log an
Seconds_Behind_Source0Keine Replikationsverzögerung
Last_Error(leer)Keine Fehler aufgetreten

2. Replikat-Verzögerung beheben

watch -n 1 "mysql -e 'SHOW REPLICA STATUS\G' | grep -E 'Seconds_Behind|Exec_Source_Log_Pos|Read_Source_Log_Pos'"

Häufige Ursachen und Lösungen:

A) Langsame Abfragen auf dem Replikat:

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/replica-slow.log';

B) Single-Thread SQL-Anwendung (MySQL 5.6 und älter):

STOP REPLICA;
SET GLOBAL replica_parallel_workers = 4;
SET GLOBAL replica_parallel_type = 'LOGICAL_CLOCK';
START REPLICA;

C) Hardware-Engpass: Die Festplatten-I/O des Replikats ist gesättigt. Überwachen Sie mit iostat -x 1 und erwägen Sie den Wechsel zu SSDs.

3. Duplicate-Key-Fehler beheben (Error 1062)

Für Binärlog-basierte Replikation:

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

Für GTID-basierte Replikation:

STOP REPLICA;
SET GTID_NEXT = '3E11FA47-71CA-11E1-9E33-C80AA9429562:42';
BEGIN; COMMIT;
SET GTID_NEXT = 'AUTOMATIC';
START REPLICA;

4. Fehlende-Zeile-Fehler beheben (Error 1032)

-- Auf dem PRIMÄREN:
SELECT * FROM mydb.mytable WHERE id = 12345;
-- Auf dem REPLIKAT: vergleichen
SELECT * FROM mydb.mytable WHERE id = 12345;

5. Relay-Log-Beschädigung wiederherstellen

STOP REPLICA;
RESET REPLICA;
START REPLICA;

6. GTID-Divergenz korrigieren

SELECT @@gtid_executed;
  • Geringfügige Divergenz: Injizieren Sie leere Transaktionen auf dem Primären für die zusätzlichen GTIDs.
  • Größere Divergenz: Erstellen Sie das Replikat aus einem frischen Backup des Primären neu.

Prävention und Best Practices

  • Replikate schreibgeschützt machen: Setzen Sie read_only = 1 und super_read_only = 1.
  • GTID-Replikation verwenden: Vereinfacht Failover und das Neuausrichten von Replikaten erheblich.
  • Replikationsverzögerung kontinuierlich überwachen: Verwenden Sie PMM, Prometheus mit mysqld_exporter oder Datadog.
  • pt-table-checksum wöchentlich ausführen: Erkennen Sie Datenabweichungen proaktiv.
  • Failover vorsichtig automatisieren: Orchestrator, MHA oder MySQL InnoDB Cluster.

Zusammenfassung

  • MySQL-Replikationsfehler lassen sich typischerweise auf Verzögerung, Duplicate/Missing-Row-Fehler, Relay-Log-Beschädigung oder GTID-Divergenz zurückführen.
  • Beginnen Sie die Diagnose immer mit SHOW REPLICA STATUS.
  • Verwenden Sie sql_slave_skip_counter oder leere GTID-Transaktionen, um einzelne Fehler zu überwinden, aber validieren Sie anschließend immer die Datenkonsistenz.
  • Verhindern Sie Probleme durch read_only auf Replikaten, GTID-Replikation und kontinuierliches Monitoring.

Verwandte Artikel