Verwenden der Schreibweiterleitung in einer SQL globalen Aurora Postgre-Datenbank

Region und Versionsverfügbarkeit der Schreibweiterleitung in Aurora Postgre SQL

In den Hauptversionen von Aurora Postgre SQL Version 16 und höheren Versionen wird die globale Schreibweiterleitung in allen Nebenversionen unterstützt. Für frühere Aurora SQL Postgre-Versionen wird die globale Schreibweiterleitung mit Nebenversionen von Version 15.4 und höher sowie mit Nebenversionen von Version 14.9 und höher unterstützt. Die Schreibweiterleitung ist in allen AWS Regionen verfügbar, in denen globale Datenbanken SQL auf Aurora Postgre-Basis verfügbar sind.

Weitere Informationen zur Version und regionalen Verfügbarkeit der SQL globalen Aurora Postgre-Datenbanken finden Sie unterGlobale Aurora-Datenbanken mit Aurora Postgre SQL.

Schreibweiterleitung in Aurora Postgre aktivieren SQL

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 an AWS Management Console und öffnen Sie die RDS Amazon-Konsole 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 --no-enable-global-write-forwarding Option 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.

  Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Linux, macOS, oder Unix:

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

  Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Windows:

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

RDS API

Um die Schreibweiterleitung über Amazon zu aktivieren RDSAPI, setzen Sie den EnableGlobalWriteForwarding Parameter auftrue. Dieser Parameter funktioniert, wenn Sie mithilfe der reateDBClusterC-Operation einen neuen sekundären Cluster erstellen. Er funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster mithilfe der odifyDBClusterM-Operation ä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üfung, ob für einen sekundären Cluster die Schreibweiterleitung in Aurora Postgre aktiviert ist SQL

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"
    }
]

Anwendung und SQL Kompatibilität mit der Schreibweiterleitung in Aurora Postgre SQL

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 der Schreibweiterleitung verwenden:

• Anweisungen in Data Manipulation Language (DML)INSERT, wieDELETE, 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 der Schreibweiterleitung nicht unterstützt:

• Anweisungen in der Datendefinitionssprache (DDL)

• 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 Postgre SQL

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 Postgre SQL.

Ausführen mehrteiliger Anweisungen mit Schreibweiterleitung in Aurora Postgre SQL

Eine DML Anweisung kann aus mehreren Teilen bestehen, z. B. aus 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 Postgre SQL

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 Postgre SQL. 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 Postgre SQL

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 jede 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 Antwortzeit in Millisekunden bei der Weiterleitung DMLs auf dem Replikat.
AuroraForwardingReplicaDMLThroughput	Anzahl pro Sekunde Anzahl der pro Sekunde auf diesem DML Replikat verarbeiteten weitergeleiteten Anweisungen.
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, bis das Replikat mit der des primären Clusters konsistent ist. LSN 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 Postgre SQL.

Warte auf Ereignisse für die Schreibweiterleitung in Aurora Postgre SQL

Amazon Aurora generiert die folgenden Warteereignisse, wenn Sie die Schreibweiterleitung mit Aurora Postgre SQL 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 Postgre SQL.

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 der Aurora Postgre-Replikation SQL.

• 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 die Operationen in der Datenmanipulationssprache (DML), sodass nur die erforderlichen Daten geändert werden.

• Wenn der Writer-Knoten des sekundären Knotens oder der primären Region durch CPU die 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 GLOBAL Konsistenzmodus 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 Writer-Knoten des sekundären Knotens oder der primären Region durch CPU die 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 Writer-Knoten des sekundären Knotens oder der primären Region durch CPU die 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 Writer-Knoten des sekundären Knotens oder der primären Region durch CPU die 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 Writer-Knoten des sekundären Knotens oder der primären Region durch CPU die Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, ihn auf einen Instance-Typ mit mehr CPU Kapazität oder mehr Netzwerkbandbreite umzustellen.