# Identificación y resolución de los bloqueadores de vaciado intensivo en RDS para PostgreSQL
En PostgreSQL, la limpieza es fundamental para garantizar el buen estado de la base de datos, ya que recupera espacio de almacenamiento y evita problemas relacionados con los [identificadores de transacciones](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND). Sin embargo, hay situaciones que pueden impedir que el vaciado funcione como es debido, lo que puede mermar el rendimiento, provocar una sobrecarga de almacenamiento e incluso afectar a la disponibilidad de la instancia de base de datos debido a la superposición de ID de transacción. Por lo tanto, identificar y resolver estos problemas es esencial para lograr un rendimiento y una disponibilidad óptimos de la base de datos. Consulte [Understanding autovacuum in Amazon RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) si desea conocer mejor la limpieza automática.
La función `postgres_get_av_diag()` ayuda a identificar los problemas que impiden o retrasan el avance de la limpieza agresiva. Se proporcionan sugerencias, entre otras, comandos para resolver el problema si es identificable o indicaciones para realizar diagnósticos adicionales cuando no se puede identificar el problema. Los bloqueadores de limpieza agresiva aparecen cuando su antigüedad supera el umbral de [vacío automático adaptativo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) establecido por RDS, que es de 500 millones de identificadores de transacciones.
**Qué antigüedad tiene el identificador de la transacción?**
La función `age()` de identificadores de transacción calcula el número de transacciones que se han producido desde el identificador de transacción descongelado más antiguo de una base de datos (`pg_database.datfrozenxid`) o tabla (`pg_class.relfrozenxid`). Este valor indica la actividad de la base de datos desde la última operación de limpieza agresiva y resalta la carga de trabajo probable para los próximos procesos de LIMPIEZA.
**Qué es una limpieza agresiva?**
Una operación de LIMPIEZA agresiva lleva a cabo un escaneo exhaustivo de todas las páginas de una tabla, incluidas las que normalmente se omiten durante las limpiezas normales. Este análisis exhaustivo tiene como objetivo congelar los ID de transacción que se acercan a su antigüedad máxima, evitando de forma eficaz una situación conocida como [superposición de identificadores de transacción](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
Para que `postgres_get_av_diag()` pueda detectar bloqueadores, el bloqueador debe haber realizado al menos 500 millones de transacciones.
**Topics**
+ [Instalación de herramientas de supervisión y diagnóstico de autovacuum en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [Funciones de postgres\$1get\$1av\$1diag() en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [Resolución de bloqueadores de vaciado identificables en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [Resolución de bloqueadores de vaciado no identificables en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [Resolución de problemas de rendimiento de vaciado en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [Explicación de los mensajes de tipo NOTICE en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# Instalación de herramientas de supervisión y diagnóstico de autovacuum en RDS para PostgreSQL
La función `postgres_get_av_diag()` está disponible actualmente en las siguientes versiones de RDS para PostgreSQL:
+ Versión 17.2 y otras versiones 17 superiores
+ Versión 16.7 y otras versiones 16 superiores
+ Versión 15.11 y otras versiones 15 superiores
+ Versión 14.16 y otras versiones 14 superiores
+ Versión 13.19 y otras versiones 13 superiores
Para utilizar `postgres_get_av_diag()`, cree la extensión `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Compruebe que la extensión esté instalada.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Compruebe que la función se haya creado.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# Funciones de postgres\$1get\$1av\$1diag() en RDS para PostgreSQL
La función `postgres_get_av_diag()` recupera información de diagnóstico sobre los procesos de autovacuum que se bloquean o se retrasan en una base de datos de RDS para PostgreSQL. La consulta debe ejecutarse en la base de datos con el ID de transacción más antiguo para obtener resultados precisos. Para obtener más información sobre el uso de la base de datos con el ID de transacción más antiguo, consulte [Not connected to the database with the age of oldest transaction ID](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
La función `postgres_get_av_diag()` devuelve una tabla con la siguiente información:
**blocker**
Especifica la categoría de actividad de la base de datos que bloquea el vaciado.
+ [Instrucción activa](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Inactividad en la transacción](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transacción preparada](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Ranura de replicación lógica](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Réplica de lectura con ranura de replicación física](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Réplica de lectura con replicación de streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tablas temporales](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**database**
Especifica el nombre de la base de datos, si está disponible y es compatible. Esta es la base de datos en la que la actividad está en curso y bloquea o bloqueará el autovacuum. Esta es la base de datos a la que debe conectarse y sobre la que debe actuar.
**blocker\$1identifier**
Especifica el identificador de la actividad que bloquea o bloqueará el autovacuum. El identificador puede ser un ID de proceso junto con una instrucción SQL, una transacción preparada, una dirección IP de una réplica de lectura y el nombre de la ranura de replicación, ya sea lógica o física.
**wait\$1event**
Especifica el [evento de espera](PostgreSQL.Tuning.md) de la sesión de bloqueo y se aplica a los siguientes bloqueadores:
+ Instrucción activa
+ Inactividad en la transacción
**autovacum\$1lagging\$1by**
Especifica el número de transacciones que tiene pendiente el autovacuum según sus trabajos por realizar y por categoría.
**suggestion**
Especifica sugerencias para resolver el bloqueo. Estas instrucciones incluyen el nombre de la base de datos en la que existe la actividad, cuando proceda, el ID de proceso (PID) de la sesión, cuando proceda, y la acción que se debe realizar.
**suggested\$1action**
Sugiere la acción que se debe llevar a cabo para resolver el bloqueo.
# Resolución de bloqueadores de vaciado identificables en RDS para PostgreSQL
Autovacuum lleva a cabo vaciados de forma intensiva y reduce la antigüedad de los ID de transacción hasta situarlos por debajo del umbral especificado por el parámetro `autovacuum_freeze_max_age` de la instancia de RDS. Esta antigüedad se puede consultar mediante la métrica `MaximumUsedTransactionIDs` de Amazon CloudWatch.
Para encontrar la configuración de `autovacuum_freeze_max_age` (que tiene un valor predeterminado de 200 millones de ID de transacción) para una instancia de Amazon RDS, puede utilizar la siguiente consulta:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Tenga en cuenta que `postgres_get_av_diag()` solo comprueba si hay bloqueadores de vaciado intensivo cuando la antigüedad supera el umbral de [autovacuum adaptativo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) de Amazon RDS de 500 millones de ID de transacción. Para que `postgres_get_av_diag()` detecte los bloqueadores, el bloqueador debe tener al menos 500 millones de transacciones de antigüedad.
La función `postgres_get_av_diag()` identifica los siguientes tipos de bloqueadores:
**Topics**
+ [Instrucción activa](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Inactividad en la transacción](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transacción preparada](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Ranura de replicación lógica](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Réplicas de lectura](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tablas temporales](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Instrucción activa
En PostgreSQL, una instrucción activa es una instrucción SQL que la base de datos está ejecutando actualmente. Incluye consultas, transacciones o cualquier operación en curso. Al realizar la supervisión mediante `pg_stat_activity`, la columna de estado indica que el proceso con el PID correspondiente está activo.
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando identifica una instrucción que resulta ser una instrucción activa.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Acción sugerida**
Siguiendo las instrucciones de la columna `suggestion`, el usuario puede conectarse a la base de datos en la que se encuentra la instrucción activa y, tal como se especifica en la columna `suggested_action`, se recomienda revisar detenidamente la opción de finalizar la sesión. Si la finalización es segura, se puede utilizar la función `pg_terminate_backend()` para finalizar la sesión. Esta acción la puede realizar un administrador (como la cuenta maestra de RDS) o un usuario con el privilegio `pg_terminate_backend()` necesario.
**aviso**
Al finalizar la sesión, se desharán (`ROLLBACK`) los cambios que haya realizado. En función de sus requisitos, es posible que quiera volver a ejecutar la instrucción. Sin embargo, se recomienda hacerlo únicamente después de que el proceso de autovacuum haya finalizado su operación de vaciado intensivo.
## Inactividad en la transacción
El concepto de inactividad en una instrucción de transacción se refiere a cualquier sesión en la que se haya abierto una transacción explícita (por ejemplo, emitiendo una instrucción `BEGIN`), se haya realizado algún trabajo y se esté esperando a que el cliente pase más trabajo o dé la señal de finalización de la transacción emitiendo una instrucción `COMMIT`, `ROLLBACK` o `END` (lo que daría como resultado un `COMMIT` implícitamente).
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando identifica una instrucción `idle in transaction` como bloqueador.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Acción sugerida**
Como se indica en la columna `suggestion`, puede conectarse a la base de datos en la que se encuentra la sesión de inactividad en la transacción y finalizar la sesión mediante la función `pg_terminate_backend()`. El usuario puede ser su usuario administrador (cuenta maestra de RDS) o un usuario con el privilegio `pg_terminate_backend()`.
**aviso**
Al finalizar la sesión, se desharán (`ROLLBACK`) los cambios que haya realizado. En función de sus requisitos, es posible que quiera volver a ejecutar la instrucción. Sin embargo, se recomienda hacerlo únicamente después de que el proceso de autovacuum haya finalizado su operación de vaciado intensivo.
## Transacción preparada
PostgreSQL permite realizar transacciones que forman parte de una estrategia de confirmación de dos fases denominada [transacciones preparadas](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Se habilitan al establecer el parámetro `max_prepared_transactions` en un valor distinto de cero. Las transacciones preparadas han sido diseñadas para garantizar que una transacción sea duradera y permanezca disponible incluso después de que la base de datos se bloquee, se reinicie o se desconecte del cliente. Al igual que las transacciones normales, se les asigna un identificador de transacción y pueden afectar al autovacuum. Si se deja en un estado preparado, el autovacuum no puede realizar la congelación y podría provocar un reinicio del ID de transacción.
Cuando las transacciones se dejan preparadas indefinidamente sin que las resuelva un administrador de transacciones, se convierten en transacciones preparadas huérfanas. La única forma de solucionar este problema es confirmar o revertir la transacción mediante los comandos `COMMIT PREPARED` o `ROLLBACK PREPARED` respectivamente.
**nota**
Tenga en cuenta que una copia de seguridad realizada durante una transacción preparada seguirá conteniendo esa transacción después de la restauración. Consulte la siguiente información sobre cómo localizar y cerrar dichas transacciones.
La función `postgres_get_av_diag()` muestra el siguiente resultado cuando identifica un bloqueador que es una transacción preparada.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Acción sugerida**
Como se menciona en la columna de sugerencias, conéctese a la base de datos en la que se encuentre la transacción preparada. Sobre la base de la columna `suggested_action`, revise detenidamente si desea enviar una instrucción `COMMIT` o `ROLLBACK`, y realizar la acción correspondiente.
Para supervisar las transacciones preparadas en general, PostgreSQL ofrece una vista de catálogo llamada `pg_prepared_xacts`. Puede utilizar la siguiente consulta para buscar transacciones preparadas.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Ranura de replicación lógica
El propósito de una ranura de replicación es almacenar los cambios no consumidos hasta que se repliquen en un servidor de destino. Para obtener más información, consulte [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) de PostgreSQL.
Existen dos tipos de ranuras de replicación lógica.
**Ranuras de replicación lógica inactivas**
Cuando finaliza la replicación, los registros de transacciones no consumidas no se pueden eliminar y la ranura de replicación queda inactiva. Aunque un suscriptor no utilice actualmente una ranura de replicación lógica inactiva, esta permanece en el servidor, lo que provoca la retención de los archivos WAL y evita la eliminación de los registros de transacciones antiguos. Esto puede aumentar el uso del disco y, específicamente, impedir que autovacuum limpie las tablas del catálogo interno, ya que el sistema debe evitar que se sobrescriba la información de LSN. Si este problema no se soluciona, puede provocar una sobrecarga del catálogo, una degradación del rendimiento y un mayor riesgo de que se produzcan vaciados previos al reinicio, lo que podría causar tiempo de inactividad en las transacciones.
**Ranuras de replicación lógica activas pero lentas**
A veces, la eliminación de las tuplas inactivas del catálogo se retrasa debido a la degradación del rendimiento de la replicación lógica. Este retraso en la replicación ralentiza la actualización de `catalog_xmin` y puede provocar una sobrecarga del catálogo y un vaciado previo al reinicio.
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando encuentra una ranura de replicación lógica que funciona como bloqueador.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Acción sugerida**
Para resolver este problema, compruebe la configuración de la replicación para ver si hay problemas con el esquema o los datos de destino que puedan estar finalizando el proceso de aplicación. Los motivos más comunes son los siguientes:
+ Columnas faltantes
+ Tipos de datos incompatibles
+ Discrepancia de datos
+ Tabla faltante
Si el problema está relacionado con problemas de infraestructura:
+ Problemas de red: [¿cómo resuelvo los problemas con una base de datos de Amazon RDS en un estado de red incompatible?](https://repost.aws/knowledge-center/rds-incompatible-network)
+ La base de datos o la instancia de base de datos no están disponibles por una de las siguientes razones:
+ La instancia de réplica se ha quedado sin espacio de almacenamiento: consulte qué hacer cuando [las instancias de base de datos de Amazon RDS se quedan sin almacenamiento](https://repost.aws/knowledge-center/rds-out-of-storage) para obtener información sobre cómo añadir almacenamiento.
+ Parámetros incompatibles: revise [¿Cómo puedo corregir una instancia de base de datos de Amazon RDS que está estancada en el estado parámetros incompatibles?](https://repost.aws/knowledge-center/rds-incompatible-parameters) para obtener más información acerca de cómo solucionar este problema.
Si la instancia está fuera de la red de AWS o en AWS EC2, consulte a su administrador sobre cómo resolver los problemas relacionados con la disponibilidad o la infraestructura.
**Eliminación de la ranura inactiva**
**aviso**
Precaución: Antes de eliminar una ranura de replicación, asegúrese exhaustivamente de que no tenga ninguna replicación en curso, de que esté inactiva y de que se encuentre en un estado irrecuperable. Si se elimina una ranura de forma prematura, se podría interrumpir la replicación o provocar la pérdida de datos.
Después de confirmar que la ranura de replicación ya no es necesaria, elimínela para permitir que el autovacuum continúe. La condición `active = 'f'` garantiza que solo se eliminará una ranura inactiva.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Réplicas de lectura
Cuando la configuración `hot_standby_feedback` está habilitada para las [réplicas de lectura de Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), evita que el autovacuum de la base de datos principal elimine determinadas filas inactivas que podrían seguir necesitando las consultas que se ejecuten en la réplica de lectura. Esto afecta a todos los tipos de réplicas de lectura físicas, incluidas las que se administran con o sin ranuras de replicación. Este comportamiento es necesario porque las consultas que se ejecutan en la réplica en espera requieren que esas filas permanezcan disponibles en el servidor principal, lo que evita cancelaciones y [conflictos de consultas](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT).
**Réplica de lectura con ranura de replicación física**
Las réplicas de lectura con ranuras de replicación físicas mejoran considerablemente la fiabilidad y la estabilidad de la replicación en RDS para PostgreSQL. Estas ranuras garantizan que la base de datos principal conserve los archivos de registro de escritura anticipada esenciales hasta que la réplica los procese, ya que esto mantiene la coherencia de datos incluso durante las interrupciones de la red.
A partir de la versión 14 de RDS para PostgreSQL, todas las réplicas utilizan ranuras de replicación. En las versiones anteriores, solo las réplicas entre regiones utilizaban ranuras de replicación.
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando encuentra una réplica de lectura con una ranura de replicación física como bloqueador.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Réplica de lectura con replicación de streaming**
Amazon RDS permite configurar réplicas de lectura sin una ranura de replicación física en versiones anteriores, hasta la versión 13. Este enfoque reduce la sobrecarga al permitir que el servidor principal recicle los archivos WAL de forma más intensiva, lo que resulta ventajoso en entornos con limitaciones del espacio en disco y en los que se pueda tolerar un ReplicaLag ocasional. Sin embargo, sin no dispone de una ranura, la réplica en espera debe permanecer sincronizada para evitar que se pierdan archivos WAL. Amazon RDS utiliza archivos WAL archivados para ayudar a la réplica a ponerse al día en caso de que se quede atrás, pero este proceso requiere una supervisión exhaustiva y puede resultar lento.
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando encuentra una réplica de lectura de streaming como bloqueador.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Acción sugerida**
Como se recomienda en la columna `suggested_action`, revise detenidamente estas opciones para desbloquear el autovacuum.
+ **Finalizar la consulta**: de acuerdo con las instrucciones de la columna de sugerencias, puede conectarse a la réplica de lectura, tal y como se especifica en la columna suggested\$1action. Se recomienda revisar detenidamente la opción para finalizar la sesión. Si la finalización se considera segura, se puede utilizar la función `pg_terminate_backend()` para finalizar la sesión. Esta acción la puede realizar un administrador (como la cuenta maestra de RDS) o un usuario con el privilegio pg\$1terminate\$1backend() necesario.
Puede ejecutar el siguiente comando SQL en la réplica de lectura para finalizar la consulta que impide que el proceso de vaciado en el principal pueda limpiar las filas antiguas. El valor de `backend_xmin` se indica en la salida de la función:
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Desactivar la retroalimentación de espera activa**: plantéese deshabilitar el parámetro `hot_standby_feedback` si provoca retrasos significativos en el vaciado.
El parámetro `hot_standby_feedback` permite que una réplica de lectura informe al servidor principal sobre su actividad de consulta, lo que evita que el principal vacíe las tablas o filas que están en uso en la réplica en espera. Si bien esto garantiza la estabilidad de las consultas en la réplica en espera, puede retrasar considerablemente el vaciado en el principal. La desactivación de esta característica permite al servidor principal continuar con el vaciado sin tener que esperar a que la réplica en espera se ponga al día. Sin embargo, esto puede provocar cancelaciones o errores en las consultas en la réplica en espera si intenta acceder a las filas que ha vaciado el principal.
+ **Eliminar la réplica de lectura si no es necesaria**: si la réplica de lectura ya no es necesaria, puede eliminarla. Esto eliminará la sobrecarga de replicación asociada y permitirá que el servidor principal recicle los registros de transacciones sin que la réplica se lo obstaculice.
## Tablas temporales
Las [tablas temporales](https://www.postgresql.org/docs/current/sql-createtable.html), que se crean con la palabra clave `TEMPORARY`, residen en el esquema temporal (por ejemplo, pg\$1temp\$1xxx) y solo la sesión que las haya creado puede acceder a ellas. Las tablas temporales se eliminan al finalizar la sesión. Sin embargo, estas tablas son invisibles para el proceso de autovacuum de PostgreSQL y la sesión que las haya creado debe vaciarlas manualmente. Intentar vaciar la tabla temporal desde otra sesión no tiene ningún efecto.
En circunstancias poco habituales, puede existir una tabla temporal sin que sea propiedad de una sesión activa. Si la sesión propietaria finaliza inesperadamente debido a un bloqueo grave, un problema de red o un suceso similar, es posible que la tabla temporal no se limpie y quede como una tabla “huérfana”. Cuando el proceso de autovacuum de PostgreSQL detecta una tabla temporal huérfana, registra el siguiente mensaje:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando identifica una tabla temporal como bloqueador. Para que la función muestre correctamente el resultado relacionado con las tablas temporales, debe ejecutarse en la misma base de datos en la que se encuentren esas tablas.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Acción sugerida**
Siga las instrucciones que aparecen en la columna `suggestion` del resultado para identificar y eliminar la tabla temporal que impide la ejecución del autovacuum. Use el siguiente comando para eliminar la tabla temporal notificada por `postgres_get_av_diag()`. Reemplace el nombre de la tabla en función del resultado proporcionado por la función `postgres_get_av_diag()`.
```
DROP TABLE my_temp_schema.my_temp_table;
```
La siguiente consulta se puede utilizar para identificar tablas temporales:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# Resolución de bloqueadores de vaciado no identificables en RDS para PostgreSQL
En esta sección se analizan otros motivos que pueden impedir que el progreso del vaciado. Actualmente, la función `postgres_get_av_diag()` no puede identificar directamente estos problemas.
**Topics**
+ [Páginas no válidas](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [Incoherencia en los índices](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [Tasa de transacciones excepcionalmente alta](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Páginas no válidas
Se produce un error de página no válida cuando PostgreSQL detecta una discrepancia en la suma de comprobación de una página al acceder a esa página. El contenido resulta ilegible, lo que impide que autovacuum congele las tuplas. Esto detiene de forma efectiva el proceso de limpieza. El siguiente error está escrito en el registro de PostgreSQL:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Determinar el tipo de objeto**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
A partir del mensaje de error, la ruta `base/16403/186752608` proporciona la siguiente información:
+ “base” es el nombre del directorio de datos de PostgreSQL.
+ “16403” es el OID de la base de datos, que puede buscar en el catálogo del sistema `pg_database`.
+ “186752608” es el `relfilenode`, que puede utilizar para buscar el nombre del objeto y el esquema en el catálogo del sistema `pg_class`.
Al comprobar el resultado de la siguiente consulta en la base de datos afectada, puede determinar el tipo de objeto. La siguiente consulta recupera información de objeto para el oid: 186752608. Sustituya este OID por el correspondiente para el error que haya encontrado.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Para obtener más información, consulte la documentación de PostgreSQL sobre [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) para ver todos los tipos de objetos compatibles, indicados en la columna `relkind` de `pg_class`.
**Indicaciones**
La solución más eficaz para este problema depende de la configuración de la instancia específica de Amazon RDS y del tipo de datos afectados por la página incoherente.
**Si el tipo de objeto es un índice:**
Se recomienda volver a crear el índice.
+ **Uso de la opción `CONCURRENTLY`**: antes de la versión 12 de PostgreSQL, la reconstrucción de un índice requería un bloqueo de tabla exclusivo, lo que restringía el acceso a la misma. Con PostgreSQL versión 12 y versiones posteriores, la opción `CONCURRENTLY` permite el bloqueo por filas, lo que mejora significativamente la disponibilidad de la tabla. A continuación, se muestra el comando:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Si bien `CONCURRENTLY` resulta menos disruptivo, puede ser más lento en tablas de uso intensivo. Si es posible, considere la posibilidad de crear el índice durante los períodos de poco tráfico.
Para obtener más información, consulte la documentación de PostgreSQL sobre [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html).
+ **Uso de la opción `INDEX_CLEANUP FALSE`**: si los índices son grandes y se calcula que tardarán mucho en completarse, puede desbloquear el autovacuum ejecutando un `VACUUM FREEZE` manual y excluyendo los índices. Esta funcionalidad está disponible en la versión 12 y posteriores de PostgreSQL.
Omitir los índices le permitirá saltarse el proceso de vaciado del índice incoherente y mitigar el problema del reinicio. Sin embargo, esto no resolverá el problema subyacente de la página no válida. Para solucionar por completo el problema de la página no válida y resolverlo, tendrá que volver a crear el índice.
**Si el tipo de objeto es una vista materializada:**
Si se produce un error de página no válida en una vista materializada, inicie sesión en la base de datos afectada y actualícela para resolver la página no válida:
Actualice la vista materializada:
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Si se produce un error al actualizar, intente volver a crearla:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
Al actualizar o volver a crear la vista materializada, se restaura sin que esto afecte a los datos de la tabla subyacente.
**Para todos los demás tipos de objetos:**
Para todos los demás tipos de objetos, puede ponerse en contacto con el servicio de asistencia de AWS.
## Incoherencia en los índices
Un índice que no sea coherente desde el punto de vista lógico puede impedir que avance el autovacuum. Los siguientes errores u otros similares se registran durante la fase de vaciado del índice o cuando se accede al índice mediante instrucciones SQL.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Indicaciones**
Reconstruya el índice u omita los índices utilizando `INDEX_CLEANUP` con un `VACUUM FREEZE` manual. Para obtener información sobre cómo reconstruir el índice, consulte [Si el tipo de objeto es un índice](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Uso de la opción CONCURRENTLY**: antes de la versión 12 de PostgreSQL, la reconstrucción de un índice requería un bloqueo de tabla exclusivo, lo que restringía el acceso a la misma. Con PostgreSQL versión 12 y versiones posteriores, la opción CONCURRENTLY permite el bloqueo por filas, lo que mejora significativamente la disponibilidad de la tabla. A continuación, se muestra el comando:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Si bien CONCURRENTLY resulta menos disruptivo, puede ser más lento en tablas de uso intensivo. Si es posible, considere la posibilidad de crear el índice durante los períodos de poco tráfico. Para obtener más información, consulte [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) en la documentación de *PostgreSQL*.
+ **Uso de la opción INDEX\$1CLEANUP FALSE**: si los índices son grandes y se calcula que tardarán mucho en completarse, puede desbloquear el autovacuum ejecutando un VACUUM FREEZE manual y excluyendo los índices. Esta funcionalidad está disponible en la versión 12 y posteriores de PostgreSQL.
Omitir los índices le permitirá saltarse el proceso de vaciado del índice incoherente y mitigar el problema del reinicio. Sin embargo, esto no resolverá el problema subyacente de la página no válida. Para solucionar por completo el problema de la página no válida y resolverlo, tendrá que volver a crear el índice.
## Tasa de transacciones excepcionalmente alta
En PostgreSQL, las tasas de transacción altas pueden afectar significativamente al rendimiento de autovacuum, lo que implica una limpieza más lenta de las tuplas inactivas y a un aumento del riesgo de reiniciar los ID de transacción. Puede supervisar la tasa de transacciones midiendo la diferencia en `max(age(datfrozenxid))` entre dos períodos de tiempo, normalmente por segundo. Además, puede utilizar las siguientes métricas de contador de Información de rendimiento de RDS para medir la tasa de transacciones (la suma de xact\$1commit y xact\$1rollback), que es el número total de transacciones.
| Contador | Tipo | Unidad | Métrica |
| --- | --- | --- | --- |
| xact\$1commit | Transacciones | Confirmaciones por segundo | db.Transactions.xact\$1commit |
| xact\$1rollback | Transacciones | Restauraciones por segundo | db.Transactions.xact\$1rollback |
Un aumento rápido indica una alta carga de transacciones, lo que puede ser excesivo para autovacuum y provocar sobrecargas, bloqueos y posibles problemas de rendimiento. Esto puede tener un impacto negativo en el proceso de autovacuum de dos maneras:
+ **Actividad de la tabla:** la tabla específica que se está vaciando podría estar registrando un gran volumen de transacciones, lo que provocaría retrasos.
+ **Recursos del sistema:** el sistema en general puede estar sobrecargado, lo que dificulta que autovacuum acceda a los recursos necesarios para funcionar de manera eficiente.
Plantéese las siguientes estrategias para permitir que autovacuum funcione de manera más eficaz y pueda seguir el ritmo de sus tareas:
1. Reduzca la tasa de transacciones si es posible. Plantéese la posibilidad de agrupar o agrupar transacciones similares cuando sea posible.
1. Utilice tablas que se actualicen con frecuencia mediante la operación `VACUUM FREEZE` manual cada noche, semana o quincena durante las horas de menor actividad.
1. Plantéese la posibilidad de escalar verticalmente su clase de instancia para asignar más recursos del sistema con el fin de administrar el volumen de transacciones elevado y el autovacuum.
# Resolución de problemas de rendimiento de vaciado en RDS para PostgreSQL
En esta sección se analizan los factores que suelen contribuir a reducir el rendimiento del vaciado y cómo abordar estos problemas.
**Topics**
+ [Vaciado de índices grandes](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [Demasiadas tablas o bases de datos que vaciar](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [Se está ejecutando un vaciado intensivo (para evitar el reinicio)](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Vaciado de índices grandes
VACUUM funciona a través de fases secuenciales: inicialización, escaneo del montón, vaciado de índices y montón, limpieza de índices, truncamiento del montón y limpieza final. Durante el escaneo del montón, el proceso elimina las páginas, las desfragmenta y las congela. Después de completar el escaneo del montón, VACUUM limpia los índices, se devuelven las páginas vacías al sistema operativo y se realizan tareas de limpieza final, como el vaciado del mapa del espacio libre y la actualización de las estadísticas.
Es posible que sea necesario realizar varias pasadas para el vaciado de índices cuando `maintenance_work_mem` (o `autovacuum_work_mem`) no es suficiente para procesar el índice. En la versión 16 y anteriores de PostgreSQL, un límite de memoria de 1 GB para almacenar los ID de tuplas inactivas a menudo forzaba varias pasadas en índices grandes. PostgreSQL 17 presenta `TidStore`, que asigna memoria de forma dinámica en lugar de utilizar una matriz de asignación única. Esto elimina la restricción de 1 GB, utiliza la memoria de manera más eficiente y reduce la necesidad de realizar varios análisis de índice por cada índice.
Es posible que los índices grandes aún requieran varias pasadas en PostgreSQL 17 si la memoria disponible no puede acomodar todo el procesamiento del índice de una vez. Por lo general, los índices mayores contienen más tuplas inactivas que requieren varias pasadas.
**Detección de operaciones de limpieza lentas**
La función `postgres_get_av_diag()` puede detectar cuando las operaciones de limpieza se ejecutan lentamente debido a memoria insuficiente. Para obtener más información sobre esta función, consulte [Instalación de herramientas de supervisión y diagnóstico de autovacuum en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
La función `postgres_get_av_diag()` emite los siguientes avisos cuando la memoria disponible no es suficiente para completar la limpieza del índice en una sola pasada.
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**nota**
La función `postgres_get_av_diag()` se basa en `pg_stat_all_tables.n_dead_tup` para estimar la cantidad de memoria necesaria para el vaciado de índices.
Cuando la función `postgres_get_av_diag()` identifique una operación de limpieza lenta que requiera múltiples análisis de índice debido a que no hay suficiente `autovacuum_work_mem`, generará el siguiente mensaje:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Indicaciones**
Puede aplicar las siguientes soluciones alternativas utilizando manualmente `VACUUM FREEZE` para acelerar la congelación de la tabla.
**Aumentar la memoria de vaciado**
Como sugiere la función `postgres_get_av_diag()`, se recomienda aumentar el parámetro `autovacuum_work_mem` para abordar las posibles restricciones de memoria en cada instancia. Aunque `autovacuum_work_mem` es un parámetro dinámico, es importante tener en cuenta que, para que la nueva configuración de memoria surta efecto, el daemon de autovacuum debe reiniciar sus procesos de trabajo. Para lograrlo:
1. Confirme que la nueva configuración esté establecida.
1. Finalice los procesos que actualmente estén ejecutando el autovacuum.
Este enfoque garantiza que la asignación de memoria ajustada se aplique a las nuevas operaciones de autovacuum.
Para obtener resultados más inmediatos, considere la posibilidad de realizar manualmente una operación `VACUUM FREEZE` con una configuración de `maintenance_work_mem` mayor durante la sesión:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Si utiliza Amazon RDS y descubre que necesita memoria adicional para poder utilizar valores más altos para `maintenance_work_mem` o `autovacuum_work_mem`, plantéese la posibilidad de actualizar a una clase de instancia con más memoria. Esto puede proporcionarle los recursos necesarios para mejorar las operaciones de vaciado manuales y automáticas, lo que se traduce en una mejora del rendimiento general de vaciado y del de las bases de datos.
**Desactivar INDEX\$1CLEANUP**
El `VACUUM` manual de la versión 12 y posteriores de PostgreSQL permite omitir la fase de limpieza de índices, mientras que el autovacuum de emergencia en la versión 14 y posteriores de PostgreSQL lo hace automáticamente en función del parámetro [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE).
**aviso**
Omitir la limpieza de índices puede provocar una sobrecarga de índices y perjudicar el rendimiento de las consultas. Para mitigar esta situación, considere la posibilidad de volver a indexar o vaciar los índices afectados durante un período de mantenimiento.
Para obtener más información sobre cómo gestionar índices grandes, consulte la documentación en [Administración de autovacuum con índices de gran tamaño](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Vaciado de índices en paralelo**
A partir de PostgreSQL 13, los índices se pueden vaciar y limpiar en paralelo de forma predeterminada utilizando `VACUUM` de forma manual, con un proceso de trabajo de vaciado asignado a cada índice. Sin embargo, para que PostgreSQL determine si una operación de vaciado es apta para su ejecución en paralelo, se deben cumplir criterios específicos:
+ Debe haber al menos dos índices.
+ El parámetro `max_parallel_maintenance_workers` debe estar establecido al menos en 2.
+ El tamaño del índice debe superar el límite `min_parallel_index_scan_size`, que de forma predeterminada es de 512 KB.
Puede ajustar la configuración `max_parallel_maintenance_workers` en función de la cantidad de vCPU disponibles en su instancia de Amazon RDS y la cantidad de índices de la tabla para optimizar el tiempo de respuesta del vaciado.
Para obtener más información, consulte [Parallel vacuuming in Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Demasiadas tablas o bases de datos que vaciar
Como se menciona en la documentación de PostgreSQL sobre [el daemon autovacuum](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM'), este funciona mediante múltiples procesos. Esto incluye un lanzador de autovacuum persistente responsable de iniciar los procesos de trabajo de autovacuum para cada base de datos del sistema. El lanzador programa estos procesos de trabajo para que se inicien aproximadamente cada `autovacuum_naptime` segundos por cada base de datos.
Con “N” bases de datos, un nuevo proceso de trabajo comienza aproximadamente cada [`autovacuum_naptime`/N segundos]. Sin embargo, el número total de procesos de trabajo simultáneos está limitado por la configuración `autovacuum_max_workers`. Si el número de bases de datos o tablas que requieren vaciado supera este límite, la siguiente base de datos o tabla se procesará en cuanto haya un proceso de trabajo disponible.
Cuando muchas tablas o bases de datos grandes requieren un vaciado al mismo tiempo, todos los procesos de trabajo de autovacuum disponibles pueden permanecer ocupados durante un período prolongado, lo que retrasa el mantenimiento de otras tablas y bases de datos. En entornos con altas tasas de transacciones, este cuello de botella puede agravarse rápidamente y provocar posibles problemas de vaciado en su instancia de Amazon RDS.
Cuando `postgres_get_av_diag()` detecta un número elevado de tablas o bases de datos, proporciona la siguiente recomendación:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Indicaciones**
**Aumentar autovacuum\$1max\$1workers**
Para agilizar el vaciado, recomendamos ajustar el parámetro `autovacuum_max_workers` para permitir que haya más procesos de trabajo de autovacuum simultáneos. Si persisten los cuellos de botella en el rendimiento, plantéese la posibilidad de escalar verticalmente su instancia de Amazon RDS a una clase con más vCPU, lo que puede mejorar aún más las capacidades de procesamiento en paralelo.
## Se está ejecutando un vaciado intensivo (para evitar el reinicio)
La antigüedad de la base de datos (MaximumUsedTransactionIDs) en PostgreSQL solo disminuye cuando se completa correctamente un vaciado intensivo (para evitar el reinicio). Hasta que finalice este vaciado, la antigüedad seguirá aumentando en función de la velocidad de transacciones.
La función `postgres_get_av_diag()` genera el `NOTICE` siguiente cuando detecta un vaciado intensivo. Sin embargo, solo activa este resultado después de que el vaciado haya estado activo durante al menos dos minutos.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Para obtener más información sobre el vaciado intensivo, consulte [When an aggressive vacuum is already running](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Puede comprobar si se está realizando un vaciado intensivo con la siguiente consulta:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Para determinar si se trata de un vaciado intensivo (para evitar el reinicio), compruebe la columna de consulta del resultado. La expresión “para evitar el reinicio” indica que se trata de un vaciado intensivo.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Por ejemplo, supongamos que hay un bloqueador en el valor de antigüedad de transacciones de 1000 millones y una tabla que requiere un vaciado intensivo para evitar el reinicio a esa misma antigüedad de transacciones. Además, hay otro bloqueador en el valor de antigüedad de transacciones de 750 millones. Tras superar el bloqueador en el valor de antigüedad de transacciones de 1000 millones, la antigüedad no se reducirá inmediatamente a 750 millones. Seguirá siendo alta hasta que se complete la tabla que necesita el vaciado intensivo o cualquier transacción con una antigüedad superior a los 750 millones. Durante este período, la antigüedad de las transacciones de su clúster de PostgreSQL seguirá aumentando. Una vez que se complete el proceso de vaciado, la antigüedad de las transacciones se reducirá a 750 millones, pero volverá a aumentar de nuevo hasta que se finalice todo el vaciado. Este ciclo continuará mientras se mantengan estas condiciones, hasta que la antigüedad de las transacciones finalmente se reduzca hasta el nivel configurado para su instancia de Amazon RDS, especificado por `autovacuum_freeze_max_age`.
# Explicación de los mensajes de tipo NOTICE en RDS para PostgreSQL
La función `postgres_get_av_diag()` proporciona los siguientes mensajes de tipo NOTICE:
**Cuando la antigüedad aún no ha alcanzado aún el umbral de supervisión**
El umbral de supervisión para que `postgres_get_av_diag()` identifique los bloqueadores es de 500 millones de transacciones por defecto. Si `postgres_get_av_diag()` genera el siguiente mensaje NOTICE, indica que la antigüedad de la transacción aún no ha alcanzado este umbral.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**No está conectado a la base de datos que tenga la antigüedad del ID de transacción más antiguo**
La función `postgres_get_av_diag()` proporciona el resultado más preciso cuando se conecta a la base de datos con el ID de transacción más antiguo. En su caso, la base de datos con el ID de transacción más antiguo notificada por `postgres_get_av_diag()` será diferente a “my\$1database”. Si no se ha conectado a la base de datos correcta, se generará el siguiente mensaje tipo NOTICE:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Conectarse a la base de datos con la antigüedad de transacción más antigua es importante por las siguientes razones:
+ **Identificar los bloqueadores de tablas temporales:** dado que los metadatos de las tablas temporales son específicos de cada base de datos, normalmente se encuentran en la base de datos en la que se crearon. Sin embargo, si una tabla temporal resulta ser la que más bloquea y reside en la base de datos con la transacción más antigua, esta información podría resultar engañosa. La conexión a la base de datos correcta garantiza la identificación precisa del bloqueador de tablas temporal.
+ **Diagnóstico de vaciados lentos:** los metadatos del índice y la información sobre el recuento de tablas son específicos de la base de datos y son necesarios para diagnosticar los problemas de vaciado lento.
**La base de datos con la transacción más antigua se encuentra en una base de datos rdsadmin o template0**
En algunos casos, las bases de datos `rdsadmin` o `template0` pueden identificarse como la base de datos con el ID de transacción más antiguo. Si esto ocurre, `postgres_get_av_diag()` emitirá el siguiente mensaje de tipo NOTICE:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Compruebe que el bloqueador de la lista no se haya originado en ninguna de estas dos bases de datos. Si se notifica que el bloqueador está presente en `rdsadmin` o `template0` de ellas, póngase en contacto con el servicio de asistencia, ya que estas bases de datos no son accesibles para el usuario y requieren intervención.
Es muy poco probable que las bases de datos `rdsadmin` o `template0` contengan un bloqueador principal.
**Cuando ya está en curso un vaciado intensivo**
La función `postgres_get_av_diag()` está diseñada para notificar si se está ejecutando un proceso de vaciado intensivo, pero solo activa esta salida después de que el vaciado haya estado activo durante al menos 1 minuto. Este retraso intencionado ayuda a reducir las probabilidades de que se produzcan falsos positivos. Mediante esta espera, la función garantiza que solo se registren los vaciados efectivos y significativos, lo que permite una supervisión más precisa y fiable de la actividad de vaciado.
La función `postgres_get_av_diag()` genera el siguiente mensaje de tipo NOTICE cuando detecta que se están realizando uno o varios vaciados intensivos.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Como se indica en el mensaje NOTICE, siga supervisando el rendimiento del vaciado. Para obtener más información acerca del vaciado intensivo, consulte [Se está ejecutando un vaciado intensivo (para evitar el reinicio)](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Cuando el vaciado intensivo está apagado**
La función `postgres_get_av_diag()` genera el siguiente mensaje NOTICE si el autovacuum está deshabilitado en la instancia de la base de datos:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
Autovacuum es una característica fundamental de la instancia de base de datos de RDS para PostgreSQL que garantiza un funcionamiento fluido de la base de datos. Elimina automáticamente las versiones de filas antiguas, recupera espacio de almacenamiento y evita que las tablas se sobrecarguen, lo que ayuda a mantener la eficiencia de las tablas y los índices para lograr un rendimiento óptimo. Además, protege contra el reinicio de los identificadores de transacciones, lo que puede detener las transacciones en su instancia de Amazon RDS. La desactivación del autovacuum puede provocar una disminución a largo plazo del rendimiento y la estabilidad de la base de datos. Le sugerimos que lo mantenga activado todo el tiempo. Para obtener más información, consulte [Descripción de autovacuum en entornos de RDS para PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
La desactivación de autovacuum no detiene los vaciados intensivos. Seguirán produciéndose una vez que las tablas alcancen el umbral de `autovacuum_freeze_max_age`.
**El número de transacciones pendientes es críticamente bajo**
La función `postgres_get_av_diag()` genera el siguiente mensaje de tipo NOTICE cuando un vaciado previo al reinicio es inminente. Este mensaje NOTICE se emite cuando su instancia de Amazon RDS está a 100 millones de transacciones de la posibilidad de rechazar nuevas transacciones.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Es necesario realizar acciones inmediatas para evitar el tiempo de inactividad de la base de datos. Debe supervisar de cerca sus operaciones de vaciado y considerar la posibilidad de iniciar manualmente un `VACUUM FREEZE` en la base de datos afectada para evitar errores en las transacciones.