Wie behebe ich Probleme, wenn ich Lesereplikate in meiner MySQL-kompatiblen DB-Instance von Aurora verwende?

Lesedauer: 4 Minute

Ich habe Probleme, wenn ich Lesereplikate in meiner DB-Instance der MySQL-kompatiblen Edition von Amazon Aurora verwende. Ich möchte diese Probleme beheben.

Lösung

Hochstufen eines MySQL-kompatiblen Lesereplikats von Aurora

Wenn die Writer-Instance einen Neustart oder eine Wartung erfordert, führe ein manuelles Failover durch, um ein Lesereplikat als Writer-Instance hochzustufen.

Gehe wie folgt vor, um ein manuelles Failover durchzuführen:

Öffne die Amazon-Aurora- und -RDS-Konsole.
Wähle im Navigationsbereich Datenbanken aus.
Wähle die Writer-Instance für den Aurora-DB-Cluster aus.
Wähle Aktionen und dann Failover aus.

Wenn die Writer-Instance nicht verfügbar ist, führt die MySQL-kompatibel Edition von Aurora automatisch einen Failover zu einer Lesereplikat-Instance durch. Eine Writer-Instance kann aus mehreren Gründen nicht mehr verfügbar sein, z. B. aufgrund von Ressourcenkonflikten oder Wartungsaktivitäten.

Wenn du mehrere Reader hast, gib eine Prioritätsstufe für die Heraufstufung für jede Instance im Cluster an. Wenn die Writer-Instance ausfällt, stuft die MySQL-kompatible Edition von Aurora das Replikat mit der höchsten Priorität als neuen Writer hoch.

Du kannst zudem ein AWS-regionsübergreifendes Aurora-Replikat als eigenständigen DB-Cluster heraufstufen. Nachdem du den Hochstufungsprozess eingeleitet hast, wird die regionsübergreifende Replikation beendet. Der hochgestufte Cluster fungiert als unabhängiger DB-Cluster und verwaltet sowohl Lese- als auch Schreibvorgänge.

Messen der Replikationsverzögerung

Da sich alle Aurora-DB-Instances in einem DB-Cluster ein gemeinsames Datenvolumen teilen, ist die Replikationsverzögerung minimal. In einigen Szenarien kann es jedoch zu einer leicht erhöhten Verzögerung bei den Readern kommen.

Hinweis: Regionsübergreifende Replikate verwenden die binäre Protokollreplikation. Das Ändern und Anwenden von Raten und Verzögerungen bei der Netzwerkkommunikation zwischen den ausgewählten Regionen kann sich auf regionsübergreifende Replikate auswirken. Regionsübergreifende Replikate, die Aurora-MySQL-Datenbanken verwenden, weisen in der Regel eine Verzögerung von weniger als 1 Sekunde auf.

Verwende die folgenden Amazon-CloudWatch-Metriken, um die Replikationsverzögerung zu messen:

Die Metrik AuroraReplicaLag misst die Replikatverzögerung zwischen dem Writer- und Reader-Knoten in Millisekunden in der gleichen Region.
Die Metrik AurorabinLogReplicaLag misst die Replikatverzögerung zwischen Aurora-DB-Clustern, die Binärprotokolle verwenden.

Informationen zu den vorherigen Metriken findest du unter Metriken auf Instance-Ebene für Amazon Aurora.

Verbessern der Replikationsleistung

Ergreife die folgenden Maßnahmen:

Um hohe Arbeitslasten auf den Reader-Instances zu vermeiden, empfiehlt es sich, alle Instances in einem Cluster in der gleichen Größe festzulegen. Wenn die Reader-Instance kleiner ist als die Writer-Instance, ist das Volumen der Änderungen zu groß, als dass der Reader mithalten könnte.
Hinweis: Wenn eine hohe Arbeitslast für die Writer-Instance besteht, stellst du möglicherweise eine vorübergehende Verzögerung bei Lesereplikaten fest. Nachdem die Reader-Instance mit der Writer-Instance übereinstimmt, verringert sich die Verzögerung.
Um Verzögerungen bei der Replikation zu vermeiden, wenn Transaktionen mit langer Laufzeit laufen, solltest du deine Transaktionen in kleineren Batches ausführen und häufig Commits ausführen.

Informationen zur Behebung von Replikationsverzögerungen mithilfe der systemeigenen binären protokollbasierten MySQL-Replikation findest du unter MySQL-Replikationsprobleme in Amazon Aurora.

Problembehandlung bei hoher Replikationsverzögerung

Verwende die CloudWatch-Metrik AuroraReplicaLag, um auf eine hohe Replikationsverzögerung zu prüfen. Eine hohe Replikationsverzögerung kann dazu führen, dass eine Reader-Instance neu gestartet wird. Informationen zur Behebung dieses Problems findest du unter Warum ist mein Amazon-Aurora-Lesereplikat zurückgefallen und wurde neu gestartet?

Einrichten einer GTID-basierten Replikation

Aurora verwendet keine native Binärprotokoll-Replikation, um Daten auf Lesereplikat-Instances zu replizieren. Du kannst keinen globalen Transaktionsidentifikator (GTID) verwenden, um Daten zwischen Instances im selben Cluster zu replizieren. In einigen Szenarien kannst du jedoch eine GTID-basierte Replikation einrichten. Weitere Informationen zur Verwendung der GTID-basierten Replikation in der MySQL-kompatiblen Edition von Aurora findest du unter MySQL-Kompatibilität für Amazon Aurora unterstützt jetzt die Replikation globaler Transaktionsidentifikatoren (GTIDs).

Für die MySQL-kompatible Versionen 3.04 von Aurora und später ist die Multithread-Binärprotokoll-Replikation aktiviert und replica_parallel_workers ist standardmäßig auf 4 gesetzt. Da die Multithread-Binärprotokoll-Replikation aktiviert ist, musst du die Stabilität deiner Datenbank gegen einen unerwarteten Stopp erhöhen. Es hat sich bewährt, die GTID-Replikation auf deiner Quelle zu aktivieren und GTIDs auf dem Replikat zuzulassen.

Hinweis: Du kannst eine GTID-basierte Replikation zwischen Amazon Relational Database Service (Amazon RDS) für MySQL und einem Aurora-Cluster und zwischen Aurora-Clustern einrichten. Die Quelle muss ein externer primärer Server sein. Bevor du den Replikationsvorgang startest, stelle sicher, dass du die binäre Protokollierung auf der Quelle aktivierst.

Weitere Informationen zu GTID findest du unter GTID-Format und -Speicher auf der MySQL-Website.