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 minimiert die Abhängigkeit von der Aurora-Speicherschicht. Anstatt konsistent auf diese Ebene zu schreiben und von ihr zu lesen, SQL verwendet Aurora Postgre einen Puffer, um den logischen WAL Stream zwischenzuspeichern, damit er während des Replikationsprozesses verwendet werden kann. Dadurch wird der Festplattenzugriff reduziert. Dieser Puffer ist der native SQL Postgre-Cache, der bei der logischen Replikation verwendet wird und in den Aurora SQL Postgre-DB-Clusterparametern als identifiziert wird. rds.logical_wal_cache

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 für manuell ändern. rds.logical_wal_cache Berücksichtigen Sie dabei Folgendes:

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

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