Wie kann ich den Fehler „Waiting for the slave SQL thread to free enough relay log space“ in Amazon Aurora MySQL beheben?

Kurzbeschreibung

Wenn Aurora MySQL ein Replikat der Binärprotokoll-Replikation ist, werden der I/O-Thread und der SQL-Thread auf die gleiche Weise wie MySQL ausgeführt. Der I/O-Thread liest Binärprotokolle aus der primären Instance und speichert sie dann als Relay-Protokolle in der Replikat-DB-Instance. Der SQL-Thread verarbeitet die Ereignisse in den Relay-Protokollen und löscht dann die Relay-Protokolle, wenn die Ereignisse in den Relay-Protokollen verarbeitet werden.

Wenn der SQL-Thread Ereignisse nicht schnell genug verarbeitet, um mit der Geschwindigkeit Schritt zu halten, mit der die Relay-Protokolle generiert werden, nimmt die Anzahl der Relay-Protokolle zu.

Wenn die globale Variable relay_log_space_limit auf einen größeren Wert als 0 gesetzt ist und die Gesamtgröße aller Relay-Protokolle das Limit erreicht, werden keine neuen Relay-Protokolle gespeichert. Bis der Relay-Protokoll-Speicherplatz wieder verfügbar ist, zeigt die Ausgabe von SHOW SLAVE STATUS die Meldung „Wartet darauf, dass der Slave-SQL-Thread genug Relay-Protokoll-Speicherplatz freimacht“ im Feld Slave_IO_State.

In Aurora MySQL ist das relay_log_space_limit auf 1000000000 (953,6 MiB) gesetzt und kann nicht geändert werden. Dadurch wird verhindert, dass das Cluster-Volumen unnötig groß wird. Wenn die Gesamtgröße aller Relay-Protokolle 1000000000 Byte (953,6 MiB) erreicht, speichert der I/O-Thread keine Relay-Protokolle mehr. Er wartet darauf, dass der SQL-Thread Ereignisse verarbeitet und die vorhandenen Protokolle löscht. Slave\ _IO\ _State zeigt dann die Meldung „Wartet darauf, dass der Slave-SQL-Thread genug Relay-Protokoll-Speicherplatz freimacht“. Wenn der SQL-Thread nicht gestoppt wird, werden die Relay-Protokolle schließlich gelöscht, und der I/O-Thread setzt das Speichern neuer Relay-Protokolle fort.

Dies bedeutet auch, dass es zu einer Replikationsverzögerung kommt, weil SQL nicht schnell genug ist, um mit der Generierung von Relay-Protokollen durch den I/O-Thread Schritt zu halten. Selbst wenn relay\ _log\ _space\ _limit auf einen größeren Wert geändert wird, sammeln sich die Relay-Protokolle weiter an, und das Problem wird erst behoben, wenn der SQL-Thread aufgeholt hat.

Sie können die aktuelle Relay-Protokoll-Umgebung, den Status des I/O-Threads und den Status des SQL-Threads in der Ausgabe des Befehls SHOW SLAVE STATUS einsehen.

Slave_IO_State: Waiting for the slave SQL thread to free enough relay log space
Master_Log_File: mysql-bin-changelog.237029
Read_Master_Log_Pos: 55356151
Relay_Master_Log_File: mysql-bin-changelog.237023
Exec_Master_Log_Pos: 120
Relay_Log_Space: 1000002403

Master_Log_File und Read_Master_Log_Pos zeigen den Namen der Binärprotokolldatei und die Position, an der der I/O-Thread das Lesen und Speichern abgeschlossen hat. Relay_Master_Log_File und Exec_Master_Log_Pos zeigen den Namen der Binärprotokolldatei und die Position, an der der SQL-Thread verarbeitet. Was der SQL-Thread tatsächlich liest, sind zwar Relay-Protokolle, aber der entsprechende Binärprotokolldateiname in der primären DB Instance und die Position werden angezeigt.

Wenn sich Master_Log_File von Relay_Master_Log_File unterscheidet, ist der SQL-Thread nicht schnell genug. Wenn Master_Log_Fileund Relay_Master_Log_File identisch sind, trägt der I/O-Thread möglicherweise zur Verzögerung bei.

Die folgenden Faktoren können zu einer unzureichenden Leistung des SQL-Threads führen:

• Lang andauernde Abfragen auf der primären DB Instance
• Unzureichende DB-Instance-Klassengröße oder unzureichender Speicherplatz
• Parallele Abfragen, die auf der primären DB Instance ausgeführt werden
• Binärprotokolle, die mit der Festplatte auf der Replikat-DB-Instance synchronisiert werden
• Binlog\ _format auf der Replikat-DB-Instance ist auf ROW gesetzt

Weitere Informationen zur Lösung dieser Probleme finden Sie unter Wie kann ich eine hohe Replikat-Verzögerung mit Amazon RDS für MySQL beheben?

Darüber hinaus können die folgenden Faktoren die Leistung des SQL-Threads beeinflussen:

• Eine sehr große Transaction History List Length (HLL) auf der Replikat-DB-Instance
• Ineffiziente I/O-Operationen auf der Replikat-DB-Instance
• Tabellen mit vielen sekundären Indizes auf der Replikat-DB-Instance

Behebung

Solange in Ihrem Replikat Schreibvorgänge stattfinden, müssen Sie sich keine Gedanken über den Speicherplatz im Relay-Protokoll machen. Sie können dies mithilfe der Metrik „Schreibdurchsatz“ in Enhanced Monitoring überwachen.

Konzentrieren Sie sich stattdessen auf die Fehlerbehebung bei der Leistung des Replikats. Weitere Informationen finden Sie unter Wie kann ich eine hohe Replikat-Verzögerung mit Amazon RDS für MySQL beheben und Warum ist mein Amazon-Aurora-Lesereplikat in Verzug geraten und neu gestartet worden?

---

Weitere Informationen

MySQL-Dokumentation für Replikat-Serveroptionen und Variablen