Wie behebe ich Probleme, die dazu führen, dass meine Aurora-Lesereplikate sich verzögern und neu gestartet werden?

Behebung

Hinweis: Die folgende Lösung gilt für Aurora-Cluster in einer einzelnen AWS-Region und für primäre globale Datenbank-Cluster, nicht für sekundäre globale Datenbank-Cluster.

AuroraReplicaLag messen

Aurora-Replikate stellen eine Verbindung zu demselben Speichervolumen her wie die Writer-Instance. Aurora schreibt synchron Änderungen auf das gemeinsam genutzte Speicher-Volume, repliziert jedoch asynchron Änderungen an den Reader-Instances. Aus Gründen der Lesekonsistenz macht Aurora Daten ungültig, die im Speicher zwischengespeichert sind und sich auf die Änderung beziehen. Der Datencache umfasst den Pufferpool oder den Seitencache.

In einigen Fällen kann es zu einer Verzögerung kommen, wenn du Änderungen auf die Reader-Instances überträgst. Die Verzögerung zeigt sich in einer Erhöhung der AuroraReplicaLag-Metrik in Amazon CloudWatch, was zu Neustarts führen kann. Möglicherweise erhältst du die folgende Fehlermeldung:

„Read Replica has fallen behind the master too much. Restarting“.

Führe für die Amazon Aurora MySQL-Compatible Edition die folgende Abfrage in der Tabelle INFORMATION_SCHEMA.REPLICA_HOST_STATUS aus, um AuroraReplicaLag zu messen:

select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID', 'writer', 'reader') as Role, replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

Beispielausgabe:

+---------------------+--------+-------------------+  
| Instance_Identifier | Role   | AuroraReplicaLag  |  
+---------------------+--------+-------------------+  
| myamscluster-aza-1  | writer |                 0 |  
| myamscluster-azb-1  | reader | 5.150000095367432 |  
| myamscluster-aza-2  | reader | 5.033999919891357 |  
+---------------------+--------+-------------------+

Führe für die Amazon Aurora PostgreSQL-Compatible Edition die folgende Abfrage aus, um die Funktion aurora_replica_status() abzurufen und die Ergebnisse zu filtern:

select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

Beispielausgabe:

server_id          | role   | aurorareplicalag  
-------------------+--------+------------------  
myapgcluster-aza-1 | Reader | 19.641  
myapgcluster-azb-1 | Reader | 19.752  
myapgcluster-aza-2 | Writer |  
(3 rows)

Sicherstellen, dass alle Instances im Cluster dieselbe Spezifikation haben

Wenn eine Reader-Instance eine niedrigere DB-Instance-Klassenkonfiguration als eine Writer-DB-Instance hat, ist die Anzahl der Änderungen möglicherweise zu groß. Dann kann die Reader-Instance im Cache nicht ungültig werden. Um dieses Problem zu vermeiden, empfiehlt es sich, für alle DB-Instances im Aurora-Cluster dieselbe Spezifikation beizubehalten.

Sitzungen mit Metriken und Enhanced Monitoring überwachen

Wenn du mehrere Sitzungen gleichzeitig ausführst, kann es bei einer Reader-Instance zu Verzögerungen kommen. Ein Aurora-Replikat könnte langsam die notwendigen Änderungen vom Writer übernehmen, weil es an verfügbaren Ressourcen mangelt. Um nach Verzögerungen zu suchen, sieh dir die Metriken CPUUtilization, DBConnections und NetworkReceiveThroughput an. Du kannst Enhanced Monitoring auch mit einer Granularität von 1 oder 5 Sekunden aktivieren, um die Ressourcennutzung auf dem Reader zu ermitteln. Oder aktiviere Performance Insights und verwende Database Insights, um die Arbeitslast des Readers zu visualisieren. Für Aurora PostgreSQL-Compatible kannst du die ReadIOPS-Metrik verwenden.

Wichtig: Performance Insights wird am 30. Juni 2026 das Ende seiner Lebensdauer erreichen. Du kannst vor dem 30. Juni 2026 ein Upgrade auf den Modus „Erweitert“ von Database Insights durchführen. Wenn du kein Upgrade durchführst, verwenden DB-Cluster, die Performance Insights verwenden, standardmäßig den Modus „Standard“ von Database Insights. Nur der Modus „Erweitert“ von Database Insights unterstützt Ausführungspläne und On-Demand-Analysen. Wenn die Cluster standardmäßig auf den Modus „Standard“ eingestellt sind, kannst du diese Funktionen möglicherweise nicht auf der Konsole verwenden. Informationen zum Aktivieren des Modus „Erweitert“ findest du unter Aktivieren des Modus „Erweitert“ von Database Insights für Amazon RDS und Aktivieren des Modus „Erweitert“ von Database Insights für Amazon Aurora.

CloudWatch verwenden, um Schreibaktivitäten zu visualisieren

Ein plötzlicher Anstieg der Schreibaktivitäten in einem bereits schreibintensiven Produktions-Cluster kann die Writer-DB-Instance überlasten. Die Überlastung kann dazu führen, dass Reader-Instances verzögert werden. Verwende CloudWatch, um die Metriken DMLThroughput, DDLThroughput und Queries anzuzeigen, die plötzliche Bursts anzeigen. Sieh dir für Aurora PostgreSQL-Compatible die Metrik WriteThroughput an.

Problembehandlung bei Transaktionen mit langer Laufzeit für Aurora MySQL-Compatible

Die MySQL InnoDB-Engine verwendet standardmäßig Multi-Version Concurrency Control (MVCC). Du musst also alle Änderungen an Zeilen verfolgen, die während der gesamten Dauer einer Transaktion vorgenommen wurden. Nach Abschluss lang andauernder Transaktionen beginnt ein Anstieg der Aktivität im Bereinigungs-Thread. Die plötzliche Bereinigung kann dazu führen, dass sich ein Aurora-Replikat aufgrund des großen Backlogs, das durch langandauernde Transaktionen entsteht, verzögert.

Überprüfe für Aurora MySQL-Compatible die Metrik RollbackSegmentHistoryListLength in CloudWatch, um den Anstieg beim Löschen zu sehen. Du kannst den Befehl SHOW ENGINE INNODB STATUS ausführen, um die Bereinigung anzuzeigen. Oder führe die folgende Abfrage aus:

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

Beispielausgabe:

+----------------------------------+-------+  
| RollbackSegmentHistoryListLength | COUNT |  
+----------------------------------+-------+  
| trx_rseg_history_len             |   358 |  
+----------------------------------+-------+  
1 row in set (0.00 sec)

Richte CloudWatch-Alarme ein, um RollbackSegmentHistoryListLength zu überwachen, um sicherzustellen, dass keine hohe Zahl erreicht wird. Es ist eine bewährte Methode, lang andauernde Transaktionen in relationalen Datenbanken zu vermeiden.

Kurze Netzwerkunterbrechungen vermeiden

Obwohl sie selten auftreten, können vorübergehende Netzwerkkommunikationsfehler zwischen den Writer- und Reader-Instances oder zwischen einer Instance und der Aurora-Speicherschicht auftreten. Reader-Instances können aufgrund einer kurzen Netzwerkunterbrechung verzögert oder neu gestartet werden. Das Aurora-Replikat kann auch verzögert werden, da eine große Anzahl von Änderungen die Netzwerkbandbreite der Instance überlastete. Um dieses Problem zu vermeiden, empfiehlt es sich, die Größe der DB-Instance auf eine Größe zu ändern, die die Anzahl der Änderungen bewältigen kann.

Ähnliche Informationen

Hinzufügen von Aurora-Replikaten zu einem DB Cluster

Replikation mit Amazon Aurora MySQL-Compatible

Überwachung von Metriken in einem Amazon-Aurora-Cluster

Metriken auf Instance-Ebene für Amazon Aurora