Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Monitoraggio della cache di scrittura e degli slot logici per la replica logica di Aurora Postgree SQL

Monitora la cache write-through della replica logica e gestisci gli slot logici per migliorare le prestazioni del tuo cluster Aurora Postgree DB. SQL Di seguito, sono disponibili ulteriori informazioni sulla cache di scrittura e sugli slot logici.

Monitoraggio della cache write-through della replica logica di Aurora Postgree SQL

Per impostazione predefinita, SQL le versioni 14.5, 13.8, 12.12 e 11.17 di Aurora Postgre e successive utilizzano una cache di scrittura per migliorare le prestazioni per la replica logica. Senza la cache di scrittura, Aurora Postgre SQL utilizza il livello di archiviazione Aurora per implementare il processo di replica logica di Postgre nativo. SQL A tale scopo, scrive WAL i dati nello storage e quindi li rilegge per decodificarli e inviarli (replicarli) ai destinatari (abbonati). Ciò può causare colli di bottiglia durante la replica logica per i cluster Aurora Postgre DB. SQL

La cache write-through riduce la necessità di utilizzare il livello di archiviazione Aurora. Invece di scrivere e leggere sempre dal livello di archiviazione Aurora, Aurora Postgre SQL utilizza un buffer per memorizzare nella cache il WAL flusso logico in modo che possa essere utilizzato durante il processo di replica, anziché estrarlo sempre dal disco. Questo buffer è la cache SQL nativa di Postgre utilizzata dalla replica logica, identificata nei parametri del cluster Aurora Postgre DB come. SQL rds.logical_wal_cache Per impostazione predefinita, questa cache utilizza 1/32 dell'impostazione della cache buffer del cluster Aurora SQL Postgre DB shared_buffers () ma non meno di 64 kB né più della dimensione di un segmento, in genere 16 MB. WAL

Quando utilizzi la replica logica con il tuo cluster Aurora SQL Postgre DB (per le versioni che supportano la cache write-through), puoi monitorare il rapporto di accesso alla cache per vedere se funziona bene per il tuo caso d'uso. A tale scopo, connettiti all'istanza di scrittura del cluster Aurora Postgre SQL DB utilizzando psql e quindi utilizza la funzione Auroraaurora_stat_logical_wal_cache, come illustrato nell'esempio seguente.

SELECT * FROM aurora_stat_logical_wal_cache();

La funzione restituisce un output come il seguente:

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)

I valori last_reset_timestamp sono stati abbreviati per garantire la leggibilità. Per ulteriori informazioni su questa funzione, consulta aurora_stat_logical_wal_cache.

Aurora Postgre SQL offre le seguenti due funzioni per il monitoraggio della cache di scrittura.

Se ritieni che la dimensione della WAL cache regolata automaticamente non sia sufficiente per i tuoi carichi di lavoro, puoi modificare il valore della cache rds.logical_wal_cache manualmente, modificando il parametro nel gruppo di parametri del cluster DB personalizzato. Tieni presente che qualsiasi valore positivo inferiore a 32 KB viene considerato come 32 KB. Per ulteriori informazioni suwal_buffers, consulta Write Ahead Log nella documentazione di SQL Postgre.

Gestione degli slot logici per Aurora Postgre SQL

L'attività di streaming viene acquisita nella vista pg_replication_origin_status. Per visualizzare il contenuto di questa vista, è possibile utilizzare la funzione pg_show_replication_origin_status(), come illustrato di seguito:

SELECT * FROM pg_show_replication_origin_status();

È possibile ottenere un elenco degli slot logici utilizzando la seguente query. SQL

SELECT * FROM pg_replication_slots;

Per eliminare uno slot logico, utilizza pg_drop_replication_slot con il nome dello slot, come illustrato nel seguente comando.

SELECT pg_drop_replication_slot('test_slot');