Wie kann ich hohe Replikatverzögerungen mit Amazon RDS für MySQL beheben?

Kurzbeschreibung

Amazon RDS für MySQL verwendet asynchrone Replikation. Das bedeutet, dass das Replikat manchmal nicht in der Lage ist, mit der primären DB-Instance Schritt zu halten. Infolgedessen kann es zu einer Replikationsverzögerung kommen.

Um die Replikationsverzögerung zu überwachen, verwenden Sie ein Amazon RDS für MySQL Read Replica mit positionsbasierter Replikation in binären Protokolldateien.

Überprüfen Sie in Amazon CloudWatch die Metrik ReplikatVerzögerung für Amazon RDS. Die Metrik ReplikatVerzögerung gibt den Wert des Felds Sekunden_Dahinter_Master des Befehls ANZEIGEN SLAVE STATUS an.

Das Feld Sekunden_Dahinter_Master zeigt den Unterschied zwischen dem aktuellen Zeitstempel auf der Replikat-DB-Instance. Es zeigt auch den ursprünglichen Zeitstempel an, der auf der primären DB-Instance für die Ereignisverarbeitung auf der Replikat-DB-Instance protokolliert wurde.

Die MySQL-Replikation arbeitet mit drei Threads: dem Binlog Dump-Thread, dem IO_FADEN und dem SQL_FADEN. Weitere Informationen zur Funktionsweise dieser Threads finden Sie in der MySQL-Dokumentation für Replikations-Fäden. Wenn es bei der Replikation zu einer Verzögerung kommt, stellen Sie fest, ob das Replikat IO_FADEN oder das Replikat SQL_FADEN die Verzögerung verursacht. Dann können Sie die Ursache für die Verzögerung ermitteln.

Auflösung

In den folgenden Beispielen erfahren Sie, welcher Replikationsthread verzögert ist:

1.Führen Sie den Befehl ANZEIGEN MASTER STATUS auf der primären DB-Instance aus und überprüfen Sie die Ausgabe. Die Ausgabe sieht ähnlich wie die folgende aus:

mysql> SHOW MASTER STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.066552|      521 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Hinweis: In der Beispielausgabe schreibt die Quell- oder primäre DB-Instance die binären Protokolle in die Datei mysql-bin.066552.

2.    Führen Sie den Befehl ANZEIGEN SLAVE STATUS auf der Replikat-DB-Instance aus und überprüfen Sie die Ausgabe. Die Ausgabe sieht den folgenden Beispielen ähnlich:

Beispiel 1:

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Master_Log_File: mysql-bin.066548
Read_Master_Log_Pos: 10050480
Relay_Master_Log_File: mysql-bin.066548
Exec_Master_Log_Pos: 10050300
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

In Beispiel 1 gibt der Meister_Log_Datei: mysql-bin.066548 an, dass das Replikat IO_FADEN aus der binären Protokolldatei mysql-bin.066548 liest. Die primäre DB-Instance schreibt die binären Protokolle in die Datei mysql-bin.066552. Diese Ausgabe zeigt, dass das Replikat IO_FADEN um vier binären Protokolle hinterherhinkt. Die Relais_Meister_Log_Datei ist jedoch mysql-bin.066548, was darauf hinweist, dass das Replikat SQL_FADEN aus derselben Datei liest wie der IO_FADEN. Dies bedeutet, dass das Replikat SQL_FADEN Schritt hält, aber das Replikat IO_FADEN eine Verzögerung aufweist.

Beispiel 2:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Master_Log_File: mysql-bin.066552
Read_Master_Log_Pos: 430
Relay_Master_Log_File: mysql-bin.066530
Exec_Master_Log_Pos: 50360
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Beispiel 2 zeigt, dass die Protokolldatei der primären Instance mysql-bin-changelog.066552 ist. Die Ausgabe zeigt, dass IO_FADEN mit der primären DB-Instance Schritt hält. In der Replikatausgabe führt der SQL-Thread Relais_Meister_Log_Datei: mysql-bin-changelog.066530 aus. Infolgedessen hinkt SQL_FADEN 22 binären Protokollen hinterher.

Normalerweise verursacht IO_FADEN keine großen Replikationsverzögerungen, da IO_FADEN nur die binären Protokolle von der primären oder Quell-Instance liest. Netzwerkkonnektivität und Netzwerklatenz können sich jedoch auf die Geschwindigkeit der Lesevorgänge zwischen den Servern auswirken. Das Replikat IO_FADEN arbeitet aufgrund der hohen Bandbreitennutzung möglicherweise langsamer.

Wenn das Replikat SQL_FADEN die Ursache für Replikationsverzögerungen ist, können die folgenden Situationen zu Verzögerungen führen:

• Abfragen mit langer Ausführungszeit auf der primären DB-Instance
• Unzureichende Größe oder unzureichender Speicher der DB-Instance-Klasse
• Parallele Abfragen werden auf der primären DB-Instance ausgeführt
• Binäre Protokolle, die mit der Festplatte auf der Replikat-DB-Instance synchronisiert werden
• Binlog_Format auf dem Replikat ist auf ROW gesetzt
• Verzögerung bei der Replikaterstellung

Abfragen mit langer Ausführungszeit auf der primären Instance

Abfragen mit langer Ausführungszeit auf der primären DB-Instance, deren Ausführung auf der Replikat-DB-Instance die gleiche Zeit in Anspruch nimmt, können die Anzahl der Sekunden_Dahinter_Meister erhöhen. Wenn Sie beispielsweise eine Änderung auf der primären Instance initiieren und die Ausführung eine Stunde dauert, beträgt die Verzögerung eine Stunde. Wenn die Änderung auch auf dem Replikat eine Stunde dauert, beträgt die Gesamtverzögerung zum Zeitpunkt der Fertigstellung etwa zwei Stunden. Dies ist eine erwartete Verzögerung, aber Sie können diese Verzögerung minimieren, indem Sie das Protokoll für langsame Abfragen auf der primären Instance überwachen. Sie können auch Aussagen mit langer Laufzeit identifizieren, um Verzögerungen zu reduzieren. Unterteilen Sie dann langlaufende Anweisungen in kleinere Anweisungen oder Transaktionen.

Unzureichende Größe oder unzureichender Speicher der DB-Instance-Klasse

Wenn die Replikat-DB-Instance-Klasse oder Speicherkonfiguration niedriger als die primäre ist, kann es sein, dass das Replikat aufgrund unzureichender Ressourcen gedrosselt wird. Dies liegt daran, dass das Replikat nicht mit den Änderungen Schritt halten kann, die an der primären Instance vorgenommen wurden. Stellen Sie sicher, dass der DB-Instance-Typ des Replikats dem der primären DB-Instance entspricht oder höher ist. Damit die Replikation effektiv funktioniert, benötigt jede Read Replica dieselbe Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance. Weitere Informationen finden Sie unter DB-Instance-Klassen.

Parallele Abfragen werden auf der primären DB-Instance ausgeführt

Wenn Sie Abfragen parallel auf der Primärseite ausführen, werden sie in serieller Reihenfolge auf das Replikat übertragen. Dies liegt daran, dass die MySQL-Replikation standardmäßig mit einem einzigen Faden (SQL_FADEN) ausgeführt wird. Wenn ein hohes Volumen an Schreibvorgängen in die Quell-DB-Instance parallel erfolgt, werden die Schreibvorgänge in die Read Replica serialisiert. Die Schreibvorgänge in die Read Replica verwenden einen einzigen SQL_FADEN zur Serialisierung. Dies kann zu einer Verzögerung zwischen der Quell-DB-Instance und dem Read Replica führen.

Die (parallele) Multithread-Replikation ist für MySQL 5.6, MySQL 5.7 und höhere Versionen verfügbar. Weitere Informationen zur Multithread-Replikation finden Sie in der MySQL-Dokumentation zu Binären Protokollierungsoptionen und Variablen.

Die Replikation mit mehreren Threads kann zu Replikationslücken führen. Die Replikation mit mehreren Threads ist beispielsweise keine optimale Methode, um Replikationsfehler zu überspringen, da es schwierig ist, zu erkennen, welche Transaktionen Sie überspringen. Dies kann zu Lücken in der Datenkonsistenz zwischen der primären und der replizierten DB-Instance führen.

Binäre Protokolle, die mit der Festplatte auf der Replikat-DB-Instance synchronisiert werden

Das Aktivieren automatischer Backups auf dem Replikat kann zu einem Mehraufwand für die Synchronisierung der binären Protokolle mit der Festplatte auf dem Replikat führen. Der Standardwert des Parameters sync_binlog ist auf 1 gesetzt. Wenn Sie diesen Wert auf 0 ändern, schalten Sie auch die Synchronisation des binären Protokolls auf die Festplatte durch den MySQL-Server aus. Anstatt auf die Festplatte zu protokollieren, leert das Betriebssystem (OS) gelegentlich die binären Protokolle auf die Festplatte.

Das Deaktivieren der binären Protokollsynchronisierung kann den Leistungsaufwand reduzieren, der erforderlich ist, um die binären Protokolle bei jeder Übernahme mit der Festplatte zu synchronisieren. Aber wenn es einen Stromausfall gibt oder das Betriebssystem abstürzt, werden einige der Übernahmen möglicherweise nicht mit den binären Protokollen synchronisiert. Diese Asynchronisierung kann sich auf die Features zur Point-in-Time-Wiederherstellung (PITR) auswirken. Weitere Informationen finden Sie in der MySQL-Dokumentation für sync_binlog.

Binlog_format ist auf RUDERN gesetzt

Der SQL-Thread führt bei der Replikation einen vollständigen Tabellenscan durch, wenn diese beiden Faktoren zutreffen:

• Das binlog_Format auf der primären DB-Instance ist auf RUDERN gesetzt.
• In der Quelltabelle fehlt ein Primärschlüssel.

Dies liegt daran, dass der Standardwert des Parameters Sklave_Rudern_Suchen_Algorithmen TABELLE_SCAN,INDEX_SCAN ist.

Um dieses Problem kurzfristig zu lösen, ändern Sie den Suchalgorithmus auf INDEX_SCAN,HASH_SCAN, um den Aufwand für den vollständigen Tabellenscan zu reduzieren. Langfristig empfiehlt es sich, jeder Tabelle einen expliziten Primärschlüssel hinzuzufügen.

Weitere Informationen zum Parameter Sklave-Rudern-Suchen-Algorithmen finden Sie in der MySQL-Dokumentation für Sklave_Redern_Suchen_Algorithmen.

Verzögerung bei der Replikaterstellung

Amazon RDS erstellt einen DB-Snapshot, um eine Read Replica einer primären MySQL-Instance zu erstellen. Anschließend stellt Amazon RDS den Snapshot wieder her, um eine neue DB-Instance (Replikat) zu erstellen, und stellt eine Replikation zwischen den beiden her.

Amazon RDS benötigt Zeit, um neue Read Replicas zu erstellen. Nach dem Einrichten der Replikation kommt es zu einer Verzögerung für die Dauer der Erstellung eines Backups der primären DB-Instance. Um diese Verzögerung zu minimieren, erstellen Sie ein manuelles Backup, bevor Sie die Replikaterstellung aurufen. Dann ist der DB-Snapshot ein inkrementelles Backup.

Wenn Sie ein Read Replica aus einem Snapshot wiederherstellen, wartet das Replikat nicht darauf, dass alle Daten von der Quelle übertragen wurden. Die Replikat-DB-Instance ist für die Ausführung der DB-Operationen verfügbar. Das neue Volume wird aus vorhandenen Snapshot-Ladungen von Amazon Elastic Block Store (Amazon EBS) im Hintergrund erstellt.

Hinweis: Bei Amazon RDS für MySQL-Replikaten (EBS-basierte Volumes) kann die Replikatverzögerung zunächst zunehmen. Dies liegt daran, dass der Lazy-Loading-Effekt die Replikationsleistung beeinflussen kann.

Um die Auswirkungen des Lazy Loading auf Tabellen für Ihre neu erstellte Read Replica zu mildern, können Sie Operationen ausführen, die vollständige Tabellenscans beinhalten. Führen Sie beispielsweise eine Operation mysqldump auf Ihrer Read Replica für bestimmte Tabellen oder Datenbanken aus. Dadurch kann Amazon RDS alle gesicherten Tabellendaten aus Amazon Simple Storage Service (Amazon S3) priorisieren und herunterladen.

Erwägen Sie auch, die InnoDB-Cache-Warming-Funktion „auf Abruf“ zu verwenden. Die InnoDB-Cache-Warming-Funktion speichert den Status des Pufferpools auf der Festplatte in einer Datei namens ib_buffer_pool im Datenverzeichnis InnoDB. Dies kann zu Leistungssteigerungen führen, indem der aktuelle Status des Pufferpools der primären DB-Instance gelöscht wird, bevor die Read Replica erstellt wird. Laden Sie dann den Pufferpool neu, nachdem Sie eine Read Replica erstellt haben.

Ähnliche Informationen

Arbeiten mit der MySQL-Replikation in Amazon RDS

Arbeiten mit MySQL Read Replicas