# Supervisión de la memoria caché de escritura indirecta y de las ranuras lógicas para la replicación lógica de Aurora PostgreSQL
Supervise la memoria caché de escritura indirecta de la replicación lógica y administre las ranuras lógicas para mejorar el rendimiento del clúster de base de datos de Aurora PostgreSQL. A continuación, encontrará más información sobre la memoria caché de escritura indirecta y las ranuras lógicas.
**Topics**
+ [
## Supervisión de la memoria caché de escritura indirecta de la replicación lógica en Aurora PostgreSQL
](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [
## Administración de ranuras lógicas para Aurora PostgreSQL
](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Supervisión de la memoria caché de escritura indirecta de la replicación lógica en Aurora PostgreSQL
De forma predeterminada, las versiones 14.5, 13.8, 12.12 y 11.17 y posteriores de Aurora PostgreSQL utilizan una memoria caché de escritura para mejorar el rendimiento de la replicación lógica. Sin la memoria caché de escritura, Aurora PostgreSQL utiliza la capa de almacenamiento de Aurora en su implementación del proceso de replicación lógica nativo de PostgreSQL. Para ello, escribe los datos de WAL en el almacenamiento y, a continuación, los lee del almacenamiento para decodificarlos y enviarlos (replicarlos) a sus destinos (suscriptores). Esto puede provocar cuellos de botella durante la replicación lógica de los clústeres de bases de datos de Aurora PostgreSQL.
La memoria caché de escritura reduce al mínimo la dependencia de la capa de almacenamiento de Aurora. En lugar de escribir y leer de manera constante en esta capa, Aurora PostgreSQL utiliza un búfer para almacenar en caché el flujo WAL lógico de modo que pueda usarse durante el proceso de replicación, lo que reduce la necesidad de acceder al disco. Este búfer es la memoria caché nativa de PostgreSQL que utiliza la replicación lógica y que se identifica en los parámetros del clúster de base de datos de Aurora PostgreSQL como `rds.logical_wal_cache`.
Al utilizar la replicación lógica con el clúster de base de datos de Aurora PostgreSQL (para las versiones que admiten la caché de escritura), puede supervisar la tasa de aciertos de caché para comprobar cómo funciona en su caso de uso. Para ello, conéctese a la instancia de escritura del clúster de base de datos de Aurora PostgreSQL mediante la función de Aurora `psql` y, a continuación, utilice la función de Aurora `aurora_stat_logical_wal_cache`, como se muestra en el siguiente ejemplo.
```
SELECT * FROM aurora_stat_logical_wal_cache();
```
La función devuelve una salida como la siguiente:
```
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)
```
Los valores de `last_reset_timestamp` se han acortado para facilitar la lectura. Para obtener más información acerca de esta función, consulte [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL proporciona las dos funciones siguientes para supervisar la memoria caché de escritura.
+ La función:`aurora_stat_logical_wal_cache` para obtener documentación de referencia, consulte [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ La función:`aurora_stat_reset_wal_cache` para obtener documentación de referencia, consulte [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
Si descubre que el tamaño de la caché de WAL que se ha ajustado automáticamente no es suficiente para sus cargas de trabajo, puede cambiar el valor de `rds.logical_wal_cache` manualmente. Considere lo siguiente:
+ Cuando el parámetro `rds.logical_replication` está deshabilitado, `rds.logical_wal_cache` se establece en cero (0).
+ Cuando el parámetro `rds.logical_replication` está habilitado, `rds.logical_wal_cache` tiene un valor predeterminado de 16 MB.
+ El parámetro `rds.logical_wal_cache` es estático y requiere un reinicio de la instancia de base de datos para que los cambios surtan efecto. Este parámetro se define en términos de bloques de 8 Kb. Tenga en cuenta que cualquier valor positivo inferior a 32 Kb se considera 32 Kb. Para obtener más información sobre `wal_buffers`, consulte [Registro de escritura anticipada](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) en la documentación de PostgreSQL.
## Administración de ranuras lógicas para Aurora PostgreSQL
La actividad de streaming se captura en la vista `pg_replication_origin_status`. Para ver el contenido de esta vista, puede usar la función `pg_show_replication_origin_status()`, tal como se muestra a continuación:
```
SELECT * FROM pg_show_replication_origin_status();
```
Puede obtener una lista de las ranuras lógicas mediante la siguiente consulta SQL.
```
SELECT * FROM pg_replication_slots;
```
Para eliminar una ranura lógica, use `pg_drop_replication_slot` con el nombre de la ranura, como se muestra en el siguiente comando.
```
SELECT pg_drop_replication_slot('test_slot');
```