Verwenden der Schreibweiterleitung in einer globalen Aurora-PostgreSQL-Datenbank

Region und Versionsverfügbarkeit der Schreibweiterleitung in Aurora PostgreSQL

Die Schreibweiterleitung wird mit Aurora-PostgreSQL-Version 15.4 und höheren Nebenversionen sowie mit Version 14.9 und höheren Nebenversionen unterstützt. Die Schreibweiterleitung ist in jeder 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.

Konsole

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 Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/rds/.

2. Wählen Sie 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 Wartungszeitfensters anwenden wählen, ignoriert Aurora diese Einstellung und aktiviert die Schreibweiterleitung sofort.

7. Wählen Sie Cluster bearbeiten aus.

AWS CLI

Um die Schreibweiterleitung mithilfe von zu aktivieren AWS CLI, verwenden Sie die --enable-global-write-forwarding Option. Diese Option funktioniert, wenn Sie mit dem create-db-clusterBefehl einen neuen sekundären Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster mithilfe des modify-db-clusterBefehls ä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 modify-db-cluster AWS CLI Befehl auf und geben Sie die folgenden Werte ein:

  • --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 LinuxmacOS, oderUnix:

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

  Windows:

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

RDS-API

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 Management Console sehen Sie Read replica write forwarding auf der Registerkarte Konfiguration die Detailseite für den Cluster. Führen Sie den folgenden AWS CLI Befehl aus, um den Status der Einstellung für die globale Schreibweiterleitung für alle Ihre Cluster zu überprüfen.

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.

Beispiel

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.

Beispiel

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 Verfahren 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:

• Data Manipulation Language (DML)-Anweisungen wie INSERT, DELETE und UPDATE.

• SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }-Anweisungen.

• PREPARE- und EXECUTE-Anweisungen.

• EXPLAIN-Anweisungen mit den Anweisungen in dieser Liste

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

• DDL-Anweisungen (Data Definition Language)

• ANALYZE

• CLUSTER

• COPY

• Cursor – Cursors werden nicht unterstützt. Stellen Sie daher sicher, dass Sie sie schließen, bevor Sie die Schreibweiterleitung verwenden.

• GRANT|REVOKE|REASSIGN OWNED|SECURITY LABEL

• LOCK

• SAVEPOINT-Anweisungen.

• SELECT INTO

• SET CONSTRAINTS

• TRUNCATE

• VACUUM

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 Sitzungsebenen-Parameter apg_write_forward.consistency_mode. Der Parameter apg_write_forward.consistency_mode wirkt sich nur auf sekundäre Cluster aus, in denen die Schreibweiterleitung aktiviert ist.

Anmerkung

Für den Parameter apg_write_forward.consistency_mode können Sie die Werte SESSION, EVENTUAL, GLOBAL oder OFF angeben. Standardmäßig ist der Wert auf SESSION festgelegt. Wenn Sie den Wert auf OFF festlegen, wird die Schreibweiterleitung in der Sitzung deaktiviert.

Wenn Sie das Konsistenzniveau erhöhen, verbringt Ihre Anwendung mehr Zeit damit, darauf zu warten, dass Änderungen zwischen den AWS Regionen übertragen werden. 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:

• SESSION— Bei allen Abfragen in einer sekundären AWS Region, die Schreibweiterleitung verwendet, werden die Ergebnisse aller in dieser Sitzung vorgenommenen Änderungen angezeigt. Die Änderungen werden unabhängig davon angezeigt, ob die Transaktion übergeben wurde. Wenn notwendig, wartet die Abfrage auf die Replikation der Ergebnisse weitergeleiteter Schreiboperationen zur aktuellen Region. Sie wartet nicht auf aktualisierte Ergebnisse aus Schreiboperationen, die in anderen Regionen oder in anderen Sitzungen innerhalb der aktuellen Region ausgeführt werden.

• EVENTUAL— Bei Abfragen in einer sekundären AWS Region, die Schreibweiterleitung verwendet, können Daten angezeigt werden, die aufgrund von Replikationsverzögerungen leicht veraltet sind. Ergebnisse von Schreiboperationen in derselben Sitzung werden erst angezeigt, wenn die Schreiboperation in der primären Region ausgeführt und zur aktuellen Region repliziert wird. Die Abfrage wartet nicht, bis die aktualisierten Ergebnisse verfügbar sind. Daher könnte sie die älteren Daten oder die aktualisierten Daten abrufen, abhängig vom Zeitpunkt der Anweisungen und der Größe der Replikationsverzögerung.

• GLOBAL— Bei einer Sitzung in einer sekundären AWS Region werden Änderungen vorgenommen, die durch diese Sitzung vorgenommen wurden. Außerdem werden alle vorgenommenen Änderungen sowohl aus der primären AWS Region als auch aus anderen sekundären AWS Regionen angezeigt. Jede Abfrage kann für einen bestimmten Zeitraum warten, abhängig von der Sitzungsverzögerung. Die Abfrage wird fortgesetzt, wenn der sekundäre Cluster zu up-to-date dem Zeitpunkt, zu dem die Abfrage gestartet wurde, alle zugeschriebenen Daten aus dem primären Cluster enthält.

• OFF – Die Schreibweiterleitung ist in der Sitzung deaktiviert.

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

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.

Name	Scope	Typ	Standardwert	Zulässige Werte
apg_write_forward.connect_timeout	Sitzung	Sekunden	30	0 – 2147483647
apg_write_forward.consistency_mode	Sitzung	enum	Sitzung	SESSION, EVENTUAL, GLOBAL, OFF
apg_write_forward.idle_in_transaction_session_timeout	Sitzung	Millisekunden	86400000	0 – 2147483647
apg_write_forward.idle_session_timeout	Sitzung	Millisekunden	300000	0 – 2147483647
apg_write_forward.max_forwarding_connections_percent	Global	int	25	1-100

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:

• apg_write_forward.consistency_mode – Ein Parameter auf Sitzungsebene, der den Grad der Lesekonsistenz auf dem sekundären Cluster steuert. Gültige Werte sind SESSION, EVENTUAL, GLOBAL oder OFF. Standardmäßig ist der Wert auf SESSION festgelegt. Wenn Sie den Wert auf OFF festlegen, wird die Schreibweiterleitung in der Sitzung deaktiviert. Weitere Informationen über Konsistenzebenen finden Sie unter Isolation und Konsistenz für die Schreibweiterleitung in Aurora PostgreSQL. Dieser Parameter ist nur in Reader-Instances sekundärer Cluster relevant, für die Schreibweiterleitung aktiviert ist und die sich in einer Aurora Global Database befinden.

• apg_write_forward.connect_timeout – Die maximale Anzahl von Sekunden, die der sekundäre Cluster beim Herstellen einer Verbindung zum primären Cluster wartet, bevor er aufgibt. Ein Wert von 0 bedeutet, dass auf unbestimmte Zeit gewartet werden soll.

• apg_write_forward.idle_in_transaction_session_timeout – Die Anzahl der Millisekunden, die der primäre Cluster auf Aktivität für eine Verbindung wartet, die aus einem sekundären Cluster mit einer offenen Transaktion weitergeleitet wird, bevor er sie schließt. Wenn die Sitzung über diesen Zeitraum hinaus inaktiv ist, bricht Aurora die Sitzung ab. Durch einen Wert des Typs 0 wird der Timout deaktiviert.

• apg_write_forward.idle_session_timeout – Die Anzahl der Millisekunden, die der primäre Cluster auf Aktivität für eine Verbindung wartet, die aus einem sekundären Cluster weitergeleitet wird, bevor er sie schließt. Wenn die Sitzung über diesen Zeitraum hinaus inaktiv bleibt, beendet Aurora die Sitzung. Durch einen Wert des Typs 0 wird der Timout deaktiviert.

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

Die folgenden CloudWatch Amazon-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.

CloudWatch Metrik	Einheiten und Beschreibung
AuroraForwardingWriterDMLThroughput	Anzahl pro Sekunde Anzahl der weitergeleiteten DML-Anweisungen, die pro Sekunde von dieser Writer-DB-Instance verarbeitet werden.
AuroraForwardingWriterOpenSessions	Anzahl Anzahl der offenen Sitzungen auf dieser Writer-DB-Instance, die weitergeleitete Anfragen verarbeiten.
AuroraForwardingWriterTotalSessions	Anzahl Anzahl der weitergeleiteten Sitzungen auf dieser Writer-DB-Instance.

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.

CloudWatch Metrik	Einheit und Beschreibung
AuroraForwardingReplicaCommitThroughput	Anzahl pro Sekunde Anzahl der Commits in Sitzungen, die von diesem Replikat pro Sekunde weitergeleitet werden.
AuroraForwardingReplicaDMLLatency	Millisekunden Durchschnittliche Reaktionszeit weitergeleiteter DML-Anweisungen in Millisekunden auf Replikaten.
AuroraForwardingReplicaDMLThroughput	Anzahl pro Sekunde Anzahl der weitergeleiteten DML-Anweisungen, die in diesem Replikat pro Sekunde verarbeitet werden.
AuroraForwardingReplicaErrorSessionsLimit	Anzahl Anzahl der Sitzungen, die vom primären Cluster zurückgewiesen wurden, weil das Limit für die maximale Zahl von Verbindungen oder die maximale Schreibweiterleitung erreicht wurde.
AuroraForwardingReplicaOpenSessions	Anzahl Die Anzahl der Sitzungen, die die Schreibweiterleitung für eine Replikat-Instance verwenden.
AuroraForwardingReplicaReadWaitLatency	Millisekunden Durchschnittliche Wartezeit in Millisekunden, die das Replikat darauf wartet, mit der LSN des primären Clusters konsistent zu sein. Das Ausmaß, in dem die Reader-DB-Instance vor der Verarbeitung einer Abfrage wartet, ist von der Einstellung apg_write_forward.consistency_mode abhängig. Weitere Informationen zu dieser Einstellung finden Sie unter Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL.

Warte-Ereignisse für die Schreibweiterleitung in Aurora PostgreSQL

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

Themen

• IPC: AuroraWriteForwardConnect
• IPC: AuroraWriteForwardConsistencyPoint
• IPC: AuroraWriteForwardExecute
• IPC: AuroraWriteForwardGetGlobalConsistencyPoint
• IPC: AuroraWriteForwardXactAbort
• IPC: AuroraWriteForwardXactCommit
• IPC: AuroraWriteForwardXactStart

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:

• SESSION – Abfragen auf einem sekundären Knoten warten auf die Ergebnisse aller in dieser Sitzung ausgeführten Änderungen.

• GLOBAL – Abfragen auf einem sekundären Knoten warten auf die Ergebnisse der in dieser Sitzung vorgenommenen Änderungen sowie auf alle festgeschriebenen Änderungen sowohl aus der primären Region als auch aus anderen sekundären Regionen im globalen Cluster.

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:

• Erhöhte Replikatverzögerung, gemessen anhand der CloudWatch ReplicaLag Amazon-Metrik. Weitere Informationen zu dieser Metrik finden Sie unter Überwachung einer Aurora PostgreSQL-Replikation.

• Erhöhte Last auf dem Writer-Knoten der primären Region oder auf dem sekundären Knoten.

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:

• Abrufen einer großen Zahl von Zeilen aus dem Writer-Knoten der primären Region.

• Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.

• Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Abfrageanforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.

• Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.

Aktionen

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

• Optimieren Sie Abfragen, um nur die erforderlichen Daten abzurufen.

• Optimieren Sie DML-Operationen (Data Manipulation Language), um nur die erforderlichen Daten zu ändern.

• 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: 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:

• Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.

• Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Abfrageanforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.

• Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.

Aktionen

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

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

• 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: 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:

• Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.

• Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Bereinigungsabfrage-Anforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.

• Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.

Aktionen

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

• Untersuchen Sie die Ursache für die abgebrochene Transaktion.

• 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: 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:

• Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.

• Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Abfrageanforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.

• Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.

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:

• Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.

• Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Abfrageanforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.

• Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.

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.