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. # Lokale Schreibweiterleitung in Aurora PostgreSQL *Lokale (clusterinterne) Schreibweiterleitung* ermöglicht Ihren Anwendungen, Lese-/Schreibtransaktionen direkt auf einem Aurora-Replikat durchzuführen. Die Schreibbefehle werden dann zum Commit an die Writer-DB-Instance weitergeleitet. Sie können die lokale Schreibweiterleitung für Anwendungen verwenden, bei denen gelegentlich Schreibvorgänge auftreten und die *Lesen-nach-Schreiben-Konsistenz* erfordern. Dies ist die Fähigkeit, den letzten Schreibvorgang in einer Transaktion zu lesen. Ohne Schreibweiterleitung müssen Ihre Anwendungen den gesamten Lese- und Schreibverkehr vollständig aufteilen und zwei Gruppen von Datenbankverbindungen aufrechterhalten, um den Datenverkehr an den richtigen Endpunkt zu senden. Lesereplikate erhalten asynchron Updates von der Writer-Instance. Da die Replikationsverzögerung zwischen Lesereplikaten unterschiedlich sein kann, ist es außerdem schwierig, eine globale Lesekonsistenz für alle Replikate zu erreichen. Die Transaktion aller Lesevorgänge, die eine Lesen-nach-Schreiben-Konsistenz erfordern, muss auf der Writer-Datenbank-Instance erfolgen. Alternativ müssen Sie eine komplexe benutzerdefinierte Anwendungslogik entwickeln, um aus Gründen der Skalierbarkeit mehrere Lesereplikate nutzen zu können und gleichzeitig die Konsistenz sicherzustellen. Durch die Schreibweiterleitung müssen diese Transaktionen nicht aufgeteilt oder ausschließlich an die Writer-Instance gesendet werden. Sie müssen auch keine komplexe Anwendungslogik entwickeln, um *Lesen-nach-Schreiben-Konsistenz* zu erreichen. Die lokale Schreibweiterleitung ist in jeder Region verfügbar, in der Aurora PostgreSQL verfügbar ist. Sie wird in folgenden Aurora-PostgreSQL-Versionen unterstützt: + 16.4 und höhere 16-Versionen + 15.8 und höhere 15-Versionen + 14.13 und höhere 14-Versionen Die lokale Schreibweiterleitung wird verwendet, um Schreibvorgänge von Replikaten innerhalb der Region weiterzuleiten. Informationen zur Weiterleitung von Schreibvorgängen aus einem globalen Replikat finden Sie unter [Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank](aurora-global-database-write-forwarding.md). **Topics** + [Einschränkungen und Überlegungen zur lokalen Schreibweiterleitung in Aurora PostgreSQL](aurora-postgresql-write-forwarding-limitations.md) + [Konfiguration von Aurora PostgreSQL für die lokale Schreibweiterleitung](aurora-postgresql-write-forwarding-configuring.md) + [Arbeiten mit der lokalen Schreibweiterleitung für Aurora PostgreSQL](aurora-postgresql-write-forwarding-understanding.md) + [Überwachen der lokalen Schreibweiterleitung in Aurora PostgreSQL](aurora-postgresql-write-forwarding-monitoring.md) # Einschränkungen und Überlegungen zur lokalen Schreibweiterleitung in Aurora PostgreSQL Für die lokale Schreibweiterleitung in Aurora PostgreSQL gelten aktuell die folgenden Einschränkungen: + Die lokale Schreibweiterleitung wird für RDS-Proxy nicht unterstützt. + Bestimmte Anweisungen sind nicht zulässig oder können veraltete Ergebnisse erzeugen, wenn Sie sie in Aurora PostgreSQL mit Schreibweiterleitung verwenden. Darüber hinaus werden benutzerdefinierte Funktionen und benutzerdefinierte Prozeduren nicht unterstützt. Daher ist die Einstellung `EnableLocalWriteForwarding` für DB-Cluster standardmäßig deaktiviert. Stellen Sie vor einer Aktivierung sicher, dass der Anwendungscode von keiner dieser Einschränkungen betroffen ist. + Die folgenden Arten von SQL-Anweisungen werden bei Schreibweiterleitung nicht unterstützt: **Anmerkung** Diese Anweisungen können von Ihnen implizit in Ihrer Anwendung verwendet oder vom PostgreSQL-Protokoll abgeleitet werden. Beispielsweise kann die PL/SQL-Ausnahmebehandlung zur Verwendung von SAVEPOINT führen, was keine unterstützte Anweisung ist. + `ANALYZE` + `CLUSTER` + `COPY` + Cursor – Cursor werden nicht unterstützt. Stellen Sie daher sicher, dass Sie sie schließen, bevor Sie die lokale Schreibweiterleitung verwenden. + DDL-Anweisungen (Data Definition Language) + `GRANT`\$1`REVOKE`\$1`REASSIGN OWNED`\$1`SECURITY LABEL` + `LISTEN / NOTIFY` + `LOCK` + `SAVEPOINT` + `SELECT INTO` + `SET CONSTRAINTS` + Sequenzaktualisierungen: `nextval()`, `setval()` + `TRUNCATE` + Zwei-Phasen-Commit-Befehle: `PREPARE TRANSACTION`, `COMMIT PREPARED`, `ROLLBACK PREPARED` + Benutzerdefinierte Funktionen und benutzerdefinierte Prozeduren. + `VACUUM` Sie können die folgenden SQL-Anweisungen mit Schreibweiterleitung verwenden: + 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 die Writer-DB-Instance weitergeleitet und dort ausgeführt. + Data Manipulation Language (DM)-Anweisungen wie `INSERT`, wie`DELETE` und `UPDATE`. + `EXPLAIN`-Anweisungen mit den Anweisungen in dieser Liste. + `PREPARE`- und `EXECUTE`-Anweisungen. + `SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }`-Anweisungen. # Konfiguration von Aurora PostgreSQL für die lokale Schreibweiterleitung Mithilfe der Informationen in den folgenden Abschnitten können Sie die lokale Schreibweiterleitung für Ihren Amazon-Aurora-PostgreSQL-DB-Cluster aktivieren, Konsistenzstufen konfigurieren und Transaktionen mit Schreibweiterleitung verwalten. ## Aktivieren der lokalen Schreibweiterleitung Standardmäßig ist die lokale Schreibweiterleitung für Aurora-PostgreSQL-DB-Cluster nicht aktiviert. Sie aktivieren die lokale Schreibweiterleitung auf Cluster-Ebene, nicht auf Instance-Ebene. ### Konsole Wählen Sie in der AWS-Managementkonsole das Kontrollkästchen **Lokale Schreibweiterleitung aktivieren** unter **Read-Replica-Schreibweiterleitung aktivieren** aus, wenn Sie einen DB-Cluster erstellen oder ändern. ### AWS CLI Wenn Sie die lokale Schreibweiterleitung über die AWS CLI aktivieren möchten, verwenden Sie die Option `--enable-local-write-forwarding`. Diese Option funktioniert, wenn Sie über den Befehl `create-db-cluster` einen neuen DB-Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen DB-Cluster über den Befehl `modify-db-cluster` ändern. Sie können die lokale Schreibweiterleitung deaktivieren, indem Sie die Option `--no-enable-local-write-forwarding` mit denselben CLI-Befehlen verwenden. Im folgenden Beispiel wird ein Aurora-PostgreSQL-DB-Cluster mit aktivierter lokaler Schreibweiterleitung erstellt. ``` aws rds create-db-cluster \ --db-cluster-identifier write-forwarding-test-cluster \ --enable-local-write-forwarding \ --engine aurora-postgresql \ --engine-version 16.4 \ --master-username myuser \ --master-user-password mypassword \ --backup-retention 1 ``` Anschließend erstellen Sie Writer- und Reader-DB-Instances, sodass Sie die Schreibweiterleitung verwenden können. Weitere Informationen finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md). ### RDS-API Um die lokale Schreibweiterleitung über die Amazon-RDS-API zu aktivieren, legen Sie den Parameter `EnableLocalWriteForwarding` auf `true` fest. Dieser Parameter funktioniert, wenn Sie über die Operation `CreateDBCluster` einen neuen DB-Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen DB-Cluster über die Operation `ModifyDBCluster` ändern. Sie können die lokale Schreibweiterleitung deaktivieren, indem Sie den Parameter `EnableLocalWriteForwarding` auf `false` festlegen. ### Aktivieren der lokalen Schreibweiterleitung für Datenbanksitzungen Der Parameter `apg_write_forward.consistency_mode` ist ein DB-Parameter und ein DB-Cluster-Parameter, der die Schreibweiterleitung ermöglicht. Sie können `SESSION`, `EVENTUAL`, `GLOBAL` oder `OFF` als Lesekonsistenzstufe angeben. Weitere Informationen über Konsistenzebenen finden Sie unter [Konsistenz und Isolation für die lokale Schreibweiterleitung in Aurora PostgreSQL](#aurora-postgresql-write-forwarding-isolation). Für diesen Parameter gelten die folgenden Regeln: + Der Standardwert ist `SESSION`. + Die lokale Schreibweiterleitung ist nur verfügbar, wenn `apg_write_forward.consistency_mode` auf `EVENTUAL`, `SESSION` oder `GLOBAL` festgelegt ist. Dieser Parameter ist nur in Reader-Instances von DB-Clustern relevant, für die die lokale Schreibweiterleitung aktiviert ist. + Wenn Sie den Wert auf `OFF` festlegen, wird die lokale Schreibweiterleitung in der Sitzung deaktiviert. ## Konsistenz und Isolation für die lokale Schreibweiterleitung in Aurora PostgreSQL Sie können den Grad der Lesekonsistenz in einem Lesereplikat steuern. Sie können die Lesekonsistenzstufe anpassen, um sicherzustellen, dass alle aus Ihrer Sitzung weitergeleiteten Schreiboperationen im Lesereplikat vor nachfolgenden Abfragen angezeigt werden. Sie können diese Einstellung auch verwenden, um sicherzustellen, dass bei Abfragen des Lesereplikats stets die aktuellen Updates der Writer-DB-Instance 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 Lesereplikate aus, in denen die lokale 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 deaktiviert. Wenn Sie das Konsistenzniveau erhöhen, verbringt Ihre Anwendung mehr Zeit mit dem Warten auf die Propagierung von Änderungen zu Lesereplikaten. Sie können das Verhältnis zwischen geringerer Latenz 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` – Für eine Sitzung auf einem Lesereplikat, das die lokale Schreibweiterleitung verwendet, werden die Ergebnisse aller in dieser Sitzung ausgeführten Ä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 Reader-DB-Instance. Sie wartet nicht auf aktualisierte Ergebnisse aus Schreiboperationen, die in anderen Sitzungen innerhalb des aktuellen DB-Clusters ausgeführt werden. + `EVENTUAL` – Einer Sitzung auf einem Lesereplikat, das die lokale Schreibweiterleitung verwendet, werden möglicherweise Daten angezeigt, die aufgrund von Replikationsverzögerungen leicht veraltet sind. Ergebnisse von Schreibvorgängen in derselben Sitzung sind erst sichtbar, wenn die Schreiboperation auf der Writer-DB-Instance ausgeführt und auf dem Lesereplikat repliziert wurde. 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` – In einer Sitzung auf einem Lesereplikat werden Änderungen angezeigt, die von dieser Sitzung vorgenommen wurden. Außerdem werden ihr alle übergebenen Änderungen sowohl aus der Schreib-DB-Instance als auch aus anderen Lesereplikaten angezeigt. Jede Abfrage kann für einen bestimmten Zeitraum warten, abhängig von der Sitzungsverzögerung. Die Abfrage wird fortgesetzt, wenn das Lesereplikat mit allen übergebenen Daten aus der Writer-DB-Instance mit Stand zu dem Zeitpunkt, an dem die Abfrage gestartet wurde, aktualisiert ist. **Anmerkung** Der globale Konsistenzmodus wirkt sich auf die Latenz von Abfragen aus, die innerhalb einer Sitzung ausgeführt werden. Es gibt eine Wartezeit, auch wenn die Sitzung keine Schreibabfragen gesendet hat. + `OFF` – Die lokale Schreibweiterleitung ist deaktiviert. 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. Weitere Informationen zu allen mit der Schreibweiterleitung verbundenen Parametern finden Sie unter [Standardparametereinstellungen für die Schreibweiterleitung](aurora-postgresql-write-forwarding-understanding.md#aurora-postgresql-write-forwarding-params). ## Transaktionszugriffsmodi mit Schreibweiterleitung Wenn der Transaktionszugriffsmodus schreibgeschützt ist, wird die lokale 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](https://www.postgresql.org/docs/current/sql-set-transaction.html). # Arbeiten mit der lokalen Schreibweiterleitung für Aurora PostgreSQL Mit den Informationen in den folgenden Abschnitten können Sie überprüfen, ob für einen Datenbank-Cluster die lokale Schreibweiterleitung aktiviert ist. Außerdem finden Sie Überlegungen zur Kompatibilität und Informationen zu den konfigurierbaren Parametern und der Einrichtung der Authentifizierung. So können Sie die lokale Schreibweiterleitungsfunktion in Aurora PostgreSQL effektiv nutzen. **Anmerkung** Wenn eine Writer-Instance in einem Cluster, der die lokale Schreibweiterleitung verwendet, neu gestartet wird, werden alle aktiven, weitergeleiteten Transaktionen und Abfragen auf Reader-Instances, die die lokale Schreibweiterleitung verwenden, automatisch geschlossen. Nachdem die Writer-Instance wieder verfügbar ist, können Sie diese Transaktionen erneut versuchen. ## Überprüfen, ob die lokale Schreibweiterleitung für einen DB-Cluster aktiviert ist Wenn Sie bestimmen möchten, ob Sie die lokale Schreibweiterleitung in einem DB-Cluster verwenden können, stellen Sie sicher, dass das `LocalWriteForwardingStatus`-Attribut für den Cluster auf `enabled` festgelegt ist. In der AWS-Managementkonsole sehen Sie auf der Registerkarte **Konfiguration** der Detailseite des Clusters den Status**Aktiviert** für **Lokale Lesereplikat-Schreibweiterleitung**. Um den Status der Einstellung für die lokale Schreibweiterleitung für alle Cluster anzuzeigen, führen Sie den folgenden AWS CLI-Befehl aus. **Example** ``` aws rds describe-db-clusters \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,LocalWriteForwardingStatus:LocalWriteForwardingStatus}' [ { "LocalWriteForwardingStatus": "enabled", "DBClusterIdentifier": "write-forwarding-test-cluster-1" }, { "LocalWriteForwardingStatus": "disabled", "DBClusterIdentifier": "write-forwarding-test-cluster-2" }, { "LocalWriteForwardingStatus": "requested", "DBClusterIdentifier": "test-global-cluster-2" }, { "LocalWriteForwardingStatus": "null", "DBClusterIdentifier": "aurora-postgresql-v2-cluster" } ] ``` Für einen DB-Cluster sind folgende Werte `LocalWriteForwardingStatus` zulässig: + `disabled` – Die lokale Schreibweiterleitung ist deaktiviert. + `disabling` – Die lokale Schreibweiterleitung wird gerade deaktiviert. + `enabled` – Die lokale Schreibweiterleitung ist aktiviert. + `enabling` – Die lokale Schreibweiterleitung wird gerade aktiviert. + `null` – Die lokale Schreibweiterleitung ist für diesen DB-Cluster nicht verfügbar. + `requested` – Die lokale Schreibweiterleitung wurde angefordert, ist aber noch nicht aktiv. ## Standardparametereinstellungen für die Schreibweiterleitung Die Aurora-Cluster-Parametergruppen enthalten Einstellungen für die lokale 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. | Parameter | Scope | Typ | Standardwert | Zulässige Werte | | --- | --- | --- | --- | --- | | apg\$1write\$1forward.connect\$1timeout | Sitzung | Sekunden | 30 | 0 – 2147483647 | | apg\$1write\$1forward.consistency\$1mode | Sitzung | enum | Sitzung | SESSION, EVENTUAL, GLOBAL, und OFF | | apg\$1write\$1forward.idle\$1in\$1transaction\$1session\$1timeout | Sitzung | Millisekunden | 86400000 | 0 – 2147483647 | | apg\$1write\$1forward.idle\$1session\$1timeout | Sitzung | Millisekunden | 300000 | 0 – 2147483647 | | apg\$1write\$1forward.max\$1forwarding\$1connections\$1percent | 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 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 die Writer-DB-Instance, wenn für den Cluster die lokale Schreibweiterleitung aktiviert ist. Verwenden Sie die folgenden Einstellungen, um Anforderungen für die lokale Schreibweiterleitung zu steuern: + `apg_write_forward.consistency_mode` – Ein Parameter auf Sitzungsebene, der den Grad der Lesekonsistenz auf dem Lesereplikat 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 lokale Schreibweiterleitung in der Sitzung deaktiviert. Weitere Informationen über Konsistenzebenen finden Sie unter [Konsistenz und Isolation für die lokale Schreibweiterleitung in Aurora PostgreSQL](aurora-postgresql-write-forwarding-configuring.md#aurora-postgresql-write-forwarding-isolation). Dieser Parameter ist nur in Reader-Instances relevant, für die die lokale Schreibweiterleitung aktiviert ist. + `apg_write_forward.connect_timeout` – Die maximale Anzahl von Sekunden, die das Lesereplikat beim Herstellen einer Verbindung mit der Writer-DB-Instance wartet, bevor der Versuch beendet wird. 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 die Writer-DB-Instance auf Aktivitäten bei einer Verbindung wartet, die von einem Lesereplikat mit einer offenen Transaktion weitergeleitet wurde, bevor die Verbindung beendet wird. 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 die Writer-DB-Instance auf Aktivitäten bei einer Verbindung wartet, die von einem Lesereplikat weitergeleitet wurde, bevor sie beendet wird. Wenn die Sitzung über diesen Zeitraum hinaus inaktiv bleibt, beendet Aurora die Sitzung. Durch einen Wert des Typs `0` wird der Timout deaktiviert. ## rdswriteforwarduser `rdswriteforwarduser` ist ein Benutzer, der verwendet wird, um eine Verbindung zwischen dem Lesereplikat und der Writer-DB-Instance herzustellen. **Anmerkung** `rdswriteforwarduser` erbt die CONNECT-Berechtigungen für Kundendatenbanken über die PUBLIC-Rolle. Wenn die Berechtigungen für die PUBLIC-Rolle entzogen werden, müssen Sie CONNECT-Berechtigungen für die Datenbanken gewähren, an die Sie Schreibvorgänge weiterleiten müssen. # Überwachen der lokalen Schreibweiterleitung in Aurora PostgreSQL Mithilfe der folgenden Abschnitte können Sie die lokale Schreibweiterleitung in Aurora PostgreSQL-Clustern überwachen, einschließlich relevanter CloudWatch Metriken und Warteereignisse, um die Leistung zu verfolgen und potenzielle Probleme zu identifizieren. ## CloudWatch Amazon-Metriken und Aurora PostgreSQL-Statusvariablen für die Schreibweiterleitung Die folgenden CloudWatch Amazon-Metriken gelten für die Writer-DB-Instances, wenn Sie die Schreibweiterleitung für eine oder mehrere Read Replicas verwenden. | CloudWatch Metrik | Einheiten und Beschreibung | | --- | --- | | `AuroraLocalForwardingWriterDMLThroughput` | Anzahl pro Sekunde Anzahl der weitergeleiteten DML-Anweisungen, die pro Sekunde von dieser Writer-DB-Instance verarbeitet werden. | | `AuroraLocalForwardingWriterOpenSessions` | Anzahl Anzahl der offenen Sitzungen auf dieser Writer-DB-Instance, die weitergeleitete Anfragen verarbeiten. | | `AuroraLocalForwardingWriterTotalSessions` | Anzahl Anzahl der weitergeleiteten Sitzungen auf dieser Writer-DB-Instance. | Die folgenden CloudWatch Metriken gelten für jede Read Replica. Diese Metriken werden auf jeder Reader-DB-Instance im DB-Cluster mit aktivierter lokaler 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 auf dem Replikat. DMLs | | `AuroraForwardingReplicaDMLThroughput` | Anzahl pro Sekunde Anzahl der weitergeleiteten DML-Anweisungen, die in diesem Replikat pro Sekunde verarbeitet werden. | | `AuroraForwardingReplicaErrorSessionsLimit` | Anzahl Anzahl der Sitzungen, die von der Writer-DB-Instance zurückgewiesen wurden, weil das Limit für die maximale Zahl von Verbindungen oder die maximalen Verbindungen für die Schreibweiterleitung erreicht wurde. | | `AuroraForwardingReplicaOpenSessions` | Anzahl Die Anzahl der Sitzungen, die die lokale Schreibweiterleitung für eine Replikat-Instance verwenden. | | `AuroraForwardingReplicaReadWaitLatency` | Millisekunden Durchschnittliche Wartezeit in Millisekunden, die das Replikat darauf wartet, mit der LSN der Writer-DB-Instance konsistent zu sein. Das Ausmaß, in dem die Reader-DB-Instance vor der Verarbeitung einer Abfrage wartet, ist von der Einstellung apg\$1write\$1forward.consistency\$1mode abhängig. Weitere Informationen zu dieser Einstellung finden Sie unter [Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg). | ## Warteereignisse für die lokale Schreibweiterleitung in Aurora PostgreSQL Amazon Aurora generiert die folgenden Warteereignisse, wenn Sie die Schreibweiterleitung mit Aurora PostgreSQL verwenden. **Topics** + [IPC: AuroraWriteForwardConnect](#apg-waits.ipcaurorawriteforwardconnect) + [IPC: AuroraWriteForwardConsistencyPoint](#apg-waits.ipcaurorawriteforwardconsistencypoint) + [IPC: AuroraWriteForwardExecute](#apg-waits.ipc:aurorawriteforwardexecute) + [IPC: AuroraWriteForwardGetGlobalConsistencyPoint](#apg-waits.ipc:aurorawriteforwardgetglobalconsistencypoint) + [IPC: AuroraWriteForwardXactAbort](#apg-waits.ipc:aurorawriteforwardxactabort) + [IPC: AuroraWriteForwardXactCommit](#apg-waits.ipc:aurorawriteforwardxactcommit) + [IPC: AuroraWriteForwardXactStart](#apg-waits.ipc:aurorawriteforwardxactstart) ### IPC: AuroraWriteForwardConnect Das `IPC:AuroraWriteForwardConnect`-Ereignis tritt ein, wenn ein Backend-Prozess auf dem Lesereplikat darauf wartet, dass eine Verbindung zur Writer-DB-Instance geöffnet wird. **Wahrscheinliche Ursachen für erhöhte Wartezeiten** Dieses Ereignis nimmt zu, wenn die Anzahl der Verbindungsversuche vom Lesereplikat zum Writer-Knoten zunimmt. **Aktionen** Reduzieren Sie die Anzahl gleichzeitiger Verbindungen von einem Lesereplikat zum Writer-Knoten. ### IPC: AuroraWriteForwardConsistencyPoint Das `IPC:AuroraWriteForwardConsistencyPoint`-Ereignis beschreibt, wie lange eine Abfrage von einem Knoten auf dem Lesereplikat 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 Lesereplikat warten auf die Ergebnisse aller in dieser Sitzung vorgenommenen Änderungen. + `GLOBAL` – Abfragen auf einem Lesereplikat warten auf die Ergebnisse der von dieser Sitzung vorgenommenen Änderungen sowie auf alle festgeschriebenen Änderungen sowohl aus der Writer-DB-Instance als auch aus dem Lesereplikat. Informationen zum Einstellen des Parameters `apg_write_forward.consistency_mode` finden Sie unter [Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg). **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](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Monitoring). + Erhöhte Auslastung der Writer-DB-Instance oder des Lesereplikats. **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 Lesereplikat darauf wartet, dass eine weitergeleitete Abfrage abgeschlossen wird und Ergebnisse vom Writer-Knoten des 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 Anzahl von Zeilen aus dem Writer-Knoten. + Eine erhöhte Netzwerklatenz zwischen dem Writer-Knoten und dem Lesereplikat erhöht die Zeit, die das Lesereplikat benötigt, um Daten vom Writer-Knoten zu empfangen. + Eine erhöhte Auslastung des Lesereplikats kann die Übertragung der Abfrageanforderung vom Lesereplikat zum Writer-Knoten verzögern. + Eine erhöhte Auslastung des Writer-Knotens kann die Übertragung der Daten vom Writer-Knoten zum Lesereplikat 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 das Lesereplikat oder der Writer-Knoten durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, dies 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 Lesereplikat, 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 Lesereplikat und dem Writer-Knoten verlängert die Zeit, die das Lesereplikat benötigt, um Daten vom Writer-Knoten zu empfangen. + Eine erhöhte Auslastung des Lesereplikats kann die Übertragung der Abfrageanforderung vom Lesereplikat zum Writer-Knoten verzögern. + Eine erhöhte Auslastung des Writer-Knotens kann die Übertragung der Daten vom Writer-Knoten zum Lesereplikat 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 das Lesereplikat oder der Writer-Knoten durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, dies auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen. ### IPC: AuroraWriteForwardXactAbort Das `IPC:AuroraWriteForwardXactAbort`-Ereignis tritt ein, wenn ein Backend-Prozess auf dem Lesereplikat 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 Lesereplikat und dem Writer-Knoten verlängert die Zeit, die das Lesereplikat benötigt, um Daten vom Writer-Knoten zu empfangen. + Eine erhöhte Auslastung des Lesereplikats kann die Übertragung der Abfrageanforderung für die Bereinigung vom Lesereplikat zum Writer-Knoten verzögern. + Eine erhöhte Auslastung des Writer-Knotens kann die Übertragung der Daten vom Writer-Knoten zum Lesereplikat verzögern. **Aktionen** Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. + Untersuchen Sie die Ursache für die abgebrochene Transaktion. + Wenn das Lesereplikat oder die Writer-DB-Instance durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, dies 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 Lesereplikat 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 Lesereplikat und dem Writer-Knoten verlängert die Zeit, die das Lesereplikat benötigt, um Daten vom Writer-Knoten zu empfangen. + Eine erhöhte Auslastung des Lesereplikats kann die Übertragung der Abfrageanforderung vom Lesereplikat zum Writer-Knoten verzögern. + Eine erhöhte Auslastung des Writer-Knotens kann die Übertragung der Daten vom Writer-Knoten zum Lesereplikat verzögern. **Aktionen** Wenn das Lesereplikat oder der Writer-Knoten durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, dies 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 Lesereplikat auf das Ergebnis eines weitergeleiteten Start-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 Lesereplikat und dem Writer-Knoten verlängert die Zeit, die das Lesereplikat benötigt, um Daten vom Writer-Knoten zu empfangen. + Eine erhöhte Auslastung des Lesereplikats kann die Übertragung der Abfrageanforderung vom Lesereplikat zum Writer-Knoten verzögern. + Eine erhöhte Auslastung des Writer-Knotens kann die Übertragung der Daten vom Writer-Knoten zum Lesereplikat verzögern. **Aktionen** Wenn das Lesereplikat oder der Writer-Knoten durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, dies auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen.