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.
# Überwachen des Write-Through-Caches und der logischen Slots für die logische Replikation in Aurora PostgreSQL
Überwachen Sie den Write-Through-Cache für die logische Replikation und verwalten Sie die logischen Slots, um die Leistung Ihres DB-Clusters in Aurora PostgreSQL zu verbessern. Im Folgenden finden Sie weitere Informationen zum Write-Through-Cache und zu den logischen Slots.
**Topics**
+ [
## Überwachen des Write-Through-Caches für die logische Replikation in Aurora PostgreSQL
](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [
## Verwalten logischer Slots für Aurora PostgreSQL
](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Überwachen des Write-Through-Caches für die logische Replikation in Aurora PostgreSQL
Standardmäßig verwenden die Aurora-PostgreSQL-Versionen 14.5, 13.8, 12.12 und 11.17 und höher einen Write-Through-Cache, um die Leistung für die logische Replikation zu verbessern. Ohne den Write-Through-Cache verwendet Aurora PostgreSQL die Aurora-Speicherschicht bei der Implementierung des nativen logischen PostgreSQL-Replikationsprozesses. Dazu schreibt es WAL-Daten in den Speicher und liest die Daten dann wieder aus dem Speicher, um sie zu dekodieren und an ihre Ziele (Abonnenten) zu senden (zu replizieren). Dies kann zu Engpässen bei der logischen Replikation für DB-Cluster von Aurora PostgreSQL führen.
Der Write-Through-Cache minimiert die Abhängigkeit von der Aurora-Speicherschicht. Statt fortlaufender Schreib- und Lesezugriffe auf diese Schicht nutzt Aurora PostgreSQL einen Puffer, der den logischen WAL-Stream für die Replikation zwischenspeichert und so Festplattenzugriffe reduziert. Dieser Puffer ist der native PostgreSQL-Cache, der in der logischen Replikation verwendet wird. Er wird in den DB-Cluster-Parametern von Aurora PostgreSQL als `rds.logical_wal_cache` identifiziert.
Wenn Sie die logische Replikation mit Ihrem DB-Cluster von Aurora PostgreSQL verwenden (für die Versionen, die den Write-Through-Cache unterstützen), können Sie die Cache-Trefferrate überwachen, um festzustellen, wie gut sie für Ihren Anwendungsfall funktioniert. Stellen Sie dazu mit `psql` eine Verbindung mit der Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL her und verwenden Sie dann die Aurora-Funktion `aurora_stat_logical_wal_cache`, wie im folgenden Beispiel gezeigt.
```
SELECT * FROM aurora_stat_logical_wal_cache();
```
Die Funktion gibt beispielsweise die folgende Ausgabe zurück.
```
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39...
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34...
(2 rows)
```
Die `last_reset_timestamp`-Werte wurden aus Gründen der Lesbarkeit gekürzt. Weitere Informationen zu dieser Funktion finden Sie unter [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL bietet die beiden folgenden Funktionen zur Überwachung des Write-Through-Cache.
+ Die `aurora_stat_logical_wal_cache`-Funktion – Die Referenzdokumentation finden Sie unter [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ Die `aurora_stat_reset_wal_cache`-Funktion – Die Referenzdokumentation finden Sie unter [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
Wenn Sie feststellen, dass die automatisch angepasste WAL-Cache-Größe für Ihre Workloads nicht ausreicht, können Sie den Wert von `rds.logical_wal_cache` manuell ändern. Berücksichtigen Sie dabei Folgendes:
+ Wenn der Parameter `rds.logical_replication` deaktiviert ist, wird `rds.logical_wal_cache` auf Null (0) gesetzt.
+ Wenn der Parameter `rds.logical_replication` aktiviert ist, hat `rds.logical_wal_cache` einen Standardwert von 16 MB.
+ Der Parameter `rds.logical_wal_cache` ist statisch und erfordert einen Neustart der Datenbank-Instance, damit Änderungen wirksam werden. Dieser Parameter ist in Form von 8-KB-Blöcken definiert. Beachten Sie, dass jeder positive Wert unter 32 KB als 32 KB behandelt wird. Weitere Informationen über `wal_buffers` finden Sie unter [Write-Ahead-Protokoll](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) in der PostgreSQL-Dokumentation.
## Verwalten logischer Slots für Aurora PostgreSQL
Streaming-Aktivitäten werden in der `pg_replication_origin_status`-Ansicht erfasst. Wenn Sie den Inhalt dieser Ansicht anzeigen möchten, können Sie die `pg_show_replication_origin_status()`-Funktion verwenden, wie im Folgenden gezeigt:
```
SELECT * FROM pg_show_replication_origin_status();
```
Sie können eine Liste Ihrer logischen Slots mit der folgenden SQL-Abfrage abrufen.
```
SELECT * FROM pg_replication_slots;
```
Zum Löschen eines logischen Slots können Sie den `pg_drop_replication_slot` mit dem Namen des Slots verwenden, wie im folgenden Befehl gezeigt.
```
SELECT pg_drop_replication_slot('test_slot');
```