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

Lösung

Stufe ein Aurora MySQL-kompatibles Lesereplikat hoch

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:

1. Öffne die Amazon-RDS-Konsole.
2. Wähle im Navigationsbereich Datenbanken aus.
3. Wählen Sie die Writer-Instance für Ihren Aurora-DB-Cluster aus.
4. Wähle Aktionen und dann Failover aus.

Wenn die Writer-Instance nicht verfügbar ist, führt Aurora MySQL-kompatibel 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 in deinem Cluster an. Wenn die Writer-Instance ausfällt, stuft Aurora MySQL-kompatibel 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.

Die Replikationsverzögerung messen

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.

Die Replikationsleistung verbessern

Ergreife die folgenden Maßnahmen:

• Um hohe Arbeitslasten auf den Reader-Instances zu vermeiden, empfiehlt es sich, alle Instances in einem Cluster auf die gleiche Größe zu legen. Wenn die Reader-Instance kleiner ist als die Writer-Instance, ist das Volumen der Änderungen zu groß, als dass der Reader damit übereinstimmen könnte.
  Hinweis: Wenn eine hohe Arbeitslast für die Writer-Instance besteht, stellst du möglicherweise eine vorübergehende Verzögerung beim Lesen von Replikaten 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 Amazon Aurora MySQL-Replikationsprobleme.

Problembehandlung bei hoher Replikationsverzögerung

Verwende die CloudWatch-Metrik AuroraReplicaLag, um eine hohe Replikationsverzögerung zu überprü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?

GTID-basierte Replikation einrichten

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 Aurora MySQL-kompatibel findest du unter Amazon Aurora for MySQL-Kompatibilität unterstützt jetzt die Replikation globaler Transaktionsidentifikatoren (GTIDs).

Für die Aurora MySQL-kompatiblen Versionen 3.04 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.

Ähnliche Informationen

Replikation von Amazon Aurora MySQL DB Clustern in allen AWS-Regionen

Replikation mit Amazon Aurora