Replikation mit Amazon Aurora Postgre SQL - Amazon Aurora
Aurora-ReplikateVerbesserung der Verfügbarkeit von Aurora ReplicasÜberwachung einer -Replikation

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Replikation mit Amazon Aurora Postgre SQL

Im Folgenden finden Sie Informationen zur Replikation mit Amazon Aurora PostgreSQL, einschließlich der Überwachung und Verwendung der logischen Replikation.

Themen

Verwendung von Aurora-Replicas

Eine Aurora Replica ist ein unabhängiger Endpunkt in einem Aurora-DB-Cluster, die die beste Methode für das Skalieren von Leseoperationen und Erhöhen der Verfügbarkeit darstellen. Ein Aurora-DB-Cluster kann bis zu 15 Aurora-Repliken enthalten, die sich in den Availability Zones des Aurora-DB-Clusters befinden AWS Region.

Das DB-Cluster-Volume besteht aus mehreren Kopien der Daten für den DB-Cluster. Die Daten im Cluster-Volume werden jedoch als ein einzelnes logisches Volume der primären Writer-DB-Instance und der Aurora-Replicas im DB-Cluster dargestellt. Weitere Informationen über Aurora-Replicas finden Sie unter Aurora-Replikate.

Aurora Replicas eignen sich für das Skalieren von Lesevorgängen, da sie in Ihrem Cluster-Volume ausschließlich für Lesevorgänge bereitstehen. Schreibvorgänge werden von der Writer-DB-Instance verwaltet. Das Cluster-Volume wird von allen Instances in Ihrem Aurora SQL Postgre-DB-Cluster gemeinsam genutzt. Daher ist keine zusätzliche Arbeit erforderlich, um eine Kopie der Daten für jede Aurora Replica zu replizieren.

Wenn ein Aurora-Replikat mit Aurora Postgre SQL gelöscht wird, wird sein Instanzendpunkt sofort entfernt, und das Aurora-Replikat wird vom Reader-Endpunkt entfernt. Wenn Anweisungen vorhanden sind, die auf dem Aurora-Replica ausgeführt werden, das gerade gelöscht wird, besteht eine Übergangsfrist von drei Minuten. Vorhandene Anweisungen können während der Nachfrist geordnet beendet werden. Nach Ablauf der Nachfrist wird das Aurora-Replikat geschlossen und gelöscht.

Aurora SQL Postgre-DB-Cluster unterstützen Aurora Replicas auf verschiedenen AWS Regionen, die die globale Aurora-Datenbank verwenden. Weitere Informationen finden Sie unter Verwenden von Amazon Aurora Global Databases.

Anmerkung

Mit der verbesserten Leseverfügbarkeitsfunktion müssen Sie die Aurora Replicas im DB-Cluster ggf. manuell neu starten. Für die DB-Cluster, die vor Einführung dieser Funktion erstellt wurden, werden durch einen Neustart der Writer-DB-Instance automatisch die Aurora Replicas neu gestartet. Durch den automatischen Neustart wird der Einstiegspunkt wiederhergestellt, der die Lese-/Schreibkonsistenz innerhalb des DB-Clusters gewährleistet.

Verbesserung der Leseverfügbarkeit von Aurora Replicas

Aurora Postgre SQL verbessert die Leseverfügbarkeit im DB-Cluster, indem die Leseanforderungen kontinuierlich bearbeitet werden, wenn die Writer-DB-Instance neu gestartet wird oder wenn die Aurora Replica nicht in der Lage ist, mit dem Schreibverkehr Schritt zu halten.

Die Leseverfügbarkeitsfunktion ist standardmäßig in den folgenden Versionen von Aurora Postgre SQL verfügbar:

  • 16.1 und alle höheren Versionen

  • 15.2 und höhere 15-Versionen

  • 14.7 und höhere 14-Versionen

  • 13.10 und höhere 13-Versionen

  • 12.14 und höhere 12-Versionen

Die Leseverfügbarkeitsfunktion wird von der globalen Aurora-Datenbank in den folgenden Versionen unterstützt:

  • 16.1 und alle höheren Versionen

  • 15.4 und höhere 15-Versionen

  • 14.9 und höhere 14-Versionen

  • 13.12 und höhere 13-Versionen

  • 12.16 und höhere 12-Versionen

Um die Leseverfügbarkeitsfunktion für einen DB-Cluster zu verwenden, der vor der Einführung der Funktion in einer dieser Versionen erstellt wurde, starten Sie die Writer-Instance des DB-Clusters neu.

Wenn Sie die statischen Parameter Ihres Aurora SQL Postgre-DB-Clusters ändern, müssen Sie die Writer-Instance neu starten, damit die Parameteränderungen wirksam werden. Sie müssen beispielsweise die Writer-Instance neu starten, wenn Sie den Wert shared_buffers festlegen. Dank der verbesserten Verfügbarkeit von Aurora Replicas behält der DB-Cluster die Leseverfügbarkeit während dieser Neustarts bei, wodurch die Auswirkungen von Änderungen auf die Writer-Instance reduziert werden. Die Reader-Instances werden nicht neu gestartet und antworten weiterhin auf die Leseanfragen. Um statische Parameteränderungen anzuwenden, starten Sie jede einzelne Reader-Instance neu.

Die Aurora Replica eines Aurora SQL Postgre-DB-Clusters kann Replikationsfehler wie Writer-Neustarts, Failover, langsame Replikation und Netzwerkprobleme beheben, indem sie nach der erneuten Verbindung mit dem Writer schnell wieder in den Zustand der In-Memory-Datenbank zurückkehrt. Dieser Ansatz ermöglicht es Aurora-Replica-Instances, die Konsistenz mit den neuesten Speicher-Updates zu erreichen, solange die Client-Datenbank noch verfügbar ist.

Bei laufenden Transaktionen, die mit der Replikationswiederherstellung kollidieren, wird möglicherweise ein Fehler angezeigt, aber der Client kann diese Transaktionen erneut versuchen, sobald die Reader wieder mit dem Writer mithalten.

Überwachen von Aurora Replicas

Sie können die Aurora Replicas bei der Wiederherstellung nach einer Writer-Unterbrechung überwachen. Verwenden Sie die folgenden Metriken, um nach den neuesten Informationen zur Reader-Instance zu suchen und um in Bearbeitung befindliche schreibgeschützte Transaktionen zu verfolgen.

  • Die aurora_replica_status Funktion wurde aktualisiert, sodass sie die meisten up-to-date Informationen für die Reader-Instance zurückgibt, wenn diese noch verbunden ist. Der Zeitstempel der letzten Aktualisierung in aurora_replica_status ist für die Zeile, die der DB-Instance entspricht, auf der die Abfrage ausgeführt wird, immer leer. Dies bedeutet, dass die Reader-Instance über die neuesten Daten verfügt.

  • Wenn das Aurora Replica die Verbindung zur Writer-Instance trennt und wieder eine Verbindung herstellt, wird das folgende Datenbankereignis ausgelöst:

    Read replica has been disconnected from the writer instance and reconnected.

  • Wenn eine schreibgeschützte Abfrage aufgrund eines Wiederherstellungskonflikts abgebrochen wird, werden im Datenbankfehlerprotokoll möglicherweise eine oder mehrere der folgenden Fehlermeldungen angezeigt:

    Canceling statement due to conflict with recovery.

    User query may not have access to page data to replica disconnect.

    User query might have tried to access a file that no longer exists.

    When the replica reconnects, you will be able to repeat your command.

Einschränkungen

Die folgenden Einschränkungen gelten für Aurora Replicas mit verbesserter Verfügbarkeit:

  • Aurora Replicas des sekundären DB-Clusters können neu gestartet werden, wenn die Daten während der Replikationswiederherstellung nicht von der Writer-Instance gestreamt werden können.

  • Aurora Replicas unterstützen keine Online-Replikationswiederherstellung, wenn eine solche Wiederherstellung bereits läuft und neu gestartet wird.

  • Aurora Replicas werden neu gestartet, wenn sich Ihre DB-Instance dem Transaktions-ID-Wraparound nähert. Weitere Informationen zum Transaktions-ID-Wraparound finden Sie unter Verhindern von Transaktions-ID-Wraparound-Fehlern.

  • Aurora Replicas können unter bestimmten Umständen neu gestartet werden, wenn der Replikationsprozess blockiert ist.

Überwachung der Aurora Postgre-Replikation SQL

Skalieren von Lesevorgängen und hohe Verfügbarkeit hängen von der minimalen Verzögerungszeit ab. Sie können überwachen, wie weit eine Aurora Replica der Writer-DB-Instance Ihres Aurora SQL Postgre-DB-Clusters hinterherhinkt, indem Sie die Amazon-Metrik überwachen. CloudWatch ReplicaLag Da Aurora Replicas aus demselben Cluster-Volume lesen wie die Writer-DB-Instance, hat die ReplicaLag Metrik für einen Aurora SQL Postgre-DB-Cluster eine andere Bedeutung. Die ReplicaLag-Metrik für eine Aurora Replica ermittelt die Verzögerung für den Seiten-Cache der Aurora Replica im Vergleich zu der der Writer-DB-Instance.

Weitere Informationen zur Überwachung von RDS Instances und CloudWatch Metriken finden Sie unter. Überwachung von Metriken in einem Amazon-Aurora-Cluster