Wie kann ich häufig auftretende Probleme bei der Verwendung von Lesereplikaten in Amazon Aurora lösen?

Lesedauer: 4 Minute
0

Ich habe eine Amazon Aurora MySQL-DB-Instance und ich habe Probleme bei der Arbeit mit Lesereplikaten. Wie kann ich häufig auftretende Probleme bei der Verwendung von Lesereplikaten mit Amazon Aurora beheben?

Kurzbeschreibung

Amazon Aurora MySQL unterstützt Lesereplikate, die sich ein gemeinsames zugrunde liegendes Volumen mit einer Writer-DB-Instance in derselben AWS-Region teilen. Wenn Sie Ihre Writer-DB-Instance ändern, sind die Updates für Replikat-Instances im DB-Cluster sichtbar. Sie können zudem regionsübergreifende MySQL-Lesereplikate erstellen. Diese werden mithilfe der MySQL-Binlog-basierten Replikations-Engine implementiert.

Es hat sich bewährt, Aurora-Replikate bei der Skalierung von Lesevorgängen zu verwenden. Hierzu müssen Sie den Lese-Workload für den Writer reduzieren. Erhöhen Sie anschließend die Verfügbarkeit, um Ereignisse zu verwalten, die die Skalierung verlangsamen oder blockieren.

Lösung

Wie stufe ich ein Aurora-Lesereplikat herauf?

Manueller Failover – Führen Sie einen manuellen Failover durch, um eine andere Lesereplikat-Instance als Writer-Instance heraufzustufen, indem Sie die folgenden Schritte ausführen:

  1. Melden Sie sich bei der Amazon Relational Database Service (Amazon RDS)-Konsole an.
  2. Wählen Sie im Navigationsbereich Datenbanken aus.
  3. Wählen Sie die Writer-Instance für Ihren Aurora-DB-Cluster aus.
  4. Wählen Sie Aktionen und dann Failover aus.

Automatischer Failover – Aurora führt automatisch einen Failover zu einer Lesereplikat-Instance durch, wenn die Writer-Instance nicht mehr verfügbar ist. Dies kann aus einer Reihe von Gründen geschehen, unter anderem aufgrund von Ressourcenknappheit und aufgrund von Wartungsaktivitäten. Wenn Sie mehrere Reader haben, können Sie jede Instance in Ihrem Cluster eine Prioritätsstufe für die Heraufstufung zuweisen. Wenn die Writer-Instance ausfällt, stuft Aurora das Replikat mit der höchsten Priorität als neuen Writer hoch.

Sie können zudem ein regionsübergreifendes Aurora-Replikat als eigenständigen DB-Cluster heraufstufen. Die regionsübergreifende Replikation wird beendet, nachdem Sie den Hochstufungsprozess eingeleitet haben. Der neu hochgestufte Cluster fungiert als unabhängiger DB-Cluster und verarbeitet sowohl Lese- als auch Schreibvorgänge.

Wie kann ich die Replikationsverzögerung messen?

Da sich alle Aurora-DB-Instances in einem einzelnen DB-Cluster ein gemeinsames Datenvolumen teilen, ist die Replikationsverzögerung minimal. Normalerweise liegen die Verzögerungszeiten im Bereich von 10 Millisekunden. Unter bestimmten Umständen kann es jedoch zu einer leicht erhöhten Verzögerung bei den Readern kommen.

**Hinweis:**Regionsübergreifende Replikate verwenden die logische Replikation und werden von der Änderungs-/Anwendungsrate und den Verzögerungen bei der Netzwerkkommunikation zwischen den ausgewählten Regionen beeinflusst. Regionsübergreifende Replikate, die Aurora-Datenbanken verwenden, weisen in der Regel eine Verzögerung von weniger als einer Sekunde auf.

Sie können die Replikationsverzögerung mithilfe der folgenden Amazon CloudWatch-Metriken messen:

  • Verwenden Sie AuroraReplicaLag um die Replikatverzögerung zwischen dem Writer- und Reader-Knoten in Millisekunden (gleiche Region) zu messen.
  • Verwenden Sie AuroraBinlogReplicaLag, um die Replikatverzögerung zwischen Aurora-DB-Clustern mithilfe von Binärprotokollen zu messen.

Wie kann ich die Replikationsleistung verbessern?

Folgen Sie diesen Empfehlungen, um die Replikatverzögerung zu verringern:

  • Wenn die Reader-Instance kleiner ist als die Writer-Instance, ist das Volumen der Änderungen möglicherweise zu groß, als dass der Reader es aufholen könnte. Es hat sich bewährt, dass alle Instances in einem Cluster dieselbe Größe haben, um eine Überlastung der Reader-Instances zu vermeiden.
  • Wenn ein hoher Workload für den Writer besteht, stellen Sie möglicherweise eine vorübergehende Verzögerung beim Lesen von Replikaten fest. Die Verzögerung verringert sich, nachdem die Reader-Instance die Writer-Instance eingeholt hat.
  • Wenn Transaktionen mit langer Laufzeit ausgeführt werden, kann es sein, dass bei den Readern eine Replikatverzögerung auftritt. Um Verzögerungen beim Replikat zu vermeiden, sollten Sie Ihre Transaktionen in kleineren Batches und häufiger Commits ausführen.

Weitere Informationen zur Behebung von hoher Replikatverzögerung mithilfe der nativen Binlog-basierten MySQL-Replikation finden Sie unter Überblick über das Sichern und Wiederherstellen eines Aurora-DB-Clusters.

Kann ich einen Global Transaction Identifier (GTID) verwenden?

Eine globale Transaktionskennung ist eine eindeutige Zeichenfolge, die einer Transaktion bei ihrem Commit zugeordnet ist. Eine GTID ist auf allen Servern einzigartig und Änderungen werden auf der Grundlage des GTID-Werts auf das Ziel angewendet. Weitere Informationen zu GTID-Konzepten finden Sie in der MySQL-Dokumentation.

Aurora verwendet keine native Binlog-Replikation, um Daten auf Lesereplikat-Instances zu replizieren. Es ist nicht möglich, GTID zu verwenden, um Daten zwischen Instances im selben Cluster zu replizieren. In bestimmten Szenarien können Sie jedoch eine GTID-basierte Replikation einrichten. Weitere Informationen zur Verwendung der GTID-basierten Replikation in Aurora MySQL finden Sie im AWS-Blog zu GTID.

Hinweis: Sie können eine GTID-basierte Replikation zwischen einem Amazon RDS-MySQL- und einem Aurora-Cluster sowie zwischen Aurora-Clustern einrichten (indem Sie davon ausgehen, dass es sich bei der Quelle um einen externen Master handelt). Stellen Sie sicher, dass Binlog auf der Quelle aktiviert ist, bevor Sie den Replikationsprozess starten.


Ähnliche Informationen

Replikation mit Amazon Aurora

Was ist Amazon Aurora?

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 3 Jahren