Practical MySQL & MariaDB

MySQL-Replikation erklärt: Einrichtung, GTID, Überwachung und Fehlerbehebung – Leitfaden

Erweitert / Sonstiges
目次

1. Was ist MySQL-Replikation? Überblick und Anwendungsfälle

MySQL-Replikation ist ein Feature, das Kopien einer Datenbank in Echtzeit mit anderen Servern synchronisiert. Dies verbessert die Redundanz und Leistung der Datenbank. Im Folgenden erklären wir im Detail, wann MySQL-Replikation eingesetzt wird und wie sie funktioniert.

Überblick über MySQL-Replikation

MySQL-Replikation teilt Datenbankinhalte über mehrere Server hinweg mithilfe eines Master-Servers und eines oder mehrerer Slave-Server. Konkret werden Datenänderungen, die im Binärlog des Master-Servers aufgezeichnet werden, von den Slave-Servern gelesen und angewendet, um die Daten synchron zu halten. Dies ermöglicht die Kontinuität des Dienstes, indem bei einem Ausfall des Master-Servers auf einen Slave-Server umgeschaltet wird.

Anwendungsfälle von MySQL-Replikation

MySQL-Replikation wird in den folgenden Szenarien häufig eingesetzt:

  • Hohe Verfügbarkeit : Im Falle eines Ausfalls minimiert das Umschalten auf einen Slave-Server die Ausfallzeit.
  • Lastverteilung : Lese‑Only‑Abfragen können auf Slave-Server verteilt werden, wodurch die Last auf dem Master-Server reduziert wird.
  • Datenschutz und Backup : Da die Replikation Daten in Echtzeit dupliziert, kann sie auch als Backup‑Mechanismus dienen.

Arten der Replikation

MySQL-Replikation umfasst die folgenden Typen, basierend auf der Synchronisationsmethode:

  • Asynchrone Replikation : Der Master fährt fort, ohne auf eine Bestätigung vom Slave zu warten. Das ermöglicht schnellere Reaktionszeiten, kann jedoch dazu führen, dass bei einem Ausfall einige Daten den Slave nicht erreichen.
  • Semi-synchrone Replikation : Der Master wartet auf die Bestätigung, dass die Daten vom Slave empfangen wurden, bevor er fortfährt. Das bietet höhere Zuverlässigkeit als die asynchrone Replikation, jedoch mit leicht langsameren Reaktionszeiten.

Der nächste Abschnitt erklärt die grundlegenden Konzepte der MySQL-Replikation, einschließlich Binärlogs und GTID.

2. Grundkonzepte der MySQL-Replikation

Um MySQL-Replikation zu verstehen, ist es wichtig, die Rollen des Binärlogs und der GTID (Global Transaction ID) zu erfassen, die im Replikationsprozess eine entscheidende Rolle spielen. Diese Elemente bilden die Grundlage für eine präzise Datenreplikation.

Rollen von Master und Slave

In der MySQL-Replikation haben der Master-Server und der Slave-Server unterschiedliche Rollen. Der Master zeichnet Datenänderungen im Binärlog auf und sendet sie an den Slave. Der Slave wendet die empfangenen Logs an, um seine Daten zu aktualisieren. Dadurch hält der Slave dieselben Daten wie der Master.

Binärlog und Relay‑Log

MySQL-Replikation basiert auf den folgenden beiden Logs:

  1. Binärlog
  • Der Binärlog zeichnet Datenänderungen (wie INSERT, UPDATE und DELETE) auf dem Master-Server auf. Dadurch kann der Slave-Server denselben Datenzustand wie der Master beibehalten.
  1. Relay‑Log
  • Der Relay‑Log speichert die vom Master empfangenen Binärlog‑Ereignisse auf dem Slave-Server. Der SQL‑Thread des Slaves führt den Relay‑Log sequenziell aus, um Datenänderungen anzuwenden.

Was ist GTID (Global Transaction ID)?

GTID ist ein Mechanismus, der jeder Transaktion eine eindeutige ID zuweist und so die Konsistenz über mehrere Slaves hinweg gewährleistet. Durch die Verwendung von GTID ist die Angabe von Binärlog‑Positionen nicht mehr erforderlich. Nur Transaktionen, die noch nicht vom Master abgerufen wurden, werden automatisch auf den Slave angewendet, was die Verwaltung stark vereinfacht.

Vorteile von GTID

  • Eindeutige Identifizierung : Jeder Transaktion wird eine eindeutige GTID zugewiesen, die klar angibt, welche Transaktionen bereits angewendet wurden.
  • Einfachere Wiederherstellung : Bei Verwendung von GTID werden nach einem Neustart des Masters oder Slaves nur nicht angewendete Transaktionen erneut verarbeitet.
  • Effizientes Betriebsmanagement : Selbst in groß angelegten Umgebungen mit mehreren Slaves kann die Transaktionskonsistenz mit vereinfachtem Management aufrechterhalten werden.

Um GTID zu verwenden, sind die Einstellungen gtid_mode=ON und enforce_gtid_consistency=ON erforderlich. Das Konfigurieren dieser Einstellungen sowohl auf dem Master als auch auf dem Slave ermöglicht eine GTID-basierte Replikation.

Der nächste Abschnitt erklärt die konkreten Schritte zur Einrichtung der MySQL-Replikation.

3. MySQL‑Replikations‑Einrichtungs‑Verfahren

Dieser Abschnitt erklärt die erforderlichen Schritte, um MySQL‑Replikation einzurichten. Wenn Sie diesen Schritten folgen, können Sie eine einfache Master‑Slave‑Struktur konfigurieren und eine Echtzeit‑Daten­synchronisation aktivieren.

Konfiguration des Master‑Servers

Zuerst bearbeiten Sie die Konfigurationsdatei des Master‑Servers (üblicherweise my.cnf oder my.ini), um das Binär‑Log zu aktivieren und die Server‑ID festzulegen.

  1. Konfigurationsdatei bearbeiten
  • Fügen Sie die folgenden Einstellungen im Abschnitt [mysqld] ein und setzen Sie eine eindeutige Server‑ID (z. B. 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • Die server-id muss für jeden Server eine eindeutige Nummer sein, und log-bin aktiviert das Binär‑Log.
  1. Replikations‑Benutzer anlegen
  • Legen Sie einen dedizierten Replikations‑Benutzer auf dem Master‑Server an und gewähren Sie die erforderlichen Berechtigungen.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • Dieser Benutzer wird vom Slave‑Server benötigt, um auf die Daten des Masters zuzugreifen.
  1. Master‑Status prüfen
  • Prüfen Sie die aktuelle Binär‑Log‑Datei und Position (Log‑Ort). Diese Information wird beim Konfigurieren des Slave‑Servers benötigt.
    SHOW MASTER STATUS;
  • Die von diesem Befehl angezeigten Werte File (Log‑Dateiname) und Position werden in der Slave‑Konfiguration verwendet.

Konfiguration des Slave‑Servers

Als Nächstes bearbeiten Sie die Konfigurationsdatei des Slave‑Servers und setzen die Server‑ID sowie die Master‑Informationen.

  1. Konfigurationsdatei bearbeiten
  • Setzen Sie ebenfalls eine eindeutige server-id auf dem Slave‑Server (z. B. 2). Dieser Wert muss sich von der Server‑ID des Masters unterscheiden.
    [mysqld]
server-id=2
  • Es ist außerdem üblich, read_only=ON zu setzen, um Schreibvorgänge auf dem Slave‑Server zu verhindern.
  1. Master‑Informationen auf dem Slave konfigurieren
  • Führen Sie den folgenden Befehl auf dem Slave‑Server aus und geben Sie den Hostnamen des Masters, den Benutzer, den Namen der Binär‑Log‑Datei und die Position an.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • Tragen Sie die zuvor auf dem Master bestätigten Werte für MASTER_LOG_FILE und MASTER_LOG_POS ein.
  1. Replikation starten
  • Führen Sie den folgenden Befehl auf dem Slave‑Server aus, um die Replikation zu starten.
    START SLAVE;

Replikations‑Status überprüfen

Stellen Sie sicher, dass die Replikation zwischen Master und Slave korrekt konfiguriert ist.

  • Master‑Status prüfen
    SHOW MASTER STATUS;
  • Slave‑Status prüfen
    SHOW SLAVE STATUS\G;
  • Wenn sowohl Slave_IO_Running als auch Slave_SQL_Running den Wert Yes anzeigen, läuft die Replikation normal.

Der nächste Abschnitt erklärt erweiterte Replikations‑Konfigurationen, einschließlich der Unterschiede zwischen asynchroner und semi‑synchroner Replikation sowie die Einrichtung mittels GTID.

4. Arten der Replikation und erweiterte Nutzung

MySQL‑Replikation umfasst zwei Hauptarten, basierend auf der Daten‑Synchronisations‑Methode: asynchrone Replikation und semi‑synchrone Replikation. Wenn Sie deren Eigenschaften verstehen und je nach Anwendungsfall auswählen, können Sie sowohl die Systemleistung als auch die Zuverlässigkeit verbessern. Dieser Abschnitt erläutert zudem die Vorteile der Verwendung von GTID (Global Transaction Identifier) für die Replikationskonfiguration.

Unterschiede zwischen asynchroner und semi‑synchroner Replikation

1. Asynchrone Replikation

Bei der asynchronen Replikation gibt der Master‑Server dem Client sofort nach Abschluss einer Transaktion eine Antwort zurück. Das bedeutet, dass der Master neue Anfragen weiter verarbeiten kann, während die Synchronisation zum Slave‑Server noch verzögert ist. Dies liefert eine hervorragende Antwort‑Performance und eignet sich für Systeme, die auf Lastverteilung ausgelegt sind. Bei einem Ausfall besteht jedoch das Risiko, dass Daten, die noch nicht auf den Slave‑Server angewendet wurden, verloren gehen.

2. Semi‑synchrone Replikation

In der semi-synchronen Replikation gibt der Master-Server eine Antwort an den Client erst zurück, nachdem bestätigt wurde, dass die Datenübertragung zum Slave-Server abgeschlossen ist. Dies verbessert die Datenkonsistenz, kann jedoch die Transaktionsantwortzeiten erhöhen, da auf den Slave gewartet wird. Semi-synchrone Replikation ist gut geeignet für Systeme, die hohe Datenkonsistenz erfordern, oder Umgebungen, in denen Datenzuverlässigkeit oberste Priorität hat.

Replikation mit GTID

GTID (Global Transaction Identifier) weist jeder Transaktion eine eindeutige ID zu und gewährleistet die Transaktionskonsistenz zwischen Master und Slave. Das Aktivieren von GTID erleichtert die Replikationsverwaltung im Vergleich zur herkömmlichen, positionsbasierten Binärlog‑Replikation.

Vorteile von GTID

  • Verbesserte Datenkonsistenz : Mit GTID kann der Slave automatisch Transaktionen erkennen, die noch nicht angewendet wurden, was die Wahrung der Konsistenz erleichtert.
  • Vereinfachte Replikationsverwaltung : GTID erhöht die Effizienz bei Failover, Master/Slave‑Umschaltung und Wiederherstellungsaufgaben. Da Sie nicht mehr Binärlog‑Positionen angeben müssen, werden die Vorgänge einfacher.

GTID‑Replikationskonfiguration

Um GTID zu verwenden, müssen Sie die folgenden Optionen in den Konfigurationsdateien sowohl des Masters als auch des Slaves hinzufügen und aktivieren.

Master-Server-Konfiguration

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

Slave-Server-Konfiguration

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

In einer GTID‑aktivierten Umgebung wird die Replikation automatisch über GTID durchgeführt, indem Sie die Master‑Informationen auf dem Slave mit dem Befehl CHANGE MASTER TO festlegen.

Der nächste Abschnitt erklärt Wartungsmethoden für MySQL‑Replikation und wichtige Überwachungspunkte für das Betriebsmanagement.

5. Wartung und Überwachung der Replikation

Um MySQL‑Replikation ordnungsgemäß zu betreiben, sind regelmäßige Wartung und Überwachung unerlässlich. Dieser Abschnitt erklärt Befehle zur Überprüfung, ob die Replikation normal funktioniert, und wie häufige Fehler zu behandeln sind.

Wie man den Replikationsstatus prüft

Verwenden Sie die folgenden Befehle, um den Synchronisationsstatus zwischen Master und Slave zu prüfen.

Überprüfung des Master‑Status

Sie können den Replikationsstatus des Master‑Servers mit dem Befehl SHOW MASTER STATUS überprüfen. Dieser Befehl zeigt den aktuellen Binärlog‑Dateinamen und die Position an, sodass Sie die neuesten Updates bestätigen können, die an den Slave geliefert werden sollen.

SHOW MASTER STATUS;

Die Ausgabe enthält typischerweise die folgenden Felder:

  • File : Der aktuelle vom Master erzeugte Binärlog‑Dateiname
  • Position : Die aktuelle Position im Binärlog
  • Binlog_Do_DB und Binlog_Ignore_DB : Datenbanken, die in die Replikation einbezogen bzw. ausgeschlossen werden

Überprüfung des Slave‑Status

Sie können den Replikationsstatus des Slave‑Servers mit dem Befehl SHOW SLAVE STATUS prüfen. Die Ergebnisse enthalten Informationen, die erforderlich sind, um festzustellen, ob der Slave korrekt arbeitet.

SHOW SLAVE STATUS\G;

Wichtige Felder umfassen:

  • Slave_IO_Running und Slave_SQL_Running : Wenn beide Yes sind, läuft der Slave normal.
  • Seconds_Behind_Master : Gibt an, wie weit der Slave hinter dem Master zurückliegt (in Sekunden). Idealerweise sollte dieser Wert 0 sein.

Fehlersuche bei der Replikation

Häufige Probleme beim Betrieb der Replikation umfassen Verbindungsfehler und Dateninkonsistenzen. Nachfolgend typische Fehlerszenarien und deren Behebung.

1. Verbindungsfehler

Wenn Slave_IO_Running No ist, bedeutet das, dass der Slave keine Verbindung zum Master herstellen kann. Versuchen Sie Folgendes:

  • Überprüfen Sie den Hostnamen oder die IP-Adresse des Masters : Stellen Sie sicher, dass die Master‑Adresse korrekt ist.
  • Prüfen Sie die Firewall‑Einstellungen : Vergewissern Sie sich, dass der erforderliche Port (in der Regel 3306) geöffnet ist.

2. Dateninkonsistenz

Wenn Last_Error eine Fehlermeldung enthält, könnte eine Dateninkonsistenz zwischen Master und Slave aufgetreten sein. In solchen Fällen stoppen Sie den Slave und wenden Korrekturen an, bevor Sie die Replikation neu starten.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. Reduzierung der Replikationsverzögerung

Replikationsverzögerung kann durch Hardwarebeschränkungen des Slaves oder Netzwerkprobleme verursacht werden. Falls erforderlich, kann eine Aufrüstung der Slave-Server-Konfiguration die Leistung verbessern.

Der nächste Abschnitt beleuchtet Replikationsprobleme detaillierter und bietet weitere Lösungen.

6. Häufige Probleme und ihre Lösungen

Während des MySQL-Replikationsbetriebs können verschiedene Probleme auftreten. Dieser Abschnitt erklärt häufige Probleme und wie man sie behebt. Frühe Erkennung von Problemen und Anwendung der richtigen Korrekturen hilft, einen stabilen Systembetrieb aufrechtzuerhalten.

1. Wenn Slave_IO_Running gestoppt ist

Symptom: Wenn Slave_IO_Running No in der Ausgabe von SHOW SLAVE STATUS anzeigt, kann der Slave keine Verbindung zum Master herstellen.

Ursachen und Lösungen:

  • Netzwerkprobleme : Wenn ein Netzwerkkonnektivitätsproblem vorliegt, kann der Slave den Master nicht erreichen. Überprüfen Sie Firewall-Einstellungen und stellen Sie sicher, dass der Master erreichbar ist.
  • Falscher Master-Hostname oder IP-Adresse : Überprüfen Sie, ob der in CHANGE MASTER TO angegebene Hostname oder die IP-Adresse korrekt ist.
  • Benutzerprivilegien-Probleme : Wenn der Replikationsbenutzer auf dem Master nicht ausreichend Privilegien hat, schlägt die Verbindung fehl. Stellen Sie sicher, dass die korrekten Privilegien mit GRANT REPLICATION SLAVE erteilt wurden.

2. Dateninkonsistenz auf dem Slave

Symptom: Wenn die Daten zwischen Master und Slave nicht übereinstimmen, kann der Slave in einen inkonsistenten Zustand geraten.

Ursachen und Lösungen:

  • Manuelle Datenausgleichung : Stoppen Sie den Slave, beheben Sie manuell die problematische Transaktion und starten Sie die Replikation dann neu. STOP SLAVE; # Daten reparieren falls notwendig START SLAVE;
  • Resynchronisation : Wenn die Inkonsistenz großflächig ist, erstellen Sie ein vollständiges Backup vom Master und synchronisieren Sie den Slave neu.

3. Replikationsverzögerung

Symptom: Wenn Seconds_Behind_Master nicht 0 in der Ausgabe von SHOW SLAVE STATUS ist, hinkt der Slave dem Master hinterher. Ideal sollte dieser Wert so nah wie möglich bei 0 liegen.

Ursachen und Lösungen:

  • Hardwarebeschränkungen des Slaves : Wenn der Slave-Server über unzureichende Ressourcen verfügt, kann er nicht mithalten. Eine Hardwareaufrüstung kann wirksam sein.
  • Abfrageoptimierung : Wenn Abfragen, die vom Master empfangen werden, zu lange auf dem Slave ausgeführt werden, kann eine Replikationsverzögerung entstehen. Das Hinzufügen von Indizes und die Optimierung von Abfragen können die Verarbeitungszeit reduzieren.

4. Replikationsbenutzerberechtigungsfehler

Symptom: Wenn Last_Error eine mit Berechtigungen zusammenhängende Meldung anzeigt, hat der Slave möglicherweise nicht ausreichend Privilegien, um sich mit dem Master zu verbinden.

Ursachen und Lösungen:

  • Neukonfiguration der Benutzerprivilegien : Stellen Sie sicher, dass auf dem Master ein Benutzer mit geeigneten Privilegien existiert. Konfigurieren Sie bei Bedarf neu. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. Wachstum der Binärlogs

Symptom: Die Binärlogs des Masters können übermäßig wachsen und Festplattenplatz verbrauchen.

Ursachen und Lösungen:

  • Binärlog-Rotation : Löschen oder archivieren Sie Binärlogs regelmäßig, um übermäßiges Wachstum zu verhindern. Durch Konfiguration von expire_logs_days können Sie Logs älter als eine bestimmte Periode automatisch entfernen. SET GLOBAL expire_logs_days = 7; # Logs älter als 7 Tage löschen

Indem Sie diese häufigen MySQL-Replikationsprobleme und ihre Lösungen verstehen, können Sie einen reibungsloseren Betriebsmanagement sicherstellen. Der nächste Abschnitt fasst Schlüsselpunkte für das Replikationsmanagement zusammen.

7. Schlussfolgerung

MySQL‑Replikation ist ein kritisches Feature zur Verbesserung der Datenkonsistenz und Systemzuverlässigkeit. In diesem Artikel haben wir alles von den grundlegenden Konzepten der MySQL‑Replikation bis hin zu Einrichtungsverfahren, Überwachungspraktiken und Fehlersuchmethoden behandelt. Nachfolgend finden Sie eine Zusammenfassung der wichtigsten Punkte für ein effektives Replikationsmanagement.

Wichtige Erkenntnisse

  1. Auswahl des richtigen Replikationstyps
  • Asynchrone Replikation bietet schnellere Reaktionszeiten und ist ideal für die Lastverteilung. Wenn jedoch Zuverlässigkeit Priorität hat, ist semi‑synchrone Replikation geeigneter. Wählen Sie basierend auf den Anforderungen Ihres Systems.
  1. Effektiver Einsatz von GTID
  • GTID eliminiert die Notwendigkeit, Binärlog‑Positionen anzugeben, und ermöglicht ein reibungsloses Transaktionsmanagement. Es ist besonders nützlich in Umgebungen mit mehreren Slaves oder wo Failover kritisch ist.
  1. Regelmäßige Statusüberwachung
  • Verwenden Sie SHOW MASTER STATUS und SHOW SLAVE STATUS, um regelmäßig den Betriebszustand von Master‑ und Slave‑Servern zu überwachen. Schnelles Handeln bei Erkennung von Anomalien minimiert Risiken wie Dateninkonsistenz oder Verzögerungen.
  1. Grundlegende Fehlersuche meistern
  • Häufige Replikationsprobleme umfassen Slave‑Verbindungsfehler, Dateninkonsistenzen und Verzögerungen. Das Verständnis grundlegender Lösungen für jedes Problem sorgt für reibungslosere Abläufe.
  1. Verwaltung von Binärlogs
  • Da Binärlogs erheblichen Speicherplatz beanspruchen können, wird empfohlen, expire_logs_days für die automatische Bereinigung zu konfigurieren und regelmäßige Wartung durchzuführen.

MySQL‑Replikation ist keine einmalige Einrichtung. Kontinuierliche Überwachung und ordnungsgemäße Wartung sind unerlässlich. Durch regelmäßige Überprüfung des Systemstatus und bei Bedarf Anpassung der Konfigurationen können Sie ein hochzuverlässiges Datenbanksystem aufbauen und erhalten.

Wir hoffen, dass Ihnen dieser Leitfaden hilft, MySQL‑Replikation besser zu verstehen und umzusetzen. Wir wünschen Ihnen reibungslose und stabile Replikationsabläufe.