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.

Überwachung des Write-Through-Cache und der logischen Steckplätze für die logische Aurora SQL Postgre-Replikation

Überwachen Sie den Write-Through-Cache für die logische Replikation und verwalten Sie logische Steckplätze, um die Leistung Ihres Aurora Postgre-DB-Clusters zu verbessern. SQL Im Folgenden finden Sie weitere Informationen zum Write-Through-Cache und zu den logischen Steckplätzen.

Überwachung des Write-Through-Cache für die SQL logische Replikation von Aurora Postgre

Standardmäßig verwenden Aurora SQL Postgre-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 SQL verwendet Aurora Postgre die Aurora-Speicherschicht bei der Implementierung des systemeigenen logischen SQL Postgre-Replikationsprozesses. Dazu werden WAL Daten in den Speicher geschrieben und dann aus dem Speicher zurückgelesen, um sie zu dekodieren und an ihre Ziele (Abonnenten) zu senden (zu replizieren). Dies kann zu Engpässen bei der logischen Replikation für Aurora Postgre-DB-Cluster führen. SQL

Der Write-Through-Cache reduziert die Notwendigkeit, die Aurora-Speicherschicht zu verwenden. Anstatt immer aus der Aurora-Speicherschicht zu schreiben und zu lesen, SQL verwendet Aurora Postgre einen Puffer, um den logischen WAL Stream zwischenzuspeichern, sodass er während des Replikationsprozesses verwendet werden kann, anstatt immer von der Festplatte abgerufen zu werden. Dieser Puffer ist der SQL native Postgre-Cache, der für die logische Replikation verwendet wird und in den Aurora SQL Postgre-DB-Clusterparametern als identifiziert wird. rds.logical_wal_cache Standardmäßig verwendet dieser Cache 1/32 der Puffer-Cache-Einstellung (shared_buffers) des Aurora SQL Postgre-DB-Clusters, aber nicht weniger als 64 kB und nicht mehr als die Größe eines WAL Segments, typischerweise 16 MB.

Wenn Sie logische Replikation mit Ihrem Aurora SQL Postgre-DB-Cluster verwenden (für die Versionen, die den Write-Through-Cache unterstützen), können Sie die Cache-Trefferquote überwachen, um zu sehen, wie gut sie für Ihren Anwendungsfall funktioniert. Stellen Sie dazu mithilfe der Aurora-Funktion eine Verbindung zur Schreibinstanz Ihres Aurora SQL Postgre-DB-Clusters her psql und verwenden Sie sie dannaurora_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 Postgre SQL bietet die folgenden zwei Funktionen zur Überwachung des Write-Through-Cache.

Wenn Sie feststellen, dass die automatisch angepasste WAL Cachegröße für Ihre Workloads nicht ausreicht, können Sie den Wert von rds.logical_wal_cache manuell ändern, indem Sie den Parameter in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe ändern. Beachten Sie, dass jeder positive Wert unter 32 kB als 32 kB behandelt wird. Weitere Informationen dazu finden Sie unter Write Ahead Log in der Postgre-Dokumentation. wal_buffers SQL

Verwaltung logischer Steckplätze für Aurora Postgre SQL

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

Mithilfe der folgenden SQL Abfrage können Sie eine Liste Ihrer logischen Steckplätze 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');