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.

Ü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_stat_logical_wal_cache.

Aurora PostgreSQL bietet die beiden folgenden Funktionen zur Überwachung des Write-Through-Cache.

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:

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');