Warum ist mein Amazon Aurora-Lesereplikat zurückgefallen und wurde neu gestartet?

Kurzbeschreibung

AuroraReplicaLag ist ein Maß für die Verzögerung in Millisekunden bei der Replikation von Änderungen von der Writer-Aurora-DB-Instance auf die Reader-Instances in einem Aurora-DB-Cluster. Aurora-Repliken stellen eine Verbindung zu demselben Speichervolumen her wie die Writer-Instance. Um die Verzögerung zwischen den Writer- und Reader-Instances zu messen, verwenden Sie die Metrik AuroraReplicaLag in Amazon CloudWatch.

Für einen Aurora-DB-Cluster gibt die AuroraReplicaLag-Metrik die Verzögerung für den Datencache der Aurora-Replik im Vergleich zur Writer-DB-Instance an. Der Datencache umfasst den Pufferpool oder den Seitencache. Änderungen werden synchron auf das gemeinsam genutzte Speichervolumen geschrieben. Änderungen werden jedoch asynchron auf die Reader-Instances repliziert, wobei alle im Speicher zwischengespeicherten Daten, die sich auf die Änderung beziehen, aus Gründen der Lesekonsistenz ungültig gemacht werden. In einigen Fällen kann es zu Verzögerungen bei der Übertragung von Änderungen auf die Reader-Instances kommen. Diese Verzögerung spiegelt sich in einer Erhöhung der AuroraReplicaLag-Metrik in CloudWatch wider, was zu eventuellen Neustarts führen kann.

Sie können Metadaten über AuroraReplicaLag nahezu in Echtzeit messen:

Treffen Sie für die Amazon Aurora MySQL-kompatible Edition eine Auswahl in der Tabelle INFORMATION_SCHEMA.REPLICA_HOST_STATUS:

mysql> 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;

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

Rufen Sie für die Amazon Aurora PostgreSQL-kompatible Edition die Funktion aurora_replica_status() auf und filtern Sie die Ergebnisse:

postgres=> 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();

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

Hinweis: Die in diesem Artikel bereitgestellte Lösung gilt für Amazon Aurora-Primärcluster mit einer Region und Global Database-Primärcluster, jedoch nicht für sekundäre Global Database-Cluster.

Lösung

Stellen Sie sicher, dass alle Instances im Cluster dieselbe Spezifikation haben

Wenn eine Reader-Instance eine schwächere DB-Instance-Klassenkonfiguration hat als eine Writer-DB-Instance, ist das Änderungsvolumen möglicherweise zu groß. In diesem Fall kann die Reader-Instance nicht im Cache ungültig werden und dann aufholen. Daher hat es sich bewährt, dass alle DB-Instances im Aurora-Cluster über dieselbe Spezifikation verfügen.

Überwachen Sie Sitzungen mithilfe von Metriken und erweiterter Überwachung

Bei einer Reader-Instance kann es zu Verzögerungen kommen, wenn mehrere Sitzungen gleichzeitig ausgeführt werden. Ein Aurora-Replikat übernimmt die vom Autor stammenden, notwendigen Änderungen möglicherweise nur langsam, da es an verfügbaren Ressourcen mangelt. Sie können diese Verzögerung bei Metriken wie CPUUtilization, DBConnections und NetworkReceiveThroughput erkennen. Sie können zudem die Erweiterte Überwachung mit einer Genauigkeit von 1 oder 5 Sekunden aktivieren, um die Ressourcennutzung auf dem Reader zu ermitteln. Darüber hinaus können Sie die Performance Insights verwenden, um den Workload zu visualisieren. Exklusiv für Aurora PostgreSQL-Compatible kann zu dem die Metrik ReadIOPS verwendet werden.

Visualisieren Sie Schreibaktivitäten mit CloudWatch

Ein plötzlicher Anstieg der Schreibaktivität in einem bereits schreibintensiven Produktionscluster kann zu einer Überlastung der Writer-DB-Instance führen. Der zusätzliche Stress, der durch den Anstieg verursacht wird, kann dazu führen, dass eine oder mehrere Reader-Instances zurückfallen. Sie können dies in CloudWatch beobachten, wenn plötzliche Anstiege der Metriken DMLThroughput, DDLThroughput und Queries zu sehen sind.

Für Aurora PostgreSQL können Sie dies in der Metrik WriteThroughput sehen.

Überprüfen Sie die ständige wachsende Länge der Verlaufslisten (HLL) (Aurora MySQL-Compatible)

Die MySQL InnoDB-Engine enthält standardmäßig Multi-Version Concurrency Control (MVCC). Das bedeutet, dass Sie alle Änderungen nachverfolgen müssen, die in allen betroffenen Zeilen während der gesamten Dauer einer Transaktion vorgenommen wurden. Nachdem lang andauernde Transaktionen abgeschlossen wurden, beginnt ein Anstieg der Purge-Thread-Aktivität. Aufgrund des hohen Backlogs, der durch Transaktionen mit langer Laufzeit entsteht, kann die plötzliche Bereinigung dazu führen, dass ein Aurora-Replikat zurückfällt.

In den Versionen 1.19.2, 2.06 und höher enthält Aurora MySQL die Metrik RollbackSegmentHistoryListLength. Sie können diese Metrik in CloudWatch verwenden, um diesen Löschvorgang zu beobachten. Dieser ist zudem in der Ausgabe von SHOW ENGINE INNODB STATUS ersichtlich oder wenn das Informationsschema wie folgt abgefragt wird:

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

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

Richten Sie CloudWatch-Alarme ein, um diese Metrik zu überwachen, damit sie keine zu hohen Werte erreicht. Bei relationalen Datenbanken hat es sich bewährt, lang andauernde Transaktionen zu vermeiden.

Vermeiden Sie kurze Netzwerkunterbrechungen

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 zurückfallen oder neu gestartet werden. Die Aurora-Replik kann auch aufgrund der Überlastung der Netzwerkbandbreite der Instance aufgrund eines großen Änderungsvolumens zurückfallen. Es hat sich bewährt, die Größe der DB-Instance und damit ihre Netzwerkkapazitäten zu berücksichtigen, um dieses Problem zu vermeiden.

---

Ähnliche Informationen

Hinzufügen von Aurora-Replikaten zu einem DB-Cluster

Single-Master-Replikation mit Amazon Aurora MySQL

Überwachung von Metriken in einem Amazon Aurora-Cluster