Zusammenfassung der Verzögerungen der MySQL-Slave-Bibliothek „Seconds_Behind_Master“

Zusammenfassung der Verzögerungen der MySQL-Slave-Bibliothek „Seconds_Behind_Master“

1. Verzögerungsklassifizierung

Wir können die Latenz in zwei Kategorien unterteilen:

1. Die erste Kategorie (der Server ist stark ausgelastet)

Diese Art der Verzögerung kann zu einer höheren Belastung des Servers, möglicherweise auch der CPU-/E/A-Auslastung, führen. Da die Slave-Bibliothek das Ereignis tatsächlich ausführt, sollten wir diese Situationen berücksichtigen, wenn die Belastung unseres Servers hoch ist. Informationen zum Anzeigen der Belastung des Threads finden Sie in Abschnitt 29.

Die durch große Transaktionen verursachte Verzögerung beginnt nicht bei 0, sondern direkt mit der Dauer der Ausführung der Hauptdatenbank. Wenn die Hauptdatenbank beispielsweise 20 Sekunden benötigt, um diese Transaktion auszuführen, beginnt die Verzögerung bei 20 Sekunden, was durch sorgfältige Beobachtung leicht zu erkennen ist. Dies liegt daran, dass im Abfrageereignis keine genaue Ausführungszeit angegeben ist. Dies wird in der Berechnungsformel im vorherigen Abschnitt ausführlich beschrieben. Weitere Informationen finden Sie in den Abschnitten 8 und 27.

Die durch DDL großer Tabellen verursachte Verzögerung erhöht sich von 0, da das Abfrageereignis die genaue Ausführungszeit aufzeichnet. Dies wurde in der Berechnungsformel im vorherigen Abschnitt ausführlich beschrieben. Bitte beachten Sie die Abschnitte 8 und 27.

Die Tabelle verwendet Primärschlüssel oder eindeutige Schlüssel nicht richtig, was zu Verzögerungen führt. In diesem Fall sollten Sie nicht davon ausgehen, dass das Setzen des Parameters slave_rows_search_algorithms auf INDEX_SCAN, HASH_SCAN das Problem vollständig lösen kann. Der Grund wird in Abschnitt 24 beschrieben.

Dies wird durch unangemessene Parameter wie sync_relay_log, sync_master_info und sync_relay_log_info verursacht. Insbesondere sync_relay_log beeinträchtigt die Leistung der Slave-Bibliothek erheblich. Den Grund dafür haben wir in Abschnitt 26 beschrieben. Das Setzen von sync_relay_log auf 1 führt zu einer großen Anzahl von Leerungsvorgängen auf der Relay-Protokoll-Festplatte.

Überprüfen Sie, ob die Binärprotokollfunktion in der Slave-Datenbank aktiviert ist, d. h. ob der Parameter log_slave_updates aktiviert ist. Wenn er nicht benötigt wird, kann er deaktiviert werden. Ich bin schon oft in diese Situation geraten.

2. Die zweite Kategorie (verursacht keine hohe Belastung des Servers)

Diese Art der Verzögerung führt normalerweise nicht zu einer hohen Belastung des Servers. Entweder führen sie das Ereignis nicht wirklich aus oder sie werden durch spezielle Vorgänge verursacht.

• Langfristig nicht festgeschriebene Transaktionen können zu einer vorübergehenden Erhöhung der Latenz führen, da es sich bei GTID_EVENT und XID_EVENT um Festschreibungszeiten und bei anderen Ereignissen um Befehlsinitiierungszeiten handelt. Wir haben dies in Abschnitt 27 anhand von Beispielen beschrieben.
• Die durch die Zeilensperre der Innodb-Schicht verursachte Verzögerung entsteht, wenn eine Änderungsoperation an der Slave-Datenbank stattfindet und ein Konflikt mit den vom SQL-Thread geänderten Daten auftritt. Wie wir in Abschnitt 23 oben gesagt haben, startet der SQL-Thread auch eine Transaktion und erhält eine Zeilensperre, wenn ein Ereignis ausgeführt wird. Lassen Sie es uns unten testen.
• Die durch MDL LOCK auf der MySQL-Ebene verursachte Verzögerung kann dadurch verursacht werden, dass der SQL-Thread bestimmte DDL-Operationen ausführt, aber die Tabelle in der Datenbank sperrt. Der Grund wurde in Abschnitt 23 beschrieben. Lassen Sie es uns unten testen.
• Dies wird durch die unangemessene Einstellung des Parameters slave_checkpoint_period in MTS verursacht, die in Abschnitt 27 getestet wurde.
• Die Slave-Serverzeit wurde während des Slave-Betriebs manuell erhöht, was auch in Abschnitt 27 getestet wurde.

2. Verwandte Tests

Denn viele der oben genannten Verzögerungssituationen haben wir bereits getestet und beschrieben. Als nächstes testen wir die durch Sperren verursachten Verzögerungen.

1. Verzögerung durch Zeilensperren auf der Innodb-Ebene

Dies lässt sich leicht testen. Ich muss lediglich eine Transaktion in der Slave-Datenbank durchführen und dieselben Daten wie der SQL-Thread ändern. Der Test läuft wie folgt ab:

Aus der Bibliothek:
 
mysql> beginnen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
 
mysql> aus tmpk löschen;
Abfrage OK, 4 Zeilen betroffen (0,00 Sek.)
Senden Sie nicht dieselbe Anweisung an die Hauptdatenbank: mysql> delete from tmpk;
Abfrage OK, 4 Zeilen betroffen (0,30 Sek.)

An diesem Punkt werden Sie die folgende Verzögerung feststellen:

Wenn Sie sys.innodb_lock_waits überprüfen, können Sie die folgenden Ergebnisse sehen:

Wenn Sie INNODB_TRX überprüfen, können Sie natürlich auch das Vorhandensein von Transaktionen beobachten. Ich werde hier keinen Screenshot machen, Sie können es selbst ausprobieren.

2. Verzögerung durch MDL LOCK auf der MySQL-Ebene

Diese Situation lässt sich auch sehr einfach testen. Wir müssen nur eine Transaktion öffnen und eine Auswahl treffen. Anschließend führt die Hauptdatenbank DDL für dieselbe Tabelle aus. Die folgenden Ergebnisse werden angezeigt:

Aus der Bibliothek:
mysql> beginnen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
 
MySQL>
MySQL>
mysql> wähle * von tkkk-Limit 1;
+------+------+------+
| ein | b | c |
+------+------+------+
| 3 | 3 | 100 |
+------+------+------+
1 Zeile im Satz (0,00 Sek.)
 
Kein Commit, die MDL-Sperre für die Tabelle wird nicht freigegeben. Die Hauptdatenbank führt die Anweisung aus:
 
mysql> Tabelle ändern tmpk testc int hinzufügen;
Abfrage OK, 0 Zeilen betroffen (1,14 Sek.)
Datensätze: 0 Duplikate: 0 Warnungen: 0
 

Zu diesem Zeitpunkt werden Ihnen die folgenden Informationen angezeigt:

Wir können aus dem Status erkennen, dass dies die Verzögerung ist, die durch das Warten auf den Erwerb der MDL-Sperre verursacht wird. Weitere Informationen zur MDL-Sperre finden Sie im Artikel:

https://www.jb51.net/article/221412.htm

Abschluss

Während der gesamten Serie sollten wir uns über die Berechnungsmethode von Seconds_Behind_Master im Klaren sein. Wenn es zu einer Verzögerung kommt, prüfen wir zunächst, ob die Slave-Bibliothek ausgelastet ist, und behandeln sie je nachdem, ob sie ausgelastet ist, unterschiedlich. Beachten Sie, dass die Last hier top -H verwenden muss, um die Auslastung der IO/SQL/Worker-Threads anzuzeigen. Ich habe mehr als einmal Freunde getroffen, die mich nach Latenzproblemen gefragt haben. Als ich sie nach der Belastung fragte, sagten sie mir, dass die Belastung nicht hoch sei und die Gesamtbelastung weniger als 2 betrage. Was wir hier beachten sollten, ist, dass nur ein CPU-Kern für einen線程verwendet werden kann. Obwohl die Gesamtbelastung weniger als 2 beträgt, können die IO/SQL/Worker-Threads voll sein. Tatsächlich ist die Belastung bereits sehr hoch. Schauen wir uns den folgenden Screenshot an, der ein Screenshot des SQL-Threads mit hoher Belastung ist:

Aus diesem Screenshot können wir erkennen, dass die Gesamtlast zwar mit knapp über 1 nicht hoch ist, der Thread mit der Lwp-Nummer 20092 jedoch bereits vollständig geladen ist. Dieser線程ist unser SQL-Thread, und es ist sehr wahrscheinlich, dass es zu diesem Zeitpunkt zu einer Verzögerung kommt. Dieser Screenshot zeigt einen Fall einer Verzögerung, der durch die falsche Verwendung von Primärschlüsseln oder eindeutigen Schlüsseln verursacht wurde. Der Fall ist wie folgt:

https://www.jb51.net/article/221396.htm

Wir sollten top -H verwenden, um die CPU-Auslastung zu prüfen, und wir können iotop, iostat und andere Tools verwenden, um die IO-Auslastung zu prüfen. Ich muss betonen, dass wir die MySQL-Last aus der Perspektive der Threads betrachten müssen.

Oben sind die Details der Verzögerungszusammenfassung der MySQL-Slave-Bibliothek Seconds_Behind_Master. Weitere Informationen zur Verzögerungszusammenfassung der Slave-Bibliothek Seconds_Behind_Master finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!