Detaillierte Analyse des MySQL Master-Slave-Verzögerungsphänomens und -prinzips

1. Phänomen

Am frühen Morgen wurde einer Online-Tabelle ein Index hinzugefügt. Die Datenmenge in der Tabelle war zu groß (über 100 Millionen Daten, mehr als 50 G Daten), was zu einer Verzögerung von mehreren Stunden zwischen Master und Slave führte. Die Systeme, die von der Slave-Datenbank abhängig waren, konnten die Daten nicht abfragen, was letztendlich das Geschäft beeinträchtigte.

Lassen Sie uns nun das Prinzip der Master-Slave-Verzögerung klären.

2. Grundsatz

Gemäß der Beschreibung im offiziellen MySQL-Dokument „MySQL Replication Implementation Details“ basiert die MySQL Master-Slave-Replikation auf drei Threads: einem Thread für master ( Binlog dump thread ) und zwei Threads slave ( I/O thread und SQL thread ). Der Master-Slave-Replikationsprozess läuft wie folgt ab:

Wenn der Master-Server und der Slave-Server verbunden sind, erstellen Sie Binlog dump thread um bin log Daten zu senden:

• Ein Binlog dump thread entspricht einem Slave-Server;
• Binlog dump thread sperrt die Daten beim Abrufen aus bin log und gibt die Sperre sofort nach dem Abrufen der Daten frei.

Wenn der Slave-Server den Befehl START_SLAVE empfängt, erstellt er I/O thread und SQL thread :

• I/O thread liest im Pull-Verfahren Ereignisse vom Master und speichert sie im relay log des Slave-Servers.
• SQL thread liest Ereignisse aus relay log und führt sie aus;
• slave kann Daten in seinem eigenen Tempo lesen und aktualisieren und kann auch den Replikationsprozess (Starten und Stoppen) nach Belieben steuern.

Hinweis: Wenn der Befehl START_SLAVE den Thread erfolgreich gestartet hat und der nachfolgende I/O thread oder SQL thread aus irgendeinem Grund stoppt, erfolgt keine Warnung und der Geschäftspartner wird davon nichts mitbekommen. Sie können das Fehlerprotokoll des Slaves anzeigen oder mit dem Befehl SHOW SLAVE STATUS den Thread-Status auf dem Slave anzeigen.

Sie können den Thread-Status über SHOW PROCESSLIST anzeigen:

Binlog-Dump-Thread:

mysql> PROZESSLISTE ANZEIGEN\G
*************************** 1. Reihe ***************************
  ID: 2
 Benutzer: root
 Gastgeber: localhost:32931
  db: NULL
Befehl: Binlog Dump
 Zeit: 94
 Status: Hat das gesamte Binärprotokoll an den Slave gesendet; warte auf Binärprotokoll
   aktualisiert werden
 Info: NULL

E/A-Thread und SQL-Thread:

mysql> PROZESSLISTE ANZEIGEN\G
*************************** 1. Reihe ***************************
  ID: 10
 Benutzer: Systembenutzer
 Gastgeber:
  db: NULL
Befehl: Verbinden
 Zeit: 11
 Status: Wartet darauf, dass der Master ein Ereignis sendet
 Info: NULL
 *************************** 2. Reihe ***************************
  ID: 11
 Benutzer: Systembenutzer
 Gastgeber:
  db: NULL
Befehl: Verbinden
 Zeit: 11
 Status: Alle Relay-Logs gelesen; wartet auf den Slave-E/A
   Thread, um es zu aktualisieren
 Info: NULL

Analyse

Da gemäß dem obigen Prinzip slave Daten mit einem einzigen Thread ( I/O thread ) liest und Daten mit einem einzigen Thread ( SQL thread ) aktualisiert, während master Daten mit mehreren Threads schreibt, kann es zu einer Master-Slave-Verzögerung kommen, solange master häufiger schreibt als slave liest und aktualisiert, beispielsweise:

1. master Schreib- tps des Masters ist höher als slave .
2. Für die Ausführung bestimmter Anweisungen, wie beispielsweise das Halten von Sperren, benötigt slave viel Zeit.
3. Wenn master bestimmte DDL -Anweisungen ausführt, ist die Ausführungszeit länger, und slave führt sie auch in der gleichen Zeit aus.

Hier wird ein Index erstellt. Nach Rücksprache mit dem DBA wird festgestellt, dass die generierte bin log über 100 GB groß ist. Das Datenvolumen ist zu groß, was dazu führt, dass der I/O thread der Slave-Bibliothek weiterhin die vom DDL Vorgang generierten bin log liest, was sich auf die Aktualisierung normaler geschäftlicher DML Ereignisse auswirkt und zu einer Verzögerung der Master-Slave-Synchronisierung führt.

4. Lösung

Aus Sicht der Ursachen der Master-Slave-Verzögerung kann die Lösung aus den folgenden Richtungen begonnen werden:

1. Geschäftsauswahl: Für Architekturen, die keine Verzögerungen bei Slave-Datenbanken tolerieren können, können Sie eine verteilte Architektur wählen, um Verzögerungsprobleme bei Slave-Datenbanken zu vermeiden.
2. Ausführungszeit: Wählen Sie für Online- DDL Operationen an großen Tabellen möglichst die frühen Morgenstunden, wenn das Geschäftsaufkommen gering ist.
3. Hardwarekonfiguration, Upgrade der Slave-Hardwarekonfiguration, z. B. SSD
4. Reduzieren Sie Anfragen, erhöhen Sie die Cache-Ebenen und verringern Sie die Anzahl der verlorenen Leseanfragen

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an