Verwenden der Schreibweiterleitung in einer globalen Aurora-PostgreSQL-Datenbank

Region und Versionsverfügbarkeit der Schreibweiterleitung in Aurora PostgreSQL

Bei Aurora-PostgreSQL-Version 16 und höheren Hauptversionen wird die globale Schreibweiterleitung in allen Nebenversionen unterstützt. In früheren Versionen von Aurora PostgreSQL wird die globale Schreibweiterleitung ab Version 15.4 und höheren Nebenversionen sowie ab Version 14.9 und höheren Nebenversionen unterstützt. Die Schreibweiterleitung ist in jeder AWS-Region verfügbar, in der auf Aurora PostgreSQL basierende globale Datenbanken verfügbar sind.

Weitere Informationen zur Verfügbarkeit von Versionen und Regionen im Zusammenhang mit globalen Aurora-PostgreSQL-Datenbanken finden Sie unter Globale Aurora-Datenbanken unterstützen Aurora PostgreSQL.

Aktivieren der Schreibweiterleitung in Aurora PostgreSQL

Standardmäßig ist die Schreibweiterleitung nicht aktiviert, wenn Sie einen sekundären Cluster zu einer Aurora Global Database hinzufügen. Sie können die Schreibweiterleitung für Ihren sekundären DB-Cluster aktivieren, während Sie ihn erstellen oder jederzeit danach. Bei Bedarf können Sie es später deaktivieren. Das Aktivieren oder Deaktivieren der Schreibweiterleitung führt nicht zu Ausfallzeiten oder einem Neustart.

In der Konsole können Sie die Schreibweiterleitung aktivieren oder deaktivieren, wenn Sie einen sekundären DB-Cluster erstellen oder ändern.

Aktivierung oder Deaktivierung der Schreibweiterleitung bei der Erstellung eines sekundären DB-Clusters

Wenn Sie einen neuen sekundären DB-Cluster erstellen, aktivieren Sie die Schreibweiterleitung, indem Sie unter Lesereplikat-Schreibweiterleitung das Kontrollkästchen Globale Schreibweiterleitung aktivieren markieren. Oder entfernen Sie die Markierung in dem Kontrollkästchen, um das Feature zu deaktivieren. Befolgen Sie die Anweisungen für Ihre DB-Engine unter Erstellen eines Amazon Aurora-DB Clusters, um einen sekundärem DB-Cluster zu erstellen.

Der folgende Screenshot zeigt den Abschnitt Lesereplikat-Schreibweiterleitung, bei dem das Kontrollkästchen Globale Schreibweiterleitung aktivieren markiert ist.

Aktivierung oder Deaktivierung der Schreibweiterleitung bei der Änderung eines sekundären DB-Clusters

In der Konsole können Sie einen sekundären DB-Cluster ändern, um die Schreibweiterleitung zu aktivieren oder zu deaktivieren.

So aktivieren oder deaktivieren Sie die Schreibweiterleitung für einen vorhandenen sekundären DB-Cluster mit der Konsole

1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

2. Wählen Sie Databases (Datenbanken) aus.

3. Wählen Sie den sekundären DB-Cluster aus und klicken Sie dann auf Ändern.

4. Markieren oder löschen Sie im Abschnitt Lesereplikat-Schreibweiterleitung das Kontrollkästchen Globale Schreibweiterleitung aktivieren.

5. Klicken Sie auf Weiter.

6. Wählen Sie für Einplanung von Änderungen die Option Sofort anwenden aus. Wenn Sie Während des nächsten geplanten Wartungsfensters anwenden wählen, ignoriert Aurora diese Einstellung und aktiviert die Schreibweiterleitung sofort.

7. Wählen Sie Cluster bearbeiten aus.

Um die Schreibweiterleitung über die AWS CLI zu aktivieren, verwenden Sie die Option --enable-global-write-forwarding. Diese Option funktioniert, wenn Sie über den Befehl create-db-cluster einen neuen sekundären Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster über den Befehl modify-db-cluster ändern. Sie erfordert, dass die globale Datenbank eine Aurora-Version verwendet, die eine Schreibweiterleitung unterstützt. Sie können die Schreibweiterleitung deaktivieren, indem Sie die Option --no-enable-global-write-forwarding mit denselben CLI-Befehlen verwenden.

In den folgenden Verfahren wird beschrieben, wie Sie die Schreibweiterleitung für einen sekundären DB-Cluster in Ihrem globalen Cluster mithilfe von AWS CLI aktivieren oder deaktivieren.

So aktivieren oder deaktivieren Sie die Schreibweiterleitung für einen vorhandenen sekundären DB-Cluster

• Rufen Sie den AWS CLI-Befehl modify-db-cluster auf und geben Sie folgende Werte an:

  • --db-cluster-identifier – der Name des DB-Clusters.

  • --enable-global-write-forwarding zum Aktivieren oder --no-enable-global-write-forwarding zum Deaktivieren.

  Das folgende Beispiel aktiviert die Schreibweiterleitung für den DB-Cluster sample-secondary-db-cluster.

  Für Linux, macOS oder Unix:

  aws rds modify-db-cluster \
      --db-cluster-identifier sample-secondary-db-cluster \
      --enable-global-write-forwarding

  Für Windows:

  aws rds modify-db-cluster ^
      --db-cluster-identifier sample-secondary-db-cluster ^
      --enable-global-write-forwarding

Um die Schreibweiterleitung über die Amazon-RDS-API zu aktivieren, legen Sie den Parameter EnableGlobalWriteForwarding auf true fest. Dieser Parameter funktioniert, wenn Sie über die Operation CreateDBCluster einen neuen sekundären Cluster erstellen. Er funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster über die Operation ModifyDBCluster ändern. Sie erfordert, dass die globale Datenbank eine Aurora-Version verwendet, die eine Schreibweiterleitung unterstützt. Sie können die Schreibweiterleitung deaktivieren, indem Sie den Parameter EnableGlobalWriteForwarding auf false festlegen.

Überprüfen auf die Aktivierung der Schreibweiterleitung für einen sekundären Cluster in Ausrora PostgreSQL

Um festzustellen, ob Sie die Schreibweiterleitung aus einem sekundären Cluster verwenden können, können Sie prüfen, ob der Cluster das Attribut besitz "GlobalWriteForwardingStatus": "enabled".

In der AWS-Managementkonsole wird Ihnen Read replica write forwarding auf der Registerkarte Configuration (Konfiguration) der Detailseite für den Cluster angezeigt. Um den Status der globalen Einstellung für die Schreibweiterleitung für alle Cluster anzuzeigen, führen Sie den folgenden AWS CLI-Befehl aus.

Ein sekundärer Cluster zeigt die Werte "enabled" oder "disabled" an, um anzugeben, ob die Schreibweiterleitung aktiviert oder deaktiviert ist. Der Wert null gibt an, dass die Schreibweiterleitung für diesen Cluster nicht verfügbar ist. Entweder ist der Cluster nicht Teil einer globalen Datenbank oder ist der primäre Cluster und nicht kein sekundärer Cluster. Der Wert kann auch "enabling" oder "disabling" sein, wenn die Schreibweiterleitung gerade aktiviert oder deaktiviert wird.

aws rds describe-db-clusters --query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}'
[
    {
        "GlobalWriteForwardingStatus": "enabled",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
    },
    {
        "GlobalWriteForwardingStatus": "disabled",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-2"
    },
    {
        "GlobalWriteForwardingStatus": null,
        "DBClusterIdentifier": "non-global-cluster"
    }
]

Führen Sie den folgenden Befehl aus, um alle sekundären Cluster zu suchen, für die eine globale Schreibweiterleitung aktiviert ist. Dieser Befehl gibt auch den Reader-Endpunkt des Clusters aus. Sie verwenden den Reader-Endpunkt des sekundären Clusters, wenn Sie die Schreibweiterleitung vom sekundären zum primären Cluster in Ihrer globalen Aurora-Datenbank verwenden.

aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]'
[
    {
        "GlobalWriteForwardingStatus": "enabled",
        "ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
    }
]

Anwendungs- und SQL-Kompatibilität mit Schreibweiterleitung in Aurora PostgreSQL

Bestimmte Anweisungen sind nicht zulässig oder können veraltete Ergebnisse erzeugen, wenn Sie sie in einer globalen Datenbank mit Schreibweiterleitung verwenden. Darüber hinaus werden benutzerdefinierte Funktionen und benutzerdefinierte Prozeduren nicht unterstützt. Daher ist die Einstellung EnableGlobalWriteForwarding für sekundäre Cluster standardmäßig deaktiviert. Stellen Sie vor einer Aktivierung sicher, dass der Anwendungscode von keiner dieser Einschränkungen betroffen ist.

Sie können die folgenden Arten von SQL-Anweisungen mit Schreibweiterleitung verwenden:

Die folgenden Arten von SQL-Anweisungen werden bei Schreibweiterleitung nicht unterstützt:

Isolation und Konsistenz für die Schreibweiterleitung in Aurora PostgreSQL

In Sitzungen, die Schreibweiterleitung verwenden, können Sie nur die Isolationsstufen REPEATABLE READ und READ COMMITTED verwenden. Die SERIALIZABLE-Isolationsstufe wird jedoch nicht unterstützt.

Sie können den Grad der Lesekonsistenz in einem sekundären Cluster steuern. Die Lesekonsistenzstufe legt fest, wie viel Wartezeit der sekundäre Cluster vor jeder Leseoperation ausführt, um sicherzustellen, dass einige oder alle Änderungen aus dem primären Cluster repliziert werden. Sie können die Lesekonsistenzstufe anpassen, um sicherzustellen, dass alle aus Ihrer Sitzung weitergeleiteten Schreiboperationen im sekundären Cluster vor nachfolgenden Abfragen angezeigt werden. Sie können diese Einstellung auch verwenden, um sicherzustellen, dass Abfragen auf dem sekundären Cluster stets die aktuellsten Updates des primären Clusters angezeigt werden. Dies gilt auch für diejenigen, die von anderen Sitzungen oder anderen Clustern übermittelt wurden. Um diese Art von Verhalten für Ihre Anwendung anzugeben, wählen Sie den entsprechenden Wert für den apg_write_forward.consistency_mode-Parameter aus. Der Parameter apg_write_forward.consistency_mode wirkt sich nur auf sekundäre Cluster aus, in denen die Schreibweiterleitung aktiviert ist.

Wenn Sie das Konsistenzniveau erhöhen, verbringt Ihre Anwendung mehr Zeit mit dem Warten auf die Propagierung von Änderungen zwischen AWS-Regionen. Sie können das Verhältnis zwischen schneller Reaktionszeit und der Gewährleistung festlegen, dass vor der Ausführung Ihrer Abfragen Änderungen an anderen Speicherorten vollständig verfügbar sind.

Bei jeder verfügbaren Konsistenzmodus-Einstellung hat dies folgende Auswirkungen:

Weitere Informationen zu allen mit der Schreibweiterleitung verbundenen Parametern finden Sie unter Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL.

Transaktionszugriffsmodi mit Schreibweiterleitung

Wenn der Transaktionszugriffsmodus schreibgeschützt ist, wird die Schreibweiterleitung nicht verwendet. Sie können den Zugriffsmodus nur dann auf Lese- und Schreibzugriff festlegen, wenn Sie mit einem DB-Cluster und einer Sitzung verbunden sind, in der die lokale Schreibweiterleitung aktiviert ist.

Weitere Informationen zu den Transaktionszugriffsmodi finden Sie unter SET TRANSACTION.

Ausführen von Multipart-Anweisungen mit Schreibweiterleitung in Aurora PostgreSQL

Eine DML-Anweisung kann aus mehreren Teilen bestehen, z. B. einer INSERT ... SELECT-Anweisung oder einer DELETE ... WHERE-Anweisung. In diesem Fall wird die gesamte Anweisung an den primären Cluster weitergeleitet und dort ausgeführt.

Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL

Die Aurora-Cluster-Parametergruppen enthalten Einstellungen für die Schreibweiterleitung. Da es sich um Cluster-Parameter handelt, haben alle DB-Instances in allen Clustern die gleichen Werte für diese Variablen. Details zu diesen Parametern sind in der folgenden Tabelle zusammengefasst, mit Nutzungshinweisen unterhalb der Tabelle.

Der apg_write_forward.max_forwarding_connections_percent-Parameter definiert die Obergrenze der Datenbankverbindungsslots, die zum Umgang mit von Readern weitergeleiteten Abfragen verwendet werden können. Er wird als Prozentsatz der Einstellung max_connections für die Writer-DB-Instance im primären Cluster ausgedrückt. Wenn beispielsweise max_connections 800 und apg_write_forward.max_forwarding_connections_percent 10 ist, dann lässt der Writer maximal 80 weitergeleitete Sitzungen gleichzeitig zu. Diese Verbindungen stammen aus demselben, von der Einstellung max_connections verwalteten Verbindungspool. Diese Einstellung gilt nur für den primären Cluster, wenn für mindestens einen sekundären Cluster die Schreibweiterleitung aktiviert ist.

Verwenden Sie die folgenden Einstellungen auf dem sekundären Cluster:

Amazon-CloudWatch-Metriken für die Schreibweiterleitung in Aurora PostgreSQL

Die folgenden Amazon CloudWatch-Metriken gelten für den primären Cluster, wenn Sie die Schreibweiterleitung auf einem oder mehreren sekundären Clustern verwenden. Diese Metriken werden alle auf der Writer-DB-Instance im primären Cluster gemessen.

Die folgenden CloudWatch-Metriken gelten für jeden sekundären Cluster. Diese Metriken werden auf jeder Reader-DB-Instance in einem sekundären Cluster mit aktivierter Schreibweiterleitung gemessen.

Warte-Ereignisse für die Schreibweiterleitung in Aurora PostgreSQL

Amazon Aurora generiert die folgenden Warteereignisse, wenn Sie die Schreibweiterleitung mit Aurora PostgreSQL verwenden.

IPC:AuroraWriteForwardConnect

Das IPC:AuroraWriteForwardConnect-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster darauf wartet, dass eine Verbindung zum Writer-Knoten des primären DB-Clusters geöffnet wird.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Dieses Ereignis nimmt zu, wenn die Anzahl der Verbindungsversuche vom Leseknoten einer sekundären Region zum Writer-Knoten des primären DB-Clusters zunimmt.

Aktionen

Reduzieren Sie die Anzahl gleichzeitiger Verbindungen von einem sekundären Knoten zum Writer-Knoten der primären Region.

IPC:AuroraWriteForwardConsistencyPoint

Das IPC:AuroraWriteForwardConsistencyPoint-Ereignis beschreibt, wie lange eine Abfrage von einem Knoten im sekundären-DB-Cluster darauf wartet, dass die Ergebnisse weitergeleiteter Schreiboperationen in die aktuelle Region repliziert werden. Dieses Ereignis wird nur generiert, wenn der Parameter apg_write_forward.consistency_mode auf Sitzungsebene auf einen der folgenden Werte gesetzt ist:

Informationen zum Einstellen des Parameters apg_write_forward.consistency_mode finden Sie unter Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Zu den häufigsten Ursachen für längere Wartezeiten gehören:

Aktionen

Ändern Sie Ihren Konsistenzmodus je nach den Anforderungen Ihrer Anwendung.

IPC:AuroraWriteForwardExecute

Das IPC:AuroraWriteForwardExecute-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster darauf wartet, dass eine weitergeleitete Abfrage abgeschlossen wird und Ergebnisse vom Writer-Knoten des primären DB-Clusters abgerufen werden.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:

Aktionen

Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.

IPC:AuroraWriteForwardGetGlobalConsistencyPoint

Das IPC:AuroraWriteForwardGetGlobalConsistencyPoint-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster, der den Konsistenzmodus GLOBAL verwendet, darauf wartet, den globalen Konsistenzpunkt vom Writer-Knoten zu erhalten, bevor er eine Abfrage ausführt.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:

Aktionen

Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.

IPC:AuroraWriteForwardXactAbort

Das IPC:AuroraWriteForwardXactAbort-Ereignis tritt ein, wenn ein Back-End-Prozess auf dem sekundären DB-Cluster auf das Ergebnis einer Remote-Bereinigungsabfrage wartet. Bereinigungsabfragen werden ausgegeben, um den Prozess nach dem Abbruch einer per Schreibweiterleitung weitergeleiteten Transaktion wieder in den entsprechenden Zustand zu versetzen. Amazon Aurora führt diese entweder aus, weil ein Fehler gefunden wurde oder weil ein Benutzer einen expliziten ABORT-Befehl ausgegeben oder eine laufende Abfrage abgebrochen hat.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:

Aktionen

Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.

IPC:AuroraWriteForwardXactCommit

Das IPC:AuroraWriteForwardXactCommit-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster auf das Ergebnis eines weitergeleiteten Commit-Transaktionsbefehls wartet.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:

Aktionen

Wenn der sekundäre Knoten oder der Writer-Knoten der primären Region durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, ihn auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen.

IPC:AuroraWriteForwardXactStart

Das IPC:AuroraWriteForwardXactStart-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster auf das Ergebnis eines weitergeleiteten Transaktionsstartbefehls wartet.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:

Aktionen

Wenn der sekundäre Knoten oder der Writer-Knoten der primären Region durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, ihn auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen.