# Amazon RDS para PostgreSQL
Amazon RDS admite instancias de base de datos que ejecutan varias versiones de PostgreSQL. Para obtener una lista de las versiones disponibles, consulte [Versiones de base de datos de PostgreSQL disponibles](PostgreSQL.Concepts.General.DBVersions.md).
Puede crear instancias de base de datos e instantáneas de base de datos, restauraciones de un momento dado y backups. Las instancias de base de datos en las que se ejecuta PostgreSQL admiten implementaciones Multi-AZ, réplicas de lectura, IOPS aprovisionadas y se pueden crear dentro de una nube virtual privada (VPC). También puede utilizar la Capa de conexión segura (SSL) para conectarse a una instancia de base de datos en la que se ejecuta PostgreSQL.
Antes de crear una instancia de base de datos, debe completar los pasos que se describen en [Configuración del entorno para Amazon RDS](CHAP_SettingUp.md).
Puede usar cualquier aplicación cliente de SQL estándar para ejecutar comandos para la instancia desde su equipo cliente. Entre estas aplicaciones se incluyen pgAdmin, una conocida herramienta de administración y desarrollo de código abierto para PostgreSQL, o psql, una utilidad de línea de comando que forma parte de una instalación de PostgreSQL. Para ofrecer una experiencia de servicio administrado, Amazon RDS no proporciona acceso de host a las instancias de base de datos. También restringe el acceso a ciertos procedimientos y tablas del sistema que requieren privilegios avanzados. Amazon RDS permite el acceso a las bases de datos de una instancia de base de datos usando cualquier aplicación cliente de SQL estándar. Amazon RDS no permite el acceso directo de anfitrión a una instancia de base de datos mediante Telnet o Secure Shell (SSH).
Amazon RDS para PostgreSQL cumple muchos estándares del sector. Por ejemplo, puede utilizar las bases de datos de Amazon RDS para PostgreSQL para crear aplicaciones conformes con HIPAA y para almacenar información relacionada con la sanidad. Esto incluye el almacenamiento de información sanitaria protegida (PHI) en virtud de un Contrato de asociación empresarial (BAA) completado con AWS. Amazon RDS para PostgreSQL también cumple con los requisitos de seguridad del Programa federal de administración de riesgos y autorizaciones (FedRAMP). Amazon RDS para PostgreSQL ha recibido una autorización provisional para operar (P-ATO) de la Junta de Autorización Conjunta (JAB) de FedRAMP en la referencia FedRAMP HIGH dentro de las regiones de AWS GovCloud (US). Para obtener más información acerca de los estándares de conformidad admitidos, consulte [Conformidad en la nube de AWS](https://aws.amazon.com/compliance/).
Para importar los datos de PostgreSQL en una instancia de base de datos, siga el procedimiento que se describe en la sección [Importación de datos en PostgreSQL en Amazon RDS](PostgreSQL.Procedural.Importing.md).
**importante**
Si detecta algún problema con la instancia de la de base de datos de RDS para PostgreSQL, es posible que el agente de asistencia de AWS necesite más información sobre el estado de las bases de datos. El objetivo es asegurarnos de que la asistencia de AWS recibe la información requerida en el menor tiempo posible.
Puede utilizar PG Collector para recopilar información valiosa sobre la base de datos en un archivo HTML consolidado. Para obtener más información sobre PG Collector, cómo ejecutarlo y cómo descargar el informe HTML, consulte [PG Collector](https://github.com/awslabs/pg-collector).
Una vez finalizado correctamente, y a menos que se indique lo contrario, el script devuelve el resultado en un formato HTML legible. El script está diseñado para excluir cualquier dato o detalle de seguridad del HTML que pueda comprometer el negocio. Además, no realiza modificaciones en la base de datos ni en el entorno. Sin embargo, si encuentra alguna información en el HTML que no le resulte cómodo compartir, no dude en eliminar la información problemática antes de cargar el HTML. Cuando el HTML sea aceptable, cárguelo utilizando la sección de archivos adjuntos en los detalles del caso de su caso de asistencia.
**Topics**
+ [Tareas de administración comunes de Amazon RDS para PostgreSQL](CHAP_PostgreSQL.CommonTasks.md)
+ [Trabajo con el entorno de vista previa de bases de datos](working-with-the-database-preview-environment.md)
+ [Versiones de base de datos de PostgreSQL disponibles](PostgreSQL.Concepts.General.DBVersions.md)
+ [Descripción del proceso de lanzamiento incremental de RDS para PostgreSQL](PostgreSQL.Concepts.General.ReleaseProcess.md)
+ [Versiones de extensiones de PostgreSQL compatibles](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md)
+ [Uso de las características de PostgreSQL admitidas por Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ [Conexión a una instancia de base de datos que ejecuta el motor de base de datos de PostgreSQL](USER_ConnectToPostgreSQLInstance.md)
+ [Protección de conexiones a RDS for PostgreSQL con SSL/TLS](PostgreSQL.Concepts.General.Security.md)
+ [Uso de la autenticación Kerberos con Amazon RDS para PostgreSQL](postgresql-kerberos.md)
+ [Uso de un servidor de DNS personalizado para el acceso a la red de salida.](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
+ [Actualizaciones del motor de base de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md)
+ [Actualización de una versión del motor de instantáneas de base de datos de PostgreSQL](USER_UpgradeDBSnapshot.PostgreSQL.md)
+ [Uso de réplicas de lectura para Amazon RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md)
+ [Mejora del rendimiento de las consultas de RDS para PostgreSQL con lecturas optimizadas para Amazon RDS](USER_PostgreSQL.optimizedreads.md)
+ [Importación de datos en PostgreSQL en Amazon RDS](PostgreSQL.Procedural.Importing.md)
+ [Exportación de datos de una de Amazon S3](postgresql-s3-export.md)
+ [Invocar una función de AWS Lambda desde una instancia de base de datos de RDS for PostgreSQL](PostgreSQL-Lambda.md)
+ [Tareas comunes de los administradores de base de datos (DBA) para Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md)
+ [Ajuste con eventos de espera de RDS para PostgreSQL](PostgreSQL.Tuning.md)
+ [Ajuste de RDS para PostgreSQL con información proactiva de Amazon DevOps Guru](PostgreSQL.Tuning_proactive_insights.md)
+ [Uso de extensiones PostgreSQL con Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md)
+ [Uso de los contenedores de datos externos compatibles para Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)
+ [Uso de Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension.md)
# Tareas de administración comunes de Amazon RDS para PostgreSQL
A continuación se detallan las tareas de administración frecuentes que se realizan para una instancia de base de datos de Amazon RDS para PostgreSQL, con enlaces a la documentación relativa a cada tarea.
| Área de la tarea | Documentación relacionada |
| --- | --- |
| **Configuración de Amazon RDS para el primer uso** Debe completar algunos requisitos previos antes de crear su instancia de base de datos. Por ejemplo, las instancias de base de datos se crean de manera predeterminada con un firewall que impide el acceso. Debe crear un grupo de seguridad con las direcciones IP y la configuración de red correctas para tener acceso a la instancia de base de datos. | [Configuración del entorno para Amazon RDS](CHAP_SettingUp.md) |
| **Descripción de las instancias de base de datos de Amazon RDS** Si va a crear una instancia de base de datos con fines de producción, debe entender cómo funcionan en Amazon RDS las clases de instancia, los tipos de almacenamiento y las IOPS aprovisionadas. | [Clases de instancia de base de datos de ](Concepts.DBInstanceClass.md) [Tipos de almacenamiento de Amazon RDS](CHAP_Storage.md#Concepts.Storage) [Almacenamiento de SSD de IOPS aprovisionadas](CHAP_Storage.md#USER_PIOPS) |
| **Búsqueda de versiones disponibles de PostgreSQL** Amazon RDS admite varias versiones de PostgreSQL. | [Versiones de base de datos de PostgreSQL disponibles](PostgreSQL.Concepts.General.DBVersions.md) |
| **Configuración de la compatibilidad con alta disponibilidad y conmutación por error** Una instancia de base de datos de producción debe usar implementaciones Multi-AZ. Las implementaciones Multi-AZ proporcionan unos niveles superiores de disponibilidad, durabilidad de los datos y tolerancia a errores para las instancias de base de datos. | [Configuración y administración de una implementación multi-AZ para Amazon RDS](Concepts.MultiAZ.md) |
| **Descripción de la red de Amazon Virtual Private Cloud (VPC** Si su cuenta de AWS tiene una VPC predeterminada, la instancia de base de datos se creará automáticamente dentro de la VPC predeterminada. En algunos casos, su cuenta podría no tener una VPC predeterminada y es posible que quiera la instancia de base de datos en una VPC. En estos casos, cree los grupos de VPC y de subred antes de crear la instancia de base de datos. | [Uso de una instancia de base de datos en una VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md) |
| **Importación de datos en PostgreSQL en Amazon RDS** Puede usar varias herramientas diferentes para importar datos en su instancia de base de datos PostgreSQL en Amazon RDS. | [Importación de datos en PostgreSQL en Amazon RDS](PostgreSQL.Procedural.Importing.md) |
| **Configuración de réplicas de solo lectura (principales y en espera)** RDS for PostgreSQL admite réplicas de lectura en la misma región de AWS y en una región de AWS distinta a la de la instancia principal. | [Trabajo con réplicas de lectura de instancias de base de datos](USER_ReadRepl.md) [Uso de réplicas de lectura para Amazon RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md) [Creación de una réplica de lectura en una distinta Región de AWS](USER_ReadRepl.XRgn.md) |
| **Descripción de los grupos de seguridad** De manera predeterminada, las instancias de base de datos se crean con un firewall que impide el acceso a ellas. Para proporcionar acceso a través de ese firewall, edite las reglas de entrada para el grupo de seguridad asociado a la VPC que aloja la instancia de base de datos. | [Control de acceso con grupos de seguridad](Overview.RDSSecurityGroups.md) |
| **Configuración de grupo de parámetros y características** Para cambiar los parámetros predeterminados de la instancia de base de datos, cree un grupo de parámetros de base de datos personalizado y cambie la configuración en él. Si lo hace antes de crear la instancia de base de datos, puede elegir su grupo de parámetros de base de datos personalizado cuando crea la instancia. | [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md) |
| **Conexión a la instancia de base de datos PostgreSQL** Después de crear un grupo de seguridad y de asociarlo a una instancia de base de datos, puede conectarse a la instancia de base de datos usando cualquier aplicación cliente estándar de SQL, como `psql` o `pgAdmin`. | [Conexión a una instancia de base de datos que ejecuta el motor de base de datos de PostgreSQL](USER_ConnectToPostgreSQLInstance.md) [Uso de SSL con una instancia de base de datos PostgreSQL](PostgreSQL.Concepts.General.SSL.md) |
| **Backup y restauración de una instancia de base de datos** Puede configurar su instancia de base de datos para que realice backups automatizados o tomar snapshots manuales y restaurar después las instancias a partir de los backups o los snapshots. | [Copia de seguridad, restauración y exportación de datos](CHAP_CommonTasks.BackupRestore.md) |
| **Monitorización de la actividad y el desempeño de una instancia de base de datos** Puede monitorizar una instancia de base de datos PostgreSQL utilizando métricas, eventos y monitorización avanzada de CloudWatch Amazon RDS. | [Consulta de métricas en la consola de Amazon RDS](USER_Monitoring.md) [Consulta de eventos de Amazon RDS](USER_ListEvents.md) |
| **Actualización de la versión de la base de datos de PostgreSQL** Puede realizar actualizaciones principales y secundarias de su instancia de base de datos PostgreSQL. | [Actualizaciones del motor de base de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md) [Elección de una versión principal para una actualización de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) |
| **Trabajo con archivos de registro** Puede obtener acceso a los archivos de registro de su instancia de base de datos PostgreSQL. | [Archivos de registro de base de datos de RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md) |
| **Descripción de las prácticas recomendadas para las instancias de base de datos de PostgreSQL** Consulte algunas de las prácticas recomendadas para trabajar con PostgreSQL en Amazon RDS. | [Prácticas recomendadas para trabajar con PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL) |
A continuación, se presenta una lista de otras secciones de esta guía que pueden ser útiles para comprender y utilizar las características importantes de RDS for PostgreSQL:
+ [Descripción de los roles y permisos de PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Control del acceso de los usuarios a la base de datos de PostgreSQLControl del acceso de los usuarios a PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
+ [Comprensión de los mecanismos de registro admitidos por RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Uso de autovacuum de PostgreSQL en Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Uso de un servidor de DNS personalizado para el acceso a la red de salida.](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
# Trabajo con el entorno de vista previa de bases de datos
La comunidad de PostgreSQL lanza continuamente nuevas versiones y nuevas extensiones de PostgreSQL, incluso versiones beta. Esto ofrece a los usuarios de PostgreSQL la oportunidad de probar una nueva versión de PostgreSQL con antelación. Para obtener más información sobre el proceso de lanzamiento de la versión beta de la comunidad de PostgreSQL, consulte la [información sobre la versión beta](https://www.postgresql.org/developer/beta/) en la documentación de PostgreSQL. Del mismo modo, Amazon RDS ofrece algunas versiones beta de PostgreSQL como versiones preliminares. Esto le permite crear instancias de base de datos con la versión de vista previa y probar sus funciones en el entorno de vista previa de la base de datos.
Las instancias de base de datos de RDS para PostgreSQL en el entorno de vista previa de base de datos son funcionalmente similares a otras instancias de RDS para PostgreSQL. Sin embargo, no puede usar una versión de vista previa para la producción.
Tenga en cuenta las siguientes limitaciones importantes:
+ Todas las instancias de base de datos se eliminan 60 días después de crearlas, junto con las copias de seguridad e instantáneas.
+ Solo puede crear una instancia de base de datos en una Virtual Private Cloud (VPC) en función del servicio de Amazon VPC.
+ Solo puede utilizar almacenamiento SSD de uso general y SSD IOPS provisionadas.
+ No puede obtener ayuda de AWS Support con instancias de base de datos. En su lugar, puede publicar sus preguntas en la comunidad de preguntas y respuestas administrada de AWS, [AWSre:Post](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service).
+ No puede copiar una instantánea de una instancia de base de datos en un entorno de producción.
Las siguientes opciones son compatibles con la vista previa:
+ Puede crear instancias de base de datos únicamente con los tipos de instancia M6i, R6i, M6g, M5, T3, R6g y R5. Para obtener más información sobre las clases de instancias de RDS, consulte [Clases de instancia de base de datos de ](Concepts.DBInstanceClass.md).
+ Puede utilizar implementaciones single-AZ y multi-AZ.
+ Puede utilizar las funciones estándar de volcado y carga de PostgreSQL para exportar bases de datos desde o importar bases de datos hacia el entorno de la vista previa de base de datos.
**Topics**
+ [Características no compatibles en el entorno de vista previa de bases de datos](#preview-environment-exclusions)
+ [Versión 17 de PostgreSQL en el entorno de vista previa de bases de datos](#PostgreSQL.Concepts.General.version17)
+ [Creación de una nueva instancia de base de datos en el entorno de vista previa de bases de datos](create-db-instance-in-preview-environment.md)
## Características no compatibles en el entorno de vista previa de bases de datos
Las siguientes características no están disponibles en el entorno de vista previa de bases de datos:
+ Copia de instantáneas entre regiones
+ Réplicas de lectura entre regiones
## Versión 17 de PostgreSQL en el entorno de vista previa de bases de datos
**nota**
Esta es la documentación preliminar de la versión 17 de Amazon RDS PostgreSQL. Está sujeta a cambios.
La versión 17.0 de PostgreSQL ya está disponible en el entorno de vista previa de bases de datos de Amazon RDS. La versión 17.0 de PostgreSQL incluye varias mejoras que se describen en la siguiente documentación de PostgreSQL, [PostgreSQL 17 Released\$1](https://www.postgresql.org/docs/17/release-17.html)
Para obtener información acerca del entorno de vista previa de base de datos, consulte [Trabajo con el entorno de vista previa de bases de datos](#working-with-the-database-preview-environment). Para acceder al entorno de vista previa desde la consola, seleccione [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/).
# Creación de una nueva instancia de base de datos en el entorno de vista previa de bases de datos
Utilice el procedimiento siguiente para crear una instancia de base de datos en el entorno de vista previa.
**Para crear una instancia de base de datos en el entorno de vista previa de bases de datos**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Elija **Panel** en el panel de navegación.
1. En la página Dashboard (Panel), busque la sección **Database Preview Environment** (Entorno de vista previa de base de datos), tal como se muestra en la siguiente imagen.
![\[Sección de entorno de vista previa con el enlace que se muestra en la consola de RDS o el panel.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
Puede navegar directamente a [Database Preview Environment](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#). Antes de continuar, debe reconocer y aceptar las limitaciones.
![\[Diálogo de limitaciones del entorno de vista previa\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. Para crear la instancia de base de datos de RDS para PostgreSQL, siga el mismo proceso que para crear cualquier instancia de base de datos de Amazon RDS. Para obtener más información, consulte el procedimiento [Consola](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) en [Creación de una instancia de base de datos](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
Para crear una instancia en el entorno de vista previa de base de datos mediante la API de RDS o la AWS CLI, utilice el siguiente punto de conexión.
```
rds-preview.us-east-2.amazonaws.com
```
# Versiones de base de datos de PostgreSQL disponibles
Amazon RDS admite instancias de base de datos que ejecutan varias ediciones de PostgreSQL. Puede especificar cualquier versión disponible actualmente de PostgreSQL cuando crea una nueva instancia de base de datos. Puede especificar la versión principal (como PostgreSQL 14) y cualquier versión secundaria disponible para la versión principal especificada. Si no se especifica ninguna versión, Amazon RDS cambia de forma predeterminada a una versión disponible, normalmente la más reciente. Si se especifica una versión principal pero no una versión secundaria, Amazon RDS usa de manera predeterminada una versión reciente de la versión principal especificada.
Para ver una lista de las versiones disponibles, así como de las versiones predeterminadas para instancias de bases de datos recién creadas, utilice el comando [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) de la AWS CLI. Por ejemplo, para mostrar la versión predeterminada del motor PostgreSQL, utilice el siguiente comando:
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
Para obtener más información sobre las versiones de PostgreSQL compatibles con Amazon RDS, consulte las [https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html). También puede ver información sobre las fechas de soporte de las versiones principales del motor ejecutando el comando [describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) de la AWS CLI o mediante la operación de la API de RDS [DescribeDBMajorEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html).
Si no está preparado para realizar una actualización manual a una nueva versión principal del motor antes de la fecha de finalización del soporte estándar de RDS, Amazon RDS inscribirá automáticamente las bases de datos en el Soporte extendido de Amazon RDS después de la fecha de finalización del soporte estándar de RDS. Luego, puede seguir ejecutando RDS para PostgreSQL (versión 11 y posteriores). Para obtener más información, consulte [Soporte extendido de Amazon RDS con Amazon RDS](extended-support.md) y [Precios de Amazon RDS](https://aws.amazon.com/rds/pricing/).
## Versiones obsoleta para Amazon RDS for PostgreSQL
Tenga en cuenta las siguientes versiones obsoletas:
+ RDS para PostgreSQL 10 quedó obsoleto en febrero de 2023.
+ RDS para PostgreSQL 9.6 quedó obsoleto en marzo de 2022.
+ RDS para PostgreSQL 9.5 quedó obsoleto en marzo de 2021.
Para obtener más información sobre la política de obsolescencia de RDS for PostgreSQL, consulte [Preguntas frecuentes de Amazon RDS](https://aws.amazon.com/rds/faqs/) Para obtener más información sobre las versiones de PostgreSQL, consulte [Política de control de versiones](https://www.postgresql.org/support/versioning/) en la documentación de PostgreSQL.
# Descripción del proceso de lanzamiento incremental de RDS para PostgreSQL
RDS para PostgreSQL ofrece correcciones de seguridad, mejoras de rendimiento y nuevas características mediante versiones incrementales, al tiempo que mantiene la compatibilidad con las versiones menores. Estas versiones se etiquetan como R1, R2, R3, etc.
**Convención de nomenclatura de las versiones de lanzamiento**
+ R1 es la versión inicial de una versión menor. Ocasionalmente, incluye nuevas características, extensiones o actualizaciones de las extensiones existentes.
+ Las versiones de lanzamiento posteriores (R2, R3 y posteriores) incluyen:
+ Actualizaciones de seguridad
+ Mejoras en el rendimiento
+ Correcciones de errores
+ Actualizaciones de extensiones
## Ventajas del proceso de lanzamiento incremental de RDS para PostgreSQL
El proceso de lanzamiento incremental proporciona las siguientes ventajas:
+ Adopción rápida de las nuevas versiones de la comunidad de PostgreSQL, gestionando por separado las mejoras específicas de RDS a través de versiones posteriores. Esto agiliza el proceso de lanzamiento y garantiza una entrega más rápida de las actualizaciones críticas.
+ Acceso a correcciones de errores, nuevas características, actualizaciones de seguridad y actualizaciones de extensiones mientras se mantiene la compatibilidad con la versión secundaria de PostgreSQL.
## Administración de actualizaciones de versiones
Amazon RDS le notifica sobre las nuevas versiones incrementales mediante acciones de mantenimiento pendientes en la Consola de administración de AWS. Puede actualizar la base de datos mediante uno de estos métodos:
+ Habilite las actualizaciones automáticas durante las ventanas de mantenimiento programadas.
+ Aplique las actualizaciones manualmente mediante las acciones de mantenimiento pendientes.
+ Utilice implementaciones azul/verde con replicación física para minimizar el tiempo de inactividad. Para obtener más información, consulte [Las implementaciones azul/verde admiten la actualización de versiones secundarias de RDS para PostgreSQL](https://aws.amazon.com/about-aws/whats-new/2024/11/rds-blue-green-deployments-upgrade-rds-postgresql/).
Antes de actualizar la base de datos, tenga en cuenta los siguientes puntos claves:
+ Es necesario reiniciar la base de datos para realizar actualizaciones a menos que utilice implementaciones azul/verde con replicación física.
+ Algunas versiones incrementales son obligatorias, especialmente las que incluyen correcciones de seguridad.
Para obtener más información sobre la actualización de la instancia de base de datos de Amazon RDS, consulte [Extensiones de confianza de PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted) y [apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html).
# Versiones de extensiones de PostgreSQL compatibles
RDS for PostgreSQL admite muchas extensiones de PostgreSQL. La comunidad de PostgreSQL a veces se refiere a estos como módulos. Las extensiones amplían la funcionalidad proporcionada por el motor PostgreSQL. Puede encontrar una lista de las extensiones admitidas por Amazon RDS en el grupo de parámetros de base de datos predeterminado de esa versión de PostgreSQL. También puede ver la lista de extensiones actuales que usan `psql` mostrando el parámetro `rds.extensions` como en el siguiente ejemplo.
```
SHOW rds.extensions;
```
**nota**
Los parámetros añadidos en una versión secundaria pueden mostrarse de manera incorrecta cuando se utiliza el parámetro `rds.extensions` en `psql`.
A partir de RDS para PostgreSQL 13, ciertas extensiones pueden instalarlas usuarios de bases de datos que no sean `rds_superuser`. Esto se conoce como *extensiones de confianza*. Para obtener más información, consulte [Extensiones de confianza de PostgreSQL](#PostgreSQL.Concepts.General.Extensions.Trusted).
Ciertas versiones de RDS para PostgreSQL admiten el parámetro `rds.allowed_extensions`. Este parámetro permite que un `rds_superuser` limite las extensiones que se pueden instalar en la instancia de base de datos de RDS para PostgreSQL. Para obtener más información, consulte [Restringir la instalación de extensiones de PostgreSQL](#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Para obtener una lista de las extensiones y versiones de PostgreSQL compatibles con cada versión disponible de RDS para PostgreSQL, consulte [Extensiones de PostgreSQL admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) en las *Notas de la versión de Amazon RDS para PostgreSQL*.
## Restringir la instalación de extensiones de PostgreSQL
Puede restringir qué extensiones se pueden instalar en una instancia de base de datos de PostgreSQL. De forma predeterminada, este parámetro no está configurado, por lo que se puede agregar cualquier extensión compatible si el usuario tiene permisos para hacerlo. Para ello, establezca el parámetro `rds.allowed_extensions` en una cadena de nombres de extensión separados por comas. Al agregar una lista de extensiones a este parámetro, identifica explícitamente las extensiones que puede utilizar su instancia de base de datos de RDS para PostgreSQL. Solo estas extensiones se pueden instalar en la instancia de base de datos de PostgreSQL.
La cadena predeterminada para el parámetro `rds.allowed_extensions` es '\$1', lo que significa que se puede instalar cualquier extensión disponible para la versión del motor. Cambiar el parámetro `rds.allowed_extensions` no requiere un reinicio de la base de datos porque es un parámetro dinámico.
El motor de instancia de base de datos de PostgreSQL debe ser una de las siguientes versiones para que pueda utilizar el parámetro:`rds.allowed_extensions`
+ Todas las versiones de PostgreSQL 16
+ PostgreSQL 15 y todas las versiones posteriores
+ PostgreSQL 14 y todas las versiones posteriores
+ PostgreSQL 13.3 y versiones secundarias posteriores
+ PostgreSQL 12.7 y versiones secundarias posteriores
Para ver qué instalaciones de extensión están permitidas, utilice el siguiente comando psql.
```
postgres=> SHOW rds.allowed_extensions;
rds.allowed_extensions
------------------------
*
```
Si se instaló una extensión antes de dejarla fuera de la lista en el parámetro `rds.allowed_extensions`, la extensión todavía se puede utilizar normalmente y comandos como `ALTER EXTENSION` y `DROP EXTENSION` continuarán funcionando. Sin embargo, una vez restringida una extensión, los comandos `CREATE EXTENSION` de la extensión restringida fallarán.
La instalación de dependencias de extensión con `CREATE EXTENSION CASCADE` también están restringidas. La extensión y sus dependencias deben especificarse en `rds.allowed_extensions`. Si falla una instalación de dependencia de extensión, se producirá un error en toda la instrucción `CREATE EXTENSION CASCADE`.
Si no se incluye una extensión con el parámetro `rds.allowed_extensions`, verá un error como el siguiente si intenta instalarla.
```
ERROR: permission denied to create extension "extension-name"
HINT: This extension is not specified in "rds.allowed_extensions".
```
## Extensiones de confianza de PostgreSQL
Para instalar la mayoría de las extensiones de PostgreSQL requiere privilegios de `rds_superuser`. PostgreSQL 13 presentó extensiones de confianza, que reducen la necesidad de conceder privilegios `rds_superuser` a los usuarios normales. Con esta característica, los usuarios pueden instalar muchas extensiones si tienen el privilegio de `CREATE` en la base de datos actual en lugar de requerir el rol de `rds_superuser`. Para obtener más información, consulte el comando de SQL [CREATE EXTENSION](https://www.postgresql.org/docs/current/sql-createextension.html) en la documentación de PostgreSQL.
A continuación se enumeran las extensiones que puede instalar un usuario que tiene el privilegio de `CREATE` en la base de datos actual y no requieren el rol de:`rds_superuser`
+ bool\$1plperl
+ [btree\$1gin](http://www.postgresql.org/docs/current/btree-gin.html)
+ [btree\$1gist](http://www.postgresql.org/docs/current/btree-gist.html)
+ [citext ](http://www.postgresql.org/docs/current/citext.html)
+ [cube ](http://www.postgresql.org/docs/current/cube.html)
+ [ dict\$1int ](http://www.postgresql.org/docs/current/dict-int.html)
+ [fuzzystrmatch](http://www.postgresql.org/docs/current/fuzzystrmatch.html)
+ [hstore](http://www.postgresql.org/docs/current/hstore.html)
+ [ intarray](http://www.postgresql.org/docs/current/intarray.html)
+ [isn](http://www.postgresql.org/docs/current/isn.html)
+ jsonb\$1plperl
+ [ltree ](http://www.postgresql.org/docs/current/ltree.html)
+ [pg\$1trgm](http://www.postgresql.org/docs/current/pgtrgm.html)
+ [pgcrypto](http://www.postgresql.org/docs/current/pgcrypto.html)
+ [plperl](https://www.postgresql.org/docs/current/plperl.html)
+ [plpgsql](https://www.postgresql.org/docs/current/plpgsql.html)
+ [pltcl](https://www.postgresql.org/docs/current/pltcl-overview.html)
+ [tablefunc](http://www.postgresql.org/docs/current/tablefunc.html)
+ [tsm\$1system\$1rows](https://www.postgresql.org/docs/current/tsm-system-rows.html)
+ [tsm\$1system\$1time](https://www.postgresql.org/docs/current/tsm-system-time.html)
+ [unaccent](http://www.postgresql.org/docs/current/unaccent.html)
+ [uuid-ossp](http://www.postgresql.org/docs/current/uuid-ossp.html)
Para obtener una lista de las extensiones y versiones de PostgreSQL compatibles con cada versión disponible de RDS para PostgreSQL, consulte [Extensiones de PostgreSQL admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) en las *Notas de la versión de Amazon RDS para PostgreSQL*.
# Uso de las características de PostgreSQL admitidas por Amazon RDS para PostgreSQL
Amazon RDS para PostgreSQL es compatible con muchas de las características más comunes de PostgreSQL. Por ejemplo, PostgreSQL tiene una característica de autovacuum que realiza un mantenimiento rutinario de la base de datos. La característica autovacuum está activa de forma predeterminada. Aunque puede desactivar esta característica, le recomendamos encarecidamente que la mantenga activada. Comprender esta característica y lo que puede hacer para asegurarse de que funciona como debería es una tarea básica de cualquier DBA. Para obtener más información sobre el autovacuum, consulte [Uso de autovacuum de PostgreSQL en Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md). Para obtener más información sobre otras tareas comunes de DBA, consulte ., [Tareas comunes de los administradores de base de datos (DBA) para Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md).
RDS for PostgreSQL también admite extensiones que agregan funcionalidades importantes a la instancia de base de datos. Por ejemplo, puede utilizar la extensión PostGIS para trabajar con datos espaciales o utilizar la extensión pg\$1cron para programar el mantenimiento desde la instancia. Para obtener más información sobre las extensiones de PostgreSQL, consulte [Uso de extensiones PostgreSQL con Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md).
Los contenedores de datos externos son un tipo específico de extensión diseñada para permitir que la instancia de base de datos de RDS for PostgreSQL funcione con otros tipos de datos o bases de datos comerciales. Para obtener más información sobre los contenedores de datos externos admitidos por RDS for PostgreSQL, consulte [Uso de los contenedores de datos externos compatibles para Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
A continuación, encontrará información sobre algunas otras características admitidas por RDS para PostgreSQL.
**Topics**
+ [Tipos de datos personalizados y enumeraciones con RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md)
+ [Desencadenadores de eventos para RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md)
+ [Páginas enormes para RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md)
+ [Replicación lógica para Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)
+ [Configuración de la autenticación de IAM para conexiones de replicación lógica](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md)
+ [Disco RAM para stats\$1temp\$1directory](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md)
+ [Espacios de tablas para RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md)
+ [Intercalaciones de RDS para PostgreSQL para EBCDIC y otras migraciones de mainframe](PostgreSQL.Collations.mainframe.migration.md)
+ [Administración de ranuras lógicas de RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md)
# Tipos de datos personalizados y enumeraciones con RDS for PostgreSQL
PostgreSQL admite la creación de tipos de datos personalizados y el trabajo con enumeraciones. Para obtener más información sobre cómo crear y trabajar con enumeraciones y otros tipos de datos, consulte [Tipos enumerados](https://www.postgresql.org/docs/14/datatype-enum.html) en la documentación de PostgreSQL.
El siguiente es un ejemplo de creación de un tipo como enumeración seguida de la inserción de valores en una tabla.
```
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors
--------
red
orange
(2 rows)
postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=> SELECT * from t1;
colors
---------
crimson
orange
(2 rows)
```
# Desencadenadores de eventos para RDS for PostgreSQL
Todas las versiones actuales de PostgreSQL admiten desencadenadores de eventos, al igual que todas las versiones disponibles de RDS for PostgreSQL. Puede utilizar la cuenta de usuario principal (`postgres`, predeterminada) para crear, modificar, renombrar y eliminar desencadenadores de eventos. Los disparadores de eventos están en el nivel de la instancia de base de datos, de modo que se pueden aplicar a todas las bases de datos de una instancia.
Por ejemplo, el siguiente código crea un desencadenador de evento que imprime el usuario actual al final de cada comando de lenguaje de definición de datos (DDL).
```
CREATE OR REPLACE FUNCTION raise_notice_func()
RETURNS event_trigger
LANGUAGE plpgsql AS
$$
BEGIN
RAISE NOTICE 'In trigger function: %', current_user;
END;
$$;
CREATE EVENT TRIGGER event_trigger_1
ON ddl_command_end
EXECUTE PROCEDURE raise_notice_func();
```
Para obtener más información acerca de los desencadenadores de eventos de PostgreSQL, consulte [Desencadenadores de eventos](https://www.postgresql.org/docs/current/static/event-triggers.html) en la documentación de PostgreSQL.
Hay varias limitaciones que afectan al uso de los disparadores de eventos de PostgreSQL en Amazon RDS. Estos incluyen los siguientes:
+ No puede crear desencadenadores de eventos en réplicas de lectura. Puede, no obstante, crear desencadenadores de eventos en un origen de réplica de lectura. Los disparadores de eventos se copian a continuación en la réplica de lectura. Los desencadenadores de eventos en la réplica de lectura no se activan en la réplica de lectura cuando los cambios se envían desde el origen. No obstante, si se promueve la réplica de lectura, los disparadores de eventos existentes se activarán cuando se produzcan operaciones en la base de datos.
+ Para realizar una actualización de versión principal en una instancia de base de datos de PostgreSQL que use desencadenadores de eventos, debe eliminar los desencadenadores de eventos antes de actualizar la instancia.
# Páginas enormes para RDS for PostgreSQL
Las *páginas enormes* son una característica de administración de la memoria que reduce la sobrecarga cuando una instancia de base de datos trabaja con grandes fragmentos contiguos de memoria, como la utilizada por los búferes compartidos. Esta característica de PostgreSQL es compatible con todas las versiones de RDS for PostgreSQL disponibles actualmente. Las páginas de gran tamaño se asignan a la aplicación con llamadas a la memoria compartida de `mmap` o `SYSV`. RDS for PostgreSQL admite tamaños de página de 4 KB y 2 MB.
Puede activar o desactivar las páginas enormes cambiando el valor del parámetro `huge_pages`. La característica está habilitada de forma predeterminada para todas las clases de instancias de base de datos que no sean de la clase de instancia de base de datos micro, pequeña y mediana.
RDS for PostgreSQL utiliza páginas enormes en función de la memoria compartida disponible. Si la instancia de base de datos no puede usar páginas de gran tamaño a causa de las restricciones de la memoria compartida, Amazon RDS impide que la instancia de base de datos se inicie. En este caso, Amazon RDS define el estado de la instancia de base de datos en un estado de los parámetros no compatible. En este caso, puede establecer el parámetro `huge_pages` en `off` para permitir que Amazon RDS inicie la instancia de base de datos.
El parámetro `shared_buffers` es esencial para configurar el grupo de memoria compartida que se requiere para usar las páginas enormes. El valor predeterminado del parámetro `shared_buffers` utiliza una macro de parámetros de base de datos. Esta macro define un porcentaje del total de las páginas de 8 KB disponibles para la memoria de la instancia de base de datos. Cuando utiliza páginas de gran tamaño, esas páginas se asignan con las páginas de gran tamaño. Amazon RDS cambia una instancia de base de datos a un estado de parámetros incompatible si los parámetros de memoria compartida se han definido de un modo que requiere más del 90 % de la memoria de la instancia de base de datos.
Para obtener más información sobre la administración de memoria de PostgreSQL, consulte [Consumo de recursos](https://www.postgresql.org/docs/current/static/runtime-config-resource.html) en la documentación de PostgreSQL.
# Replicación lógica para Amazon RDS para PostgreSQL
A partir de la versión 10.4, RDS para PostgreSQL admite la sintaxis SQL de publicación y suscripción introducida en PostgreSQL 10. Para obtener más información, consulte [Replicación lógica](https://www.postgresql.org/docs/current/logical-replication.html) en la documentación de PostgreSQL.
**nota**
Además de la función de replicación lógica nativa de PostgreSQL introducida en PostgreSQL 10, RDS para PostgreSQL también admite la extensión `pglogical`. Para obtener más información, consulte [Uso de pglogical para sincronizar datos entre instancias](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
A continuación encontrará información sobre la configuración de la replicación lógica para una instancia de base de datos de RDS for PostgreSQL.
**Topics**
+ [Comprensión de la replicación lógica y la descodificación lógica](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding)
+ [Trabajo con ranuras de replicación lógica](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots)
+ [Replicación de datos de nivel de tabla mediante replicación lógica](#PostgreSQL.Concepts.LogicalReplication.Tables)
## Comprensión de la replicación lógica y la descodificación lógica
RDS for PostgreSQL admite el streaming de los cambios del registro de escritura anticipada (WAL) mediante las ranuras de replicación lógica de PostgreSQL. También admite el uso de decodificación lógica. Puede configurar ranuras de replicación lógica en su instancia y transmitir los cambios de la base de datos a través de estas ranuras a un cliente como `pg_recvlogical`. Las ranuras de replicación lógica se crean a nivel de la base de datos y admiten conexiones de replicación a una única base de datos.
Los clientes más comunes para la replicación lógica de PostgreSQL son AWS Database Migration Service o un host administrado personalizado en una instancia de Amazon EC2. La ranura de replicación lógica no tiene información sobre el receptor de la transmisión. Además, no existe el requisito de que el destino sea una base de datos de réplica. Si configura una ranura de replicación lógica y no lee desde la ranura, los datos podrían escribirse y rellenarse rápidamente en el almacenamiento de la instancia de base de datos.
La replicación y descodificación lógicas de PostgreSQL en Amazon RDS se activan con un parámetro, un tipo de conexión de replicación y un rol de seguridad. El cliente para la descodificación lógica puede ser cualquier cliente que sea capaz de establecer una conexión de replicación con una base de datos en una instancia de base de datos PostgreSQL.
**Para activar la descodificación lógica para una instancia de base de datos de RDS for PostgreSQL**
1. Asegúrese de que la cuenta de usuario que está utilizando tenga los siguientes roles:
+ El rol `rds_superuser` para poder activar la replicación lógica
+ El rol `rds_replication` para conceder permisos para administrar ranuras lógicas y para transmitir datos mediante ranuras lógicas
1. Establezca el parámetro estático `rds.logical_replication` en 1. Como parte de la aplicación de este parámetro, también defina los parámetros `wal_level`, `max_wal_senders`, `max_replication_slots` y `max_connections`. Estos cambios de parámetro pueden incrementar la generación de WAL, por lo que el parámetro `rds.logical_replication` se debe configurar solo cuando se utilicen ranuras lógicas.
1. Reinicie la instancia de base de datos para que el parámetro `rds.logical_replication` estático tenga efecto.
1. Cree una ranura de replicación lógica como se indica en la siguiente sección. Este proceso necesita que especifique un complemento de descodificación. Actualmente, RDS for PostgreSQL admite los complementos de salida test\$1decoding y wal2json que se incluyen con PostgreSQL.
Para obtener más información acerca de la descodificación lógica de PostgreSQL, consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html).
## Trabajo con ranuras de replicación lógica
Puede usar comandos de SQL para trabajar con las ranuras lógicas. Por ejemplo, el siguiente comando crea una ranura lógica denominada `test_slot` usando el complemento de salida predeterminado de PostgreSQL `test_decoding`.
```
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)
```
Para ver las ranuras lógicas, use el siguiente comando.
```
SELECT * FROM pg_replication_slots;
```
Para eliminar una ranura lógica, use el siguiente comando.
```
SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)
```
Para ver más ejemplos del trabajo con ranuras de replicación lógica, consulte [ Logical Decoding Examples](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html) en la documentación de PostgreSQL.
Luego de crear la ranura de replicación lógica, se puede iniciar el streaming. El siguiente ejemplo muestra cómo se controla la decodificación lógica a través del protocolo de replicación del streaming. Este ejemplo utiliza el programa pg\$1recvlogical, que se incluye en la distribución de PostgreSQL. Esto requiere que la autenticación del cliente se configure para permitir las conexiones de replicación.
```
pg_recvlogical -d postgres --slot test_slot -U postgres
--host -instance-name.111122223333.aws-region.rds.amazonaws.com
-f - --start
```
Para ver el contenido de la vista `pg_replication_origin_status`, consulte la función `pg_show_replication_origin_status`.
```
SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)
```
## Replicación de datos de nivel de tabla mediante replicación lógica
Puede utilizar la replicación lógica para replicar los datos de las tablas de origen a las tablas de destino en RDS para PostgreSQL. La replicación lógica primero realiza una carga inicial de los datos existentes de las tablas de origen y, a continuación, continúa replicando los cambios en curso.
1.
**Creación de las tablas de origen**
Conéctese a la base de datos de origen en la instancia de base de datos de RDS para PostgreSQL:
```
source=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
1.
**Inserción de datos en las tablas de origen**
```
source=> INSERT INTO testtab VALUES (generate_series(1,1000));
INSERT 0 1000
```
1.
**Creación de una publicación para las tablas de origen**
+ Cree una publicación para las tablas de origen:
```
source=> CREATE PUBLICATION testpub FOR TABLE testtab;
CREATE PUBLICATION
```
+ Utilice una consulta SELECT para verificar los detalles de la publicación que se creó:
```
source=> SELECT * FROM pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
--------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
115069 | testpub | 16395 | f | t | t | t | t | f
(1 row)
```
+ Verifique que las tablas de origen se hayan agregado a la publicación:
```
source=> SELECT * FROM pg_publication_tables;
pubname | schemaname | tablename
---------+------------+-----------
testpub | public | testtab
(1 rows)
```
+ Para replicar todas las tablas de una base de datos, utilice:
```
CREATE PUBLICATION testpub FOR ALL TABLES;
```
+ Si la publicación ya está creada para una tabla individual y necesita agregar una tabla nueva, puede ejecutar la siguiente consulta para agregar cualquier tabla nueva a la publicación existente:
```
ALTER PUBLICATION add table ;
```
1.
**Conéctese a la base de datos de destino y cree tablas de destino**
+ Conéctese a la base de datos de destino en la instancia de base de datos de destino. Cree las tablas de destino con los mismos nombres que las tablas de origen:
```
target=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
+ Asegúrese de que no haya datos presentes en las tablas de destino ejecutando una consulta SELECT en las tablas de destino:
```
target=> SELECT count(*) FROM testtab;
count
-------
0
(1 row)
```
1.
**Cree y verifique la suscripción en la base de datos de destino**
+ Cree la suscripción en la base de datos de destino:
```
target=> CREATE SUBSCRIPTION testsub
CONNECTION 'host= port=5432 dbname= user= password='
PUBLICATION testpub;
NOTICE: Created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
+ Utilice una consulta SELECT para verificar que la suscripción esté habilitada:
```
target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16434 | testsub | t | testsub | {testpub}
(1 row)
```
+ Cuando se crea la suscripción, se cargan todos los datos de las tablas de origen en las tablas de destino. Ejecute una consulta SELECT en las tablas de destino para verificar que se cargan los datos iniciales:
```
target=> SELECT count(*) FROM testtab;
count
-------
1000
(1 row)
```
1.
**Verificación de la ranura de replicación en la base de datos de origen**
La creación de una suscripción en la base de datos de destino crea una ranura de replicación en la base de datos de origen. Verifique los detalles de la ranura de replicación ejecutando la siguiente consulta SELECT en la base de datos de origen:
```
source=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size
----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------
testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved |
(1 row)
```
1.
**prueba de replicación**
+ Compruebe si los cambios en los datos de las tablas de origen se están replicando en las tablas de destino insertando filas en las tablas de origen:
```
source=> INSERT INTO testtab VALUES(generate_series(1001,2000));
INSERT 0 1000
source=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
+ Verifique el número de filas en las tablas de destino para confirmar que se están replicando las nuevas inserciones:
```
target=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
1.
**Actualización de la suscripción después de agregar tablas**
+ Cuando se agregan nuevas tablas a una publicación existente, es obligatorio actualizar la suscripción para que los cambios surtan efecto:
```
ALTER SUBSCRIPTION REFRESH PUBLICATION;
```
+ Este comando obtiene la información de las tablas que faltan del publicador e inicia la replicación de las tablas que se agregaron a las publicaciones suscritas desde que se creó la suscripción o se actualizó por última vez.
# Configuración de la autenticación de IAM para conexiones de replicación lógica
A partir de las versiones 11 y superiores de RDS para PostgreSQL, puede usar la autenticación AWS Identity and Access Management (IAM) para las conexiones de replicación. Esta característica mejora la seguridad al permitirle administrar el acceso a la base de datos mediante roles de IAM en lugar de contraseñas. Funciona por clúster y detalle de la instancia y sigue el mismo modelo de seguridad que la autenticación de IAM estándar.
La autenticación de IAM para conexiones de replicación es una característica opcional. Para habilitarla, establezca el parámetro `rds.iam_auth_for_replication` en 1 en el grupo de parámetros del clúster de la base de datos o de base de datos. Como se trata de un parámetro dinámico, el clúster o instancia de base de datos no necesita reiniciarse, lo que le permite aprovechar la autenticación de IAM con las cargas de trabajo existentes sin tiempo de inactividad. Antes de habilitar esta característica, asegúrese de que cumple los requisitos previos mostrados a continuación.
**Topics**
+ [Requisitos previos](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites)
+ [Habilitación de la autenticación de IAM para las conexiones de replicación](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling)
+ [Desactivación de la autenticación de IAM para las conexiones de replicación](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling)
+ [Limitaciones y consideraciones](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations)
## Requisitos previos
Para utilizar la autenticación de IAM para conexiones de replicación, debe cumplir todos los siguientes requisitos:
+ Las instancia de base de datos de RDS para PostgreSQL debe ser de versión 11 o posterior.
+ En su instancia de base de datos de RDS para PostgreSQL del publicador:
+ Habilite la autenticación de bases de datos de IAM. Para obtener más información, consulte [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Habilite la replicación lógica estableciendo el parámetro `rds.logical_replication` en 1.
En la replicación lógica, el publicador es la base de datos de RDS para PostgreSQL de origen que envía los datos a los clústeres de suscriptores. Para obtener más información, consulte [Replicación lógica para Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
**nota**
La autenticación de IAM y la replicación lógica deben estar habilitadas en la instancia de base de datos de RDS para Aurora PostgreSQL del publicador. Si ninguna de las dos está habilitada, no podrá utilizar la autenticación de IAM para conexiones de replicación.
## Habilitación de la autenticación de IAM para las conexiones de replicación
Realice los siguientes pasos antes de habilitar la autenticación de IAM para la conexión de replicación.
**Habilitación de la autenticación de IAM para las conexiones de replicación**
1. Compruebe que el clúster o instancia de base de datos de RDS para PostgreSQL cumpla todos los requisitos previos para la autenticación de IAM con conexiones de replicación. Para obtener más información, consulte [Requisitos previos](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites).
1. Configure el parámetro `rds.iam_auth_for_replication` en función de la configuración de RDS para PostgreSQL:
+ Para instancias de base de datos de RDS para PostgreSQL: modifique su grupo de parámetros de base de datos.
+ Para clústeres multi-AZ: modifique el grupo de parámetros de clúster de base de datos.
Establezca `rds.iam_auth_for_replication` en 1. Este es un parámetro dinámico que se aplica de forma inmediata sin necesidad de reiniciar.
**nota**
Los clústeres de multi-AZ utilizan solo grupos de parámetros de clúster de base de datos. Los grupos de parámetros de instancias individuales no se pueden modificar en los clústeres de multi-AZ.
1. Conéctese a la base de datos y conceda los roles necesarios al usuario de replicación:
Los siguientes comandos SQL otorgan los roles necesarios para habilitar la autenticación de IAM para las conexiones de replicación:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Tras completar estos pasos, el usuario especificado debe usar la autenticación de IAM para las conexiones de replicación.
**importante**
Al habilitar la característica, los usuarios con los roles `rds_iam` y `rds_replication` deben usar la autenticación de IAM para las conexiones de replicación. Esto se aplica si los roles se asignan directamente al usuario o si se heredan a través de otros roles.
## Desactivación de la autenticación de IAM para las conexiones de replicación
Puede desactivar la autenticación de IAM para conexiones de replicación mediante cualquiera de los siguientes métodos:
+ Defina el parámetro `rds.iam_auth_for_replication` en 0 en el grupo de parámetros de base de datos para las instancias de base de datos o en el grupo de parámetros del clúster de base de datos para los clústeres multi-AZ.
+ Otra opción, puede desactivar cualquiera de estas características en el clúster o la instancia de base de datos de RDS para PostgreSQL:
+ Desactivación de la replicación lógica estableciendo el parámetro `rds.logical_replication` en 0
+ Desactivación de la autenticación de IAM
Al desactivar la característica, las conexiones de replicación pueden usar contraseñas de bases de datos para la autenticación.
**nota**
Las conexiones de replicación para los usuarios sin el rol `rds_iam` pueden usar la autenticación por contraseña incluso cuando la característica está habilitada.
## Limitaciones y consideraciones
Tenga en cuenta las limitaciones y consideraciones siguientes al usar la autenticación de IAM para las conexiones de replicación lógicas:
+ Esta característica solo está disponible para las versiones 11 y superiores de RDS para PostgreSQL.
+ El publicador debe admitir la autenticación de IAM para las conexiones de replicación.
+ De forma predeterminada, el token de autenticación de IAM caduca a los 15 minutos. Es posible que tenga que actualizar las conexiones de replicación de larga duración antes de que caduque el token.
# Disco RAM para stats\$1temp\$1directory
Puede utilizar el parámetro `rds.pg_stat_ramdisk_size` de RDS for PostgreSQL para especificar la memoria del sistema asignada a un disco RAM para almacenar el `stats_temp_directory` de PostgreSQL. El parámetro del disco RAM solo está disponible en RDS para la versión 14 y anteriores de PostgreSQL.
Para algunas cargas de trabajo, configurar este parámetro puede mejorar el rendimiento y reducir los requisitos de E/S. Para obtener más información acerca de `stats_temp_directory`, consulte la [ documentación de PostgreSQL.](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY).
Para configurar un disco RAM para `stats_temp_directory`, configure el parámetro `rds.pg_stat_ramdisk_size` en un valor literal entero en el grupo de parámetros utilizado por la instancia de base de datos. Este parámetro indica MB, por lo que debe utilizar un valor entero. Las expresiones, fórmulas y funciones no son válidas para el parámetro `rds.pg_stat_ramdisk_size`. Asegúrese de reiniciar la instancia de base de datos para que el cambio surta efecto. Para obtener información acerca de cómo configurar los parámetros, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Por ejemplo, el comando de la AWS CLI siguiente establece el parámetro del disco RAM en 256 MB.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name pg-95-ramdisk-testing \
--parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"
```
Después de reiniciar, ejecute el siguiente comando para ver el estado de `stats_temp_directory`.
```
postgres=> SHOW stats_temp_directory;
```
El comando debe devolver lo siguiente.
```
stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)
```
# Espacios de tablas para RDS for PostgreSQL
RDS for PostgreSQL es compatible con los espacios de tablas por razones de compatibilidad. Debido a que todo el almacenamiento se encuentra en un único volumen lógico, no puede usar espacios de tabla para la división o el aislamiento de la E/S. Nuestros puntos de referencia y experiencia indican que un único volumen lógico es la mejor configuración para la mayoría de los casos de uso.
Para crear y utilizar espacios de tablas con su instancia de base de datos RDS para PostgreSQL se requiere el rol de `rds_superuser`. La cuenta de usuario principal de su instancia de base de datos RDS para PostgreSQL (nombre predeterminado, `postgres`) es miembro de este rol. Para obtener más información, consulte [Descripción de los roles y permisos de PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Si especifica un nombre de archivo al crear un espacio de tabla, el prefijo de ruta es `/rdsdbdata/db/base/tablespace`. El siguiente ejemplo coloca los archivos de espacio de tabla en `/rdsdbdata/db/base/tablespace/data`. Este ejemplo asume que existe un usuario `dbadmin` (rol) y que se le otorgó el rol `rds_superuser` necesario para trabajar con espacios de tablas.
```
postgres=> CREATE TABLESPACE act_data
OWNER dbadmin
LOCATION '/data';
CREATE TABLESPACE
```
Para saber más sobre los espacios de tablas de PostgreSQL, consulte [Espacios de tablas](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html) en la documentación de PostgreSQL.
# Intercalaciones de RDS para PostgreSQL para EBCDIC y otras migraciones de mainframe
Las versiones 10 y posteriores de RDS para PostgreSQL incluyen la versión 60.2 de ICU, que se basa en Unicode 10.0 e incluye intercalaciones del repositorio de datos de configuración regional común de Unicode, CLDR 32. Estas bibliotecas de internacionalización de software garantizan que las codificaciones de caracteres se presenten de forma coherente, independientemente del sistema operativo o la plataforma. Para obtener más información acerca de Unicode CLDR-32, consulte la [Nota de la versión de CLDR 32](https://cldr.unicode.org/index/downloads/cldr-32) en el sitio web de CLDR de Unicode. Puede obtener más información sobre los componentes de internacionalización de Unicode (ICU) en el sitio web del [Comité Técnico de la UCI (ICU-TC)](https://icu.unicode.org/home). Para obtener información sobre la ICU-60, consulte [Download ICU 60](https://icu.unicode.org/download/60) (Descargar ICU 60).
A partir de la versión 14.3, RDS para PostgreSQL también incluye intercalaciones que ayudan con la integración y conversión de datos desde sistemas basados en EBCDIC. El código de intercambio decimal extendido codificado en binario extendido o *EBCDIC* se usa comúnmente en los sistemas operativos de mainframe. Estas intercalaciones proporcionadas por Amazon RDS están definidas de forma limitada para ordenar solo los caracteres Unicode que se asignan directamente a las páginas de códigos EBCDIC. Los caracteres se ordenan por puntos de código EBCDIC para permitir la validación de los datos después de la conversión. Estas intercalaciones no incluyen formularios desnormalizados ni caracteres Unicode que no se asignen directamente a un carácter en la página de códigos EBCDIC de origen.
Las asignaciones de caracteres entre las páginas de códigos EBCDIC y los puntos de código Unicode se basan en tablas publicadas por IBM. El conjunto completo está disponible en IBM como un [archivo comprimido](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip) para descargarlo. RDS para PostgreSQL utilizó estas asignaciones con herramientas proporcionadas por la ICU para crear las intercalaciones que se enumeran en las tablas de esta sección. Los nombres de las intercalaciones incluyen un idioma y un país, según lo requiera la ICU. Sin embargo, en las páginas de códigos EBCDIC no se especifican idiomas y algunas páginas de códigos EBCDIC cubren varios países. Esto significa que la parte del idioma y el país de los nombres de intercalaciones de la tabla es arbitraria y no es necesario que coincidan con la configuración regional actual. En otras palabras, el número de página del código es la parte más importante del nombre de la intercalación en esta tabla. Puede usar cualquiera de las intercalaciones que se enumeran en las siguientes tablas en cualquier base de datos de RDS para PostgreSQL.
+ [Unicode to EBCDIC collations table](#ebcdic-table): algunas herramientas de migración de datos de mainframe utilizan LATIN1 o LATIN9 internamente para codificar y procesar datos. Estas herramientas utilizan esquemas de ida y vuelta para proteger la integridad de los datos y admitir la conversión inversa. Las herramientas que procesan datos mediante la intercalación LATIN1, que no requiere un tratamiento especial, pueden usar las intercalaciones de esta tabla.
+ [Unicode to LATIN9 collations table](#latin9-table): puede usar estas intercalaciones en cualquier base de datos de RDS para PostgreSQL.
En la siguiente tabla, encontrará intercalaciones disponibles en RDS para PostgreSQL que asignan páginas de códigos EBCDIC a puntos de código Unicode. Le recomendamos que utilice las intercalaciones de esta tabla para desarrollar aplicaciones que requieran una clasificación basada en el orden de las páginas de códigos de IBM.
| Nombre de intercalación de PostgreSQL | Descripción de la asignación y el orden de clasificación de páginas de códigos |
| --- | --- |
| da-DK-cp277-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 277 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 277 de IBM CP. |
| de-DE-cp273-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 273 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 273 de IBM CP. |
| en-GB-cp285-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 285 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 285 de IBM CP. |
| en-US-cp037-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 037 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 037 de IBM CP. |
| es-ES-cp284-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 284 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 284 de IBM CP. |
| fi-FI-cp278-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 278 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 278 de IBM CP. |
| fr-FR-cp297-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 297 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 297 de IBM CP. |
| it-IT-cp280-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 280 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 280 de IBM CP. |
| nl-BE-cp500-x-icu | Los caracteres Unicode que se asignan directamente a la página de código 500 de IBM EBCDIC (por tablas de conversión) se ordenan de acuerdo con la clasificación de puntos de códigos 500 de IBM CP. |
Amazon RDS proporciona un conjunto de intercalaciones adicionales que ordenan los puntos de código Unicode que se asignan a caracteres LATIN9 mediante las tablas publicadas por IBM, en el orden de los puntos de código originales de acuerdo con la página de códigos EBCDIC de los datos de origen.
| Nombre de intercalación de PostgreSQL | Descripción de la asignación y el orden de clasificación de páginas de códigos |
| --- | --- |
| da-DK-cp1142m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1142 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1142 de IBM CP. |
| de-DE-cp1141m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1141 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1141 de IBM CP. |
| en-GB-cp1146m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1146 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1146 de IBM CP. |
| en-US-cp1140m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1140 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1140 de IBM CP. |
| es-ES-cp1145m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1145 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1145 de IBM CP. |
| fi-FI-cp1143m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1143 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1143 de IBM CP. |
| fr-FR-cp1147m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1147 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1147 de IBM CP. |
| it-IT-cp1144m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1144 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1144 de IBM CP. |
| nl-BE-cp1148m-x-icu | Los caracteres Unicode que se asignan a los caracteres LATIN9 convertidos originalmente desde la página de código 1148 de IBM EBCDIC (según las tablas de conversión) se clasifican en el orden de los puntos de códigos 1148 de IBM CP. |
A continuación, encontrará un ejemplo de cómo utilizar una intercalación de RDS para PostgreSQL.
```
db1=> SELECT pg_import_system_collations('pg_catalog');
pg_import_system_collations
-----------------------------
36
db1=> SELECT '¤' < 'a' col1;
col1
------
t
db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;
col1
------
f
```
Le recomendamos que utilice las intercalaciones de la [Unicode to EBCDIC collations table](#ebcdic-table) y en la [Unicode to LATIN9 collations table](#latin9-table) para el desarrollo de aplicaciones que requieran una clasificación basada en el orden de las páginas de códigos de IBM. Las siguientes intercalaciones (sufijo con la letra “b”) también son visibles en `pg_collation`, pero están pensadas para que las utilicen las herramientas de integración y migración de datos del mainframe en AWS que asignan páginas de códigos con cambios de puntos de código específicos y requieren un tratamiento especial en la intercalación. En otras palabras, no se recomienda el uso de las siguientes intercalaciones.
+ da-DK-277b-x-icu
+ da-DK-1142b-x-icu
+ de-DE-cp273b-x-icu
+ de-DE-cp1141b-x-icu
+ en-GB-cp1146b-x-icu
+ en-GB-cp285b-x-icu
+ en-US-cp037b-x-icu
+ en-US-cp1140b-x-icu
+ es-ES-cp1145b-x-icu
+ es-ES-cp284b-x-icu
+ fi-FI-cp1143b-x-icu
+ fr-FR-cp1147b-x-icu
+ fr-FR-cp297b-x-icu
+ it-IT-cp1144b-x-icu
+ it-IT-cp280b-x-icu
+ nl-BE-cp1148b-x-icu
+ nl-BE-cp500b-x-icu
Para obtener más información sobre la migración de aplicaciones de entornos mainframe a AWS, consulte [What is AWS Mainframe Modernization?](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html) (¿Qué es Mainframe Modernization?).
Para obtener más información sobre la administración de las intercalaciones en PostgreSQL, consulte [Collation Support](https://www.postgresql.org/docs/current/collation.html) (Compatibilidad de Soporte de intercalaciones en la documentación de PostgreSQL.
# Administración de ranuras lógicas de RDS para PostgreSQL
A partir de la versión 17 de Community PostgreSQL, se ha introducido una nueva característica para sincronizar automáticamente las ranuras de replicación lógica de los servidores principales a los servidores en espera mediante el parámetro `sync_replication_slots` o la función relacionada `pg_sync_replication_slots()`, que sincroniza manualmente las ranuras durante la ejecución.
Estas características están disponibles a partir de la versión 17 de RDS para PostgreSQL. Una configuración típica tendrá una instancia principal y su [réplica de lectura](USER_PostgreSQL.Replication.ReadReplicas.md), así como un suscriptor de replicación lógica a la principal.
Asegúrese de que la suscripción se cree con la opción de conmutación por error establecida en true:
```
CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true);
```
Esto crea una ranura lógica en el publicador con la conmutación por error habilitada.
```
postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots;
slot_name | slot_type | failover
-----------+-----------+----------
subname | logical | t
(1 row)
```
Al habilitar la sincronización de ranuras, todas las ranuras de replicación lógica de conmutación por error del servidor principal se crean automáticamente en los servidores físicos y en espera y se sincronizan de forma periódica. Asegúrese de que se hayan establecido los siguientes valores mediante [grupos de parámetros](USER_WorkingWithParamGroups.Associating.md):
+ `rds.logical_replication` debe ser `1` para habilitar la replicación lógica
+ `hot_standby_feedback` debe ser `1` en la instancia en espera
+ Debe establecerse `rds.logical_slot_sync_dbname` en la instancia en espera en un nombre válido de base de datos
El valor predeterminado del parámetro es `postgres`. Si la instancia de publicación lógica tiene la base de datos de `postgres`, no es necesario cambiar el parámetro predeterminado.
+ Debe establecerse `synchronized_standby_slots` en la instancia principal en la ranura de replicación física de la instancia en espera destinada a sincronizarse
+ `sync_replication_slots` debe ser `1` para habilitar la sincronización automática
Con una ranura de suscripción habilitada para la conmutación por error y los valores de parámetros anteriores, cuando se promociona una instancia en espera, el suscriptor puede modificar su suscripción a la instancia recién promovida y continuar con la replicación lógica sin problemas.
# Conexión a una instancia de base de datos que ejecuta el motor de base de datos de PostgreSQL
Una vez que Amazon RDS aprovisione su instancia de base de datos, puede usar cualquier aplicación cliente de SQL estándar para conectarse a la instancia. Antes de que pueda conectarse, la instancia de base de datos tiene que estar disponible y accesible. Si puede conectarse a la instancia desde fuera de la VPC depende de cómo haya creado la instancia de base de datos de Amazon RDS:
+ Si creó la instancia de base de datos como *public* (pública), los dispositivos y las instancias de Amazon EC2 fuera de la VPC se pueden conectarse a la base de datos.
+ Si creó la instancia de base de datos como *private* (privada), solo las instancias y dispositivos de Amazon EC2 dentro de Amazon VPC pueden conectarse a la base de datos.
Para verificar si la instancia de base de datos es pública o privada, use la Consola de administración de AWS para ver la pestaña **Connectivity & security** (Conectividad y seguridad) de la instancia. En **Security** (Seguridad), puede encontrar el valor “Publicly accessible” (Accesible públicamente), con “No” si es privada, y “Yes” (Sí) si es pública.
Para obtener más información sobre las distintas configuraciones de Amazon RDS y Amazon VPC y cómo afectan a la accesibilidad, consulte [Escenarios de acceso a una instancia de base de datos en una VPC](USER_VPC.Scenarios.md).
**Contents**
+ [Instalación del cliente psql](#install-psql)
+ [Búsqueda de información de conexión para una instancia de base de datos RDS para PostgreSQL](#postgresql-endpoint)
+ [Uso de pgAdmin para conectarse a una instancia de base de datos de RDS for PostgreSQL](USER_ConnectToPostgreSQLInstance.pgAdmin.md)
+ [Uso de psql para conectarse a una instancia de base de datos de RDS for PostgreSQL](USER_ConnectToPostgreSQLInstance.psql.md)
+ [Conexión a RDS para PostgreSQL con el controlador JDBC de Amazon Web Services (AWS)](PostgreSQL.Connecting.JDBCDriver.md)
+ [Conexión a RDS para PostgreSQL con el controlador de Python de Amazon Web Services (AWS)](PostgreSQL.Connecting.PythonDriver.md)
+ [Solución de problemas de conexiones a la instancia de RDS for PostgreSQL](USER_ConnectToPostgreSQLInstance.Troubleshooting.md)
+ [Error – FATAL: el *nombre* de la base de datos no existe](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [Error – No se pudo conectar al servidor: se ha agotado el tiempo de espera.](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [Errores con reglas de acceso de grupos de seguridad](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Instalación del cliente psql
Para conectarse a la instancia de base de datos desde una instancia de EC2, puede instalar un cliente PostgreSQL en la instancia de EC2. Para instalar la versión más reciente del cliente psql en Amazon Linux 2023, ejecute el siguiente comando:
```
sudo dnf install postgresql
```
Para instalar la versión más reciente del cliente psql en Amazon Linux 2, ejecute el siguiente comando:
```
sudo yum install -y postgresql
```
Para instalar la versión más reciente del cliente psql en Ubuntu, ejecute el siguiente comando:
```
sudo apt install -y postgresql-client
```
## Búsqueda de información de conexión para una instancia de base de datos RDS para PostgreSQL
Si la instancia de base de datos está disponible y accesible, puede conectarse si proporciona la siguiente información a la aplicación cliente de SQL:
+ El punto de conexión de la instancia de base de datos, que sirve como nombre de host (nombre DNS) de la instancia.
+ El puerto en el que la instancia de base de datos está a la escucha. Para PostgreSQL, el puerto predeterminado es el 5432.
+ El nombre de usuario y la contraseña de la instancia de base de datos. El “nombre de usuario maestro” predeterminado para PostgreSQL es `postgres`.
+ El nombre y contraseña de la base de datos (nombre de base de datos).
Para obtener estos detalles puede usar la Consola de administración de AWS, el comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) de la AWS CLI o la operación [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) de la API de Amazon RDS.
**Para buscar el punto de conexión, el número de puerto y el nombre de la base de datos mediante la Consola de administración de AWS**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Abra la consola de RDS y, a continuación, elija **Databases (Bases de datos)** para mostrar una lista de las instancias de base de datos.
1. Seleccione el nombre de la instancia de base de datos de PostgreSQL para mostrar sus detalles.
1. En la pestaña **Connectivity & security (Conectividad y seguridad)**, copie el punto de enlace. También anote el número de puerto. Necesita el punto de enlace y el número de puerto para conectarse a la instancia de base de datos.
![\[Obtenga el punto de conexión desde la consola de RDS\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/PostgreSQL-endpoint.png)
1. En la pestaña **Configuration** (Configuración), anote el nombre de la base de datos. Si creó una base de datos al crear la instancia de RDS for PostgreSQL, verá el nombre que aparece en DB name (Nombre de base de datos). Si no ha creado una base de datos, el nombre de la base de datos muestra un guion (‐).
![\[Obtener el nombre de la base de datos de la consola de RDS\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/PostgreSQL-db-name.png)
A continuación, se muestran dos formas de conectarse a una instancia de base de datos PostgreSQL. En el primer ejemplo, se usa pgAdmin, una conocida herramienta de administración y desarrollo de código abierto para PostgreSQL. En el segundo ejemplo, se usa psql, una utilidad de línea de comandos que forma parte de una instalación de PostgreSQL.
# Uso de pgAdmin para conectarse a una instancia de base de datos de RDS for PostgreSQL
Puede usar la herramienta de código abierto pgAdmin para conectarse a una instancia de base de datos de RDS for PostgreSQL. Puede descargar y usar pgAdmin desde [http://www.pgadmin.org/](http://www.pgadmin.org/) sin tener una instancia local de PostgreSQL en su ordenador cliente.
**Para conectarse a una instancia de base de datos de RDS for PostgreSQL mediante pgAdmin**
1. Lance la aplicación pgAdmin en su equipo cliente.
1. En la pestaña **Dashboard (Panel)**, elija **Add New Server (Añadir nuevo servidor)**.
1. En el cuadro de diálogo **Create - Server (Crear - Servidor)**, escriba un nombre en la pestaña **General** para identificar el servidor en pgAdmin.
1. En la pestaña **Connection (Conexión)**, escriba la siguiente información de su instancia de base de datos:
+ En **Host**, especifique el punto de enlace, como `mypostgresql.c6c8dntfzzhgv0.us-east-2.rds.amazonaws.com`.
+ En **Port (Puerto)**, escriba el puerto asignado.
+ Para **Username** (Nombre de usuario), escriba el nombre de usuario que especificó cuando creó la instancia de base de datos (si cambió el “nombre de usuario maestro” del predeterminado, `postgres`).
+ En **Password (Contraseña)**, escriba la contraseña que especificó cuando creó la instancia de base de datos.
![\[Escriba la contraseña que especificó al crear la instancia de base de datos.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/Postgres-Connect01.png)
1. Seleccione **Save**.
Si tiene problemas para conectarse, consulte [Solución de problemas de conexiones a la instancia de RDS for PostgreSQL](USER_ConnectToPostgreSQLInstance.Troubleshooting.md).
1. Para obtener acceso a una base de datos en el navegador de pgAdmin, expanda **Servers (Servidores)**, la instancia de base de datos y **Databases (Bases de datos)**. Elija el nombre de base de datos de la instancia de base de datos.
![\[Elija el nombre de base de datos de la instancia de base de datos en el navegador de pgAdmin\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/Postgres-Connect02.png)
1. Para abrir un panel en el que puede especificar comandos SQL, elija **Tools (Herramientas)**, **Query Tool (Herramienta de consulta)**.
# Uso de psql para conectarse a una instancia de base de datos de RDS for PostgreSQL
Puede usar una instancia local de la utilidad de línea de comandos psql para conectarse a una instancia de base de datos de RDS for PostgreSQL. Necesitará que PostgreSQL o el cliente de psql estén instalados en el equipo cliente.
Puede descargar el cliente de PostgreSQL desde el sitio web de [PostgreSQL](https://www.postgresql.org/download/). Para instalar psql, siga las instrucciones específicas de su sistema operativo.
Para conectarse a la instancia de base de datos de RDS for PostgreSQL mediante psql, debe proporcionar la información del host (DNS) y las credenciales de acceso.
Use uno de los siguientes formatos para conectarse a la instancia de base de datos de RDS for PostgreSQL. Cuando se conecte, se le pedirá una contraseña. En los trabajos por lotes o scripts, use la opción `--no-password`. Esta opción está establecida para toda la sesión.
**nota**
Un intento de conexión con `--no-password` falla cuando el servidor requiere autenticación de contraseña y una contraseña no está disponible desde otras fuentes. Para obtener más información, consulte [la documentación de psql](https://www.postgresql.org/docs/13/app-psql.html).
Si es la primera vez que se conecta a esta instancia de base de datos o si aún no creó una base de datos para esta instancia de RDS for PostgreSQL, puede conectarse a la base de datos **postgres** mediante el “nombre de usuario maestro” y la contraseña.
En Unix, utilice el formato siguiente.
```
psql \
--host= \
--port= \
--username= \
--password \
--dbname=
```
En Windows, utilice el formato siguiente.
```
psql ^
--host= ^
--port= ^
--username= ^
--password ^
--dbname=
```
Por ejemplo, el siguiente comando se conecta a una base de datos denominada `mypgdb` en una instancia de base de datos PostgreSQL denominada `mypostgresql` usando credenciales ficticias.
```
psql --host=mypostgresql.c6c8mwvfdgv0.us-west-2.rds.amazonaws.com --port=5432 --username=awsuser --password --dbname=mypgdb
```
# Conexión a RDS para PostgreSQL con el controlador JDBC de Amazon Web Services (AWS)
El controlador JDBC de Amazon Web Services (AWS) se ha diseñado como un contenedor JDBC avanzado. Este contenedor complementa y amplía la funcionalidad del controlador JDBC existente. El controlador se admite con el controlador pgJDBC de la comunidad.
Para instalar el controlador JDBC de AWS, añada el archivo .jar del controlador JDBC de AWS (ubicado en la aplicación `CLASSPATH`) y conserve las referencias al controlador de la comunidad correspondiente. Actualice el prefijo de la URL de conexión correspondiente de la siguiente manera:
+ `jdbc:postgresql://` De a `jdbc:aws-wrapper:postgresql://`
Para obtener más información sobre el controlador JDBC de AWS e instrucciones completas para utilizarlo, consulte el repositorio GitHub del controlador JDBC de [Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-jdbc-wrapper).
# Conexión a RDS para PostgreSQL con el controlador de Python de Amazon Web Services (AWS)
El controlador de Python de Amazon Web Services (AWS) se ha diseñado como un contenedor de Python avanzado. Este contenedor complementa y amplía la funcionalidad del controlador de Psycopg de código abierto. El controlador de Python de AWS se admite con las versiones 3.8 y posteriores de Python. Puede instalar el paquete de `aws-advanced-python-wrapper` mediante el comando `pip`, junto con los paquetes de código abierto de `psycopg`.
Para obtener más información sobre el controlador de Python de AWS e instrucciones completas para utilizarlo, consulte el repositorio GitHub del controlador de Python de [Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-python-wrapper).
# Solución de problemas de conexiones a la instancia de RDS for PostgreSQL
**Topics**
+ [Error – FATAL: el *nombre* de la base de datos no existe](#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [Error – No se pudo conectar al servidor: se ha agotado el tiempo de espera.](#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [Errores con reglas de acceso de grupos de seguridad](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## Error – FATAL: el *nombre* de la base de datos no existe
Si al intentar conectarse recibe un error como `FATAL: database name does not exist`, intente utilizar el nombre de base de datos predeterminado **postgres** para la opción `--dbname`.
## Error – No se pudo conectar al servidor: se ha agotado el tiempo de espera.
Si no puede conectarse a la instancia de base de datos, el error más frecuente es `Could not connect to server: Connection timed out.` Si recibe este error, proceda de la siguiente forma:
+ Compruebe que el nombre de host usado es el punto de enlace de la instancia de base de datos y que el número de puerto usado es correcto.
+ Asegúrese de que la accesibilidad pública de la instancia de base de datos está establecida en **Yes (Sí)** para permitir conexiones externas. Para modificar la configuración **Public access (Acceso público)**, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md).
+ Asegúrese de que el usuario que se conecta a la base de datos tenga acceso CONNECT. Puede utilizar la siguiente consulta para proporcionar acceso a la base de datos.
```
GRANT CONNECT ON DATABASE database name TO username;
```
+ Compruebe que el grupo de seguridad asignado a la instancia de base de datos cuenta con las reglas necesarias para permitir el acceso de su conexión a través de cualquier firewall. Por ejemplo, si la instancia de base de datos se creó utilizando el puerto predeterminado 5432, es posible que su empresa tenga reglas de firewall que bloquean las conexiones a ese puerto desde los dispositivos externos de la empresa.
Para solucionar esto, modifique la instancia de base de datos para que use un puerto diferente. Asegúrese también de que el grupo de seguridad aplicado a la instancia de base de datos permite las conexiones en el nuevo puerto. Para modificar la configuración del **Database port (Puerto de base de datos)**, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md).
+ Compruebe si el puerto que intenta utilizar ya está ocupado por una instancia local de PostgreSQL u otro servicio que se ejecute en el ordenador. Por ejemplo, si tiene una base de datos PostgreSQL local que se ejecuta en el mismo puerto (el valor predeterminado es 5432), podría impedir una conexión correcta a la instancia de base de datos de RDS para PostgreSQL. Asegúrese de que el puerto esté libre o intente conectarse con un número de puerto diferente si es posible.
+ Véase también [Errores con reglas de acceso de grupos de seguridad](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules).
## Errores con reglas de acceso de grupos de seguridad
El problema de conexión más frecuente se suele producir con las reglas de acceso del grupo de seguridad asignado a la instancia de base de datos. Si al crear la instancia de base de datos usó el grupo de seguridad predeterminado, lo más probable es que ese grupo no tuviera las reglas que le permiten obtener acceso a la instancia.
Para que funcione la conexión, el grupo de seguridad que asignó a la instancia de base de datos al crearla debe permitir el acceso a esa instancia de base de datos. Por ejemplo, si la instancia de base de datos se creó en una VPC, debe tener un grupo de seguridad de VPC que autorice las conexiones. Compruebe si la instancia de base de datos se creó utilizando un grupo de seguridad que no autoriza las conexiones desde el dispositivo o la instancia Amazon EC2 en la que se está ejecutando la aplicación.
Puede añadir o editar una regla de entrada en el grupo de seguridad. En **Source (Origen)**, elegir **My IP (Mi IP)** permite el acceso a la instancia de base de datos desde la dirección IP detectada en su navegador. Para obtener más información, consulte [Proporcionar acceso a la instancia de base de datos en la VPC mediante la creación de un grupo de seguridad](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
Igualmente, si la instancia de base de datos se creó fuera de una VPC, debe tener un grupo de seguridad de base de datos que autorice esas conexiones.
Para obtener más información acerca de los grupos de seguridad de Amazon RDS, consulte [Control de acceso con grupos de seguridad](Overview.RDSSecurityGroups.md).
# Protección de conexiones a RDS for PostgreSQL con SSL/TLS
RDS for PostgreSQL admite el cifrado de la capa de sockets seguros (SSL) para las instancias de base de datos de PostgreSQL. Con SSL, puede cifrar una conexión de PostgreSQL entre sus aplicaciones y sus instancias de base de datos de PostgreSQL. También puede obligar a todas las conexiones con su instancia de base de datos PostgreSQL a usar SSL. RDS for PostgreSQL también admite la seguridad de la capa de transporte (TLS), el protocolo sucesor de la SSL.
Para obtener más información sobre Amazon RDS y la protección de datos, incluido el cifrado de conexiones mediante SSL/TLS, consulte [Protección de datos en Amazon RDS](DataDurability.md).
**Topics**
+ [Uso de SSL con una instancia de base de datos PostgreSQL](PostgreSQL.Concepts.General.SSL.md)
+ [Actualización de aplicaciones para la conexión a las instancias de base de datos de PostgreSQL con los nuevos certificados SSL/TLS](ssl-certificate-rotation-postgresql.md)
# Uso de SSL con una instancia de base de datos PostgreSQL
Amazon RDS admite el cifrado de la Capa de conexión segura (SSL) para las instancias de base de datos de PostgreSQL. Con SSL, puede cifrar una conexión de PostgreSQL entre sus aplicaciones y sus instancias de base de datos de PostgreSQL. De forma predeterminada, RDS for PostgreSQL utiliza y espera que todos los clientes se conecten mediante SSL/TLS, pero también puede hacer que sea obligatorio. RDS para PostgreSQL admite las versiones 1.1, 1.2 y 1.3 de la seguridad de la capa de transporte (TLS).
Para obtener la información general acerca de la compatibilidad con SSL y las bases de datos de PostgreSQL, consulte [Compatibilidad con SSL](https://www.postgresql.org/docs/11/libpq-ssl.html) en la documentación de PostgreSQL. Para obtener información sobre el uso de una conexión SSL a través de JDBC, consulte [Configuración del cliente](https://jdbc.postgresql.org/documentation/head/ssl-client.html) en la documentación de PostgreSQL.
La compatibilidad con SSL está disponible en todas las regiones de AWS para PostgreSQL. Amazon RDS crea un certificado SSL para su instancia de base de datos de PostgreSQL cuando se crea la instancia. Si se habilita la verificación con certificado SSL, el certificado incluye el punto de enlace de la instancia de base de datos como nombre común (CN) que el certificado de SSL debe proteger frente a los ataques de suplantación.
**Topics**
+ [Conectar con una instancia de base de datos PostgreSQL a través de SSL](#PostgreSQL.Concepts.General.SSL.Connecting)
+ [Requerir una conexión SSL a una instancia de base de datos PostgreSQL](#PostgreSQL.Concepts.General.SSL.Requiring)
+ [Determinar el estado de la conexión SSL](#PostgreSQL.Concepts.General.SSL.Status)
+ [Conjuntos de cifrado SSL en RDS for PostgreSQL](#PostgreSQL.Concepts.General.SSL.Ciphers)
## Conectar con una instancia de base de datos PostgreSQL a través de SSL
**Para conectar con una instancia de base de datos PostgreSQL a través de SSL**
1. Descargue el certificado.
Para obtener más información acerca de cómo descargar certificados, consulte [Uso de SSL/TLS para cifrar una conexión a una instancia o un clúster de base de datos](UsingWithRDS.SSL.md).
1. Conecte su instancia de base de datos de PostgreSQL a través de SSL.
Cuando se conecte utilizando SSL, su cliente podrá elegir si verifica la cadena de certificados. Si sus parámetros de conexión especifican `sslmode=verify-ca` o `sslmode=verify-full`, su cliente precisa que los certificados de CA de RDS estén en su almacén de confianza o se haga referencia a ellos en la URL de conexión. Este requisito es para verificar la cadena de certificados que firma su certificado de base de datos.
Cuando un cliente, como psql o JDBC, está configurado con soporte de SSL, primero el cliente intenta conectarse a la base de datos con SSL de manera predeterminada. SI el cliente no puede conectarse con SSL, vuelve a la conexión sin SSL. El modo `sslmode` predeterminado utilizado es diferente entre los clientes basados en libpq (como psql) y JDBC. Los clientes basados en libpq y JDBC utilizan de manera predeterminada `prefer`.
Use el parámetro `sslrootcert` para hacer referencia al certificado, por ejemplo: `sslrootcert=rds-ssl-ca-cert.pem`.
A continuación, se muestra un ejemplo de cómo se utiliza `psql` para conectarse a una instancia de base de datos de PostgreSQL mediante SSL con verificación de certificados.
```
$ psql "host=db-name.555555555555.ap-southeast-1.rds.amazonaws.com
port=5432 dbname=testDB user=testuser sslrootcert=rds-ca-rsa2048-g1.pem sslmode=verify-full"
```
## Requerir una conexión SSL a una instancia de base de datos PostgreSQL
Puede exigir que las conexiones a la instancia de base de datos PostgreSQL usen SSL por medio del parámetro `rds.force_ssl`. El valor predeterminado del valor `rds.force_ssl` es 1 (activado) para RDS para PostgreSQL versión 15 y posteriores. Para todas las demás versiones principales de RDS para PostgreSQL 14 y anteriores, el valor predeterminado de este parámetro es 0 (desactivado). Puede definir el parámetro `rds.force_ssl` en 1 (activado) fin de imponer SSL/TLS para las conexiones al clúster de base de datos. Puede definir el parámetro `rds.force_ssl` en 1 (activado) para imponer SSL para las conexiones a la instancia de base de datos.
Para cambiar el valor de este parámetro, debe crear un grupo de parámetros de base de datos personalizado. A continuación, cambie el valor de `rds.force_ssl` en el grupo de parámetros de base de datos personalizado a `1` para activar esta característica. Si prepara el grupo de parámetros de base de datos personalizado antes de crear la instancia de base de datos de RDS for PostgreSQL, puede elegirlo (en lugar de un grupo de parámetros predeterminado) durante el proceso de creación. Si lo hace después de que la instancia de base de datos de RDS for PostgreSQL ya se esté ejecutando, debe reiniciar la instancia para que utilice el grupo de parámetros personalizado. Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Cuando la característica `rds.force_ssl` está activa en la instancia de base de datos, los intentos de conexión que no utilizan SSL se rechazan con el siguiente mensaje:
```
$ psql -h db-name.555555555555.ap-southeast-1.rds.amazonaws.com port=5432 dbname=testDB user=testuser
psql: error: FATAL: no pg_hba.conf entry for host "w.x.y.z", user "testuser", database "testDB", SSL off
```
## Determinar el estado de la conexión SSL
El estado cifrado de su conexión se muestra en el banner de inicio de sesión al establecer conexión con la instancia de base de datos:
```
Password for user master:
psql (10.3)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
También puede cargar la extensión `sslinfo` y llamar después a la función `ssl_is_used()` para determinar si se está usando SSL. La función devuelve `t` si la conexión usa SSL; de lo contrario, devuelve `f`.
```
postgres=> CREATE EXTENSION sslinfo;
CREATE EXTENSION
postgres=> SELECT ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
Para obtener información más detallada, puede usar la siguiente consulta para obtener información de `pg_settings`:
```
SELECT name as "Parameter name", setting as value, short_desc FROM pg_settings WHERE name LIKE '%ssl%';
Parameter name | value | short_desc
----------------------------------------+-----------------------------------------+-------------------------------------------------------
ssl | on | Enables SSL connections.
ssl_ca_file | /rdsdbdata/rds-metadata/ca-cert.pem | Location of the SSL certificate authority file.
ssl_cert_file | /rdsdbdata/rds-metadata/server-cert.pem | Location of the SSL server certificate file.
ssl_ciphers | HIGH:!aNULL:!3DES | Sets the list of allowed SSL ciphers.
ssl_crl_file | | Location of the SSL certificate revocation list file.
ssl_dh_params_file | | Location of the SSL DH parameters file.
ssl_ecdh_curve | prime256v1 | Sets the curve to use for ECDH.
ssl_key_file | /rdsdbdata/rds-metadata/server-key.pem | Location of the SSL server private key file.
ssl_library | OpenSSL | Name of the SSL library.
ssl_max_protocol_version | | Sets the maximum SSL/TLS protocol version to use.
ssl_min_protocol_version | TLSv1.2 | Sets the minimum SSL/TLS protocol version to use.
ssl_passphrase_command | | Command to obtain passphrases for SSL.
ssl_passphrase_command_supports_reload | off | Also use ssl_passphrase_command during server reload.
ssl_prefer_server_ciphers | on | Give priority to server ciphersuite order.
(14 rows)
```
También puede recopilar toda la información sobre el uso de SSL de la instancia de base de datos de RDS for PostgreSQL por proceso, cliente y aplicación mediante la siguiente consulta:
```
SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
FROM pg_stat_ssl
JOIN pg_stat_activity
ON pg_stat_ssl.pid = pg_stat_activity.pid
ORDER BY ssl;
Database name | User name | ssl | client_addr | application_name | backend_type
---------------+-----------+-----+----------------+------------------------+------------------------------
| | f | | | autovacuum launcher
| rdsadmin | f | | | logical replication launcher
| | f | | | background writer
| | f | | | checkpointer
| | f | | | walwriter
rdsadmin | rdsadmin | t | 127.0.0.1 | | client backend
rdsadmin | rdsadmin | t | 127.0.0.1 | PostgreSQL JDBC Driver | client backend
postgres | postgres | t | 204.246.162.36 | psql | client backend
(8 rows)
```
Para identificar el cifrado utilizado para la conexión SSL, puede realizar la consulta de la siguiente manera:
```
postgres=> SELECT ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
Para obtener información acerca de la opción `sslmode`, consulte [Funciones de control de conexión de la base de datos](https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) en la *documentación de PostgreSQL*.
## Conjuntos de cifrado SSL en RDS for PostgreSQL
El parámetro de configuración de PostgreSQL [ssl\$1ciphers](https://www.postgresql.org/docs/current/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SSL) especifica las categorías de conjuntos de cifrado permitidos para las conexiones SSL a la base de datos al usar TLS 1.2 y anteriores.
En RDS para PostgreSQL 16 y versiones posteriores, puede modificar el parámetro `ssl_ciphers` para usar valores específicos de los conjuntos de cifrado de la lista de permitidos. Este es un parámetro dinámico que no requiere el reinicio de la instancia de base de datos. Para ver los conjuntos de cifrado de la lista de permitidos, utilice la consola de Amazon RDS o el siguiente comando de la CLI de AWS:
```
aws rds describe-db-parameters --db-parameter-group-name --region --endpoint-url --output json | jq '.Parameters[] | select(.ParameterName == "ssl_ciphers")'
```
La siguiente tabla muestra los conjuntos de cifrado predeterminados y los conjuntos de cifrado permitidos para las versiones que admiten configuraciones personalizadas.
| Versión del motor de PostgreSQL | Valores predeterminados del conjunto ssl\$1cipher | Valores personalizados del conjunto ssl\$1cipher de la lista de permitidos |
| --- | --- | --- |
| 18 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 17 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 16 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 15 | HIGH:\$1aNULL:\$13DES | No se admite ssl\$1ciphers personalizado |
| 14 | HIGH:\$1aNULL:\$13DES | No se admite ssl\$1ciphers personalizado |
| 13 | HIGH:\$1aNULL:\$13DES | No se admite ssl\$1ciphers personalizado |
| 12 | HIGH:\$1aNULL:\$13DES | No se admite ssl\$1ciphers personalizado |
| 11.4 y versiones secundarias posteriores | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | No se admite ssl\$1ciphers personalizado |
| 11.1, 11.2 | HIGH:MEDIUM:\$13DES:\$1aNULL | No se admite ssl\$1ciphers personalizado |
| 10.9 y versiones secundarias posteriores | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | No se admite ssl\$1ciphers personalizado |
| 10.7 y versiones menores inferiores | HIGH:MEDIUM:\$13DES:\$1aNULL | No se admite ssl\$1ciphers personalizado |
Para configurar todas las conexiones de instancias para que usen el conjunto de cifrado `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`, modifique el grupo de parámetros como se muestra en el siguiente ejemplo:
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_ciphers',ParameterValue='TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',ApplyMethod=immediate"
```
Este ejemplo utiliza un cifrado ECDSA, que requiere que la instancia use una autoridad de certificación con criptografía de curva elíptica (ECC) para establecer una conexión. Para obtener información sobre las autoridades de certificación proporcionadas por Amazon RDS, consulte [Entidades de certificación](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/singWithRDS.SSL.html#UsingWithRDS.SSL.RegionCertificateAuthorities).
Puede verificar los cifrados en uso mediante los métodos descritos en [Determinación del estado de la conexión SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html#PostgreSQL.Concepts.General.SSL.Status).
Los cifrados pueden tener diferentes nombres en función del contexto:
+ Los cifrados de la lista de permitidos que puede configurar en el grupo de parámetros se denominan con sus nombres de IANA.
+ Los banners de inicio de sesión `sslinfo` y `psql` hacen referencia a los cifrados mediante los nombres de OpenSSL.
De forma predeterminada, el valor de `ssl_max_protocol_version` en RDS para PostgreSQL 16 y versiones posteriores es TLS v1.3. Debe establecer el valor de este parámetro en TLS v1.2, ya que TLS v1.3 no utiliza las configuraciones de cifrado especificadas en el parámetro `ssl_ciphers`. Cuando establece el valor como TLS v1.2, las conexiones utilizan solo los cifrados que usted defina en `ssl_ciphers`.
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_max_protocol_version',ParameterValue='TLSv1.2',ApplyMethod=immediate"
```
Para garantizar que las conexiones a la base de datos utilicen SSL, establezca `rds.force_ssl parameter` en 1 en el grupo de parámetros. Para obtener más información acerca de los parámetros y grupos de parámetros, consulte [Grupos de parámetros para Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html).
# Actualización de aplicaciones para la conexión a las instancias de base de datos de PostgreSQL con los nuevos certificados SSL/TLS
Los certificados utilizados para capas de sockets seguros o seguridad de la capa de transporte (SSL/TLS) suelen tener una vida útil establecida. Cuando los proveedores de servicios actualizan sus certificados de la autoridad de certificación (CA), los clientes deben actualizar sus aplicaciones para utilizar los certificados nuevos. A continuación, puede encontrar información sobre cómo determinar si sus aplicaciones cliente utilizan SSL/TLS para conectarse a su instancia de base de datos de Amazon RDS for PostgreSQL. También encontrará información sobre cómo comprobar si esas aplicaciones verifican el certificado del servidor cuando se conectan.
**nota**
Una aplicación cliente configurada para verificar el certificado del servidor antes de la conexión SSL/TLS debe tener un certificado de CA válido en el almacén de confianza del cliente. Actualice el almacén de confianza del cliente cuando sea necesario para acceder a certificados nuevos.
Después actualizar sus certificados de CA en los almacenes de confianza de la aplicación de su cliente, puede rotar los certificados en sus instancias de base de datos. Se recomienda probar estos procedimientos en un entorno que no sea de producción antes de implementarlos en entornos de producción.
Para obtener más información acerca de la rotación de certificados, consulte [Rotar certificados SSL/TLS](UsingWithRDS.SSL-certificate-rotation.md). Para obtener más información acerca de cómo descargar certificados, consulte [Uso de SSL/TLS para cifrar una conexión a una instancia o un clúster de base de datos](UsingWithRDS.SSL.md). Para obtener información sobre el uso de SSL/TLS con las instancias de base de datos de PostgreSQL, consulte [Uso de SSL con una instancia de base de datos PostgreSQL](PostgreSQL.Concepts.General.SSL.md).
**Topics**
+ [Determinación de si las aplicaciones se conectan a sus instancias de base de datos de PostfreSQL mediante SSL](#ssl-certificate-rotation-postgresql.determining-server)
+ [Determinación de si un cliente necesita una verificación de certificados para conectarse](#ssl-certificate-rotation-postgresql.determining-client)
+ [Actualización del almacén de confianza de su aplicación](#ssl-certificate-rotation-postgresql.updating-trust-store)
+ [Uso de conexiones SSL/TLS para diferentes tipos de aplicaciones](#ssl-certificate-rotation-postgresql.applications)
## Determinación de si las aplicaciones se conectan a sus instancias de base de datos de PostfreSQL mediante SSL
Compruebe la configuración de la instancia de base de datos para obtener el valor del parámetro de `rds.force_ssl`. De forma predeterminada, el parámetro `rds.force_ssl` está configurado en `0` (desactivado) para las instancias de base de datos que utilizan versiones de PostgreSQL anteriores a la versión 15. De forma predeterminada, `rds.force_ssl` está configurado en `1` (activado) para las instancias de base de datos que utilizan PostgreSQL versión 15 y versiones principales posteriores. Si el parámetro `rds.force_ssl` está configurado como `1` (activado), se precisa que los clientes utilicen SSL/TLS para las conexiones. Para obtener más información acerca de los grupos de parámetros, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Si utiliza la versión 9.5 o una versión importante anterior de RDS PostgreSQL y `rds.force_ssl` no está configurado como `1` (activado), consulte la vista `pg_stat_ssl` para comprobar las conexiones que utilizan SSL. Por ejemplo, la siguiente consulta devuelve solo las conexiones SSL y la información acerca de los clientes que utilizan SSL.
```
SELECT datname, usename, ssl, client_addr
FROM pg_stat_ssl INNER JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid
WHERE ssl is true and usename<>'rdsadmin';
```
Solo las filas que utilizan conexiones SSL/TLS se muestran con información sobre la conexión. A continuación, se muestra un ejemplo del resultado.
```
datname | usename | ssl | client_addr
----------+---------+-----+-------------
benchdb | pgadmin | t | 53.95.6.13
postgres | pgadmin | t | 53.95.6.13
(2 rows)
```
Esta consulta solo muestra las conexiones actuales en el momento de la consulta. La ausencia de resultados no indica que no haya ninguna aplicación utilizando conexiones SSL. Se pueden establecer otras conexiones SSL en un momento diferente.
## Determinación de si un cliente necesita una verificación de certificados para conectarse
Cuando un cliente, como psql o JDBC, está configurado con soporte de SSL, primero el cliente intenta conectarse a la base de datos con SSL de manera predeterminada. SI el cliente no puede conectarse con SSL, vuelve a la conexión sin SSL. El modo `sslmode` predeterminado utilizado para clientes con libpq (como psql) y JDBC está establecido en `prefer`. El certificado del servidor se verifica solo cuando se proporciona `sslrootcert` con `sslmode` configurado como `verify-ca` o `verify-full`. Se lanza un error si el certificado no es válido.
Utilice `PGSSLROOTCERT` para verificar el certificado con la variable de entorno `PGSSLMODE`, con `PGSSLMODE` establecido como `verify-ca` o `verify-full`.
```
PGSSLMODE=verify-full PGSSLROOTCERT=/fullpath/ssl-cert.pem psql -h pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com -U masteruser -d postgres
```
Utilice el argumento `sslrootcert` para verificar el certificado con `sslmode` en el formato de la cadena de conexión, con `sslmode` establecido como `verify-ca` o `verify-full` para verificar el certificado.
```
psql "host=pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com sslmode=verify-full sslrootcert=/full/path/ssl-cert.pem user=masteruser dbname=postgres"
```
Por ejemplo, en el caso anterior, si utiliza un certificado raíz no válido, observa un error similar a lo siguiente en su cliente.
```
psql: SSL error: certificate verify failed
```
## Actualización del almacén de confianza de su aplicación
Para obtener información sobre la actualización del almacén de confianza para las aplicaciones de PostgreSQL, consulte [Conexiones TCP/IP seguras con SSL](https://www.postgresql.org/docs/current/ssl-tcp.html) en la documentación de PostgreSQL.
Para obtener información sobre la descarga del certificado raíz, consulte [Uso de SSL/TLS para cifrar una conexión a una instancia o un clúster de base de datos](UsingWithRDS.SSL.md).
Para obtener secuencias de comandos de ejemplo que importan certificados, consulte [Script de muestra para la importación de certificados en su almacén de confianza](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script).
**nota**
Cuando actualice el almacén de confianza, puede retener certificados antiguos además de añadir los nuevos certificados.
## Uso de conexiones SSL/TLS para diferentes tipos de aplicaciones
Lo siguiente proporciona información acerca del uso de conexiones SSL/TLS para diferentes tipo de aplicaciones:
+ **psql**
El cliente se ha invocado desde la línea de comandos especificando las opciones como una cadena de conexión o como variables del entorno. Para las conexiones SSL/TLS, las opciones relevantes son `sslmode` (variable de entorno `PGSSLMODE`), `sslrootcert` (variable de entorno `PGSSLROOTCERT`).
Para obtener la lista completa de opciones, consulte [Palabras de clave del parámetro](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS) en la documentación de PostgreSQL. Para obtener la lista completa de variables de entorno, consulte [ Variables de entorno](https://www.postgresql.org/docs/current/libpq-envars.html) en la documentación de PostgreSQL.
+ **pgAdmin**
Este cliente basado en el navegador es una interfaz más intuitiva para conectarse a la base de datos de PostgreSQL.
Para obtener información sobre la configuración de las conexiones, consulte la [documentación de pgAdmin](https://www.pgadmin.org/docs/pgadmin4/latest/server_dialog.html).
+ **JDBC**
JDBC habilita las conexiones de base de datos con aplicaciones de Java.
Para obtener información general sobre la conexión a la base de datos de PostgreSQL con JDBC, consulte [Connecting to the database](https://jdbc.postgresql.org/documentation/use/#connecting-to-the-database) (Conexión con la base de datos) en la documentación del controlador JDBC de PostgreSQL. Para obtener información sobre la conexión con SSL/TLS, consulte [Configuring the client](https://jdbc.postgresql.org/documentation/ssl/#configuring-the-client) (Configuración del cliente) en la documentación del controlador JDBC de PostgreSQL.
+ **Python**
Una biblioteca de Python popular para la conexión a las bases de datos de PostgreSQL es `psycopg2`.
Para obtener información acerca del uso de `psycopg2`, consulte la [documentación de psycopg2](https://pypi.org/project/psycopg2/). Para obtener un breve tutorial sobre cómo conectarse a una base de datos de PostgreSQL, consulte [Tutorial de psycopg2](https://wiki.postgresql.org/wiki/Psycopg2_Tutorial). Puede encontrar información acerca de las opciones que acepta del comando de conexión en [El contenido del módulo psycopg2](http://initd.org/psycopg/docs/module.html#module-psycopg2).
**importante**
Después de que haya determinado que sus conexiones de base de datos utilizan SSL/TLS y haya actualizado el almacén de confianza de su aplicación, puede actualizar su base de datos para que utilice los certificados de rds-ca-rsa2048-g1. Para obtener instrucciones, consulte el paso 3 en [Actualización del certificado de entidad de certificación modificando la instancia o el clúster de base de datos](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating).
# Uso de la autenticación Kerberos con Amazon RDS para PostgreSQL
Puede usar Kerberos para autenticar a los usuarios cuando se conecten a su instancia de base de datos en la que se ejecuta PostgreSQL. Para ello, configure la instancia de base de datos para utilizar AWS Directory Service for Microsoft Active Directory para la autenticación Kerberos. AWS Directory Service for Microsoft Active Directory también se denomina AWS Managed Microsoft AD. Es una función disponible con Directory Service. Para obtener más información, consulte [¿Qué esDirectory Service?](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) en la *Guía de administración de AWS Directory Service*.
Para empezar, cree un directorio de AWS Managed Microsoft AD para almacenar las credenciales de usuario. A continuación, proporcione a su instancia de base de datos de PostgreSQL el dominio de Active Directory y otra información. Cuando los usuarios se autentican con la instancia de de base de datos de PostgreSQL, las solicitudes de autenticación se reenvían al directorio AWS Managed Microsoft AD.
Mantener todas las credenciales en el mismo directorio puede ahorrarle tiempo y esfuerzo. Tiene un lugar centralizado para almacenar y administrar credenciales para varias instancias de bases de datos. El uso de un directorio también puede mejorar su perfil de seguridad general.
Además, puede acceder a las credenciales desde su propio Microsoft Active Directory en las instalaciones. Para ello, cree una relación de dominio de confianza para que el directorio de AWS Managed Microsoft AD confíe en su Microsoft Active Directory en las instalaciones. De esta manera, los usuarios pueden acceder a las instancias de los de PostgreSQL con la misma experiencia de inicio de sesión único (SSO) de Windows que cuando acceden a cargas de trabajo en las instalaciones.
Una base de datos puede utilizar la autenticación por contraseña o la autenticación por contraseña con Kerberos o con la autenticación de AWS Identity and Access Management (IAM). Para obtener más información acerca de la autenticación IAM, consulte [Autenticación de bases de datos de IAM para MariaDB, MySQL, and PostgreSQL](UsingWithRDS.IAMDBAuth.md).
**nota**
RDS para PostgreSQL no admite la autenticación Kerberos para grupos de Active Directory.
**Topics**
+ [Disponibilidad en regiones y versiones](#postgresql-kerberos.RegionVersionAvailability)
+ [Información general de la autenticación Kerberos para instancias de base de datos de PostgreSQL](#postgresql-kerberos-overview)
+ [Configuración de autenticación Kerberos para instancias de base de datos de PostgreSQL](postgresql-kerberos-setting-up.md)
+ [Administración de una instancia de base de datos de RDS para PostgreSQL en un dominio de Active Directory](postgresql-kerberos-managing.md)
+ [Conexión a PostgreSQL con autenticación Kerberos](postgresql-kerberos-connecting.md)
## Disponibilidad en regiones y versiones
La disponibilidad de las características varía según las versiones específicas de cada motor de base de datos y entre Regiones de AWS. Para obtener más información sobre la disponibilidad en versiones y regiones de RDS para PostgreSQL con autenticación Kerberos, consulte [Regiones y motores de base de datos admitidos para autenticación de Kerberos en Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md).
## Información general de la autenticación Kerberos para instancias de base de datos de PostgreSQL
Para configurar la autenticación Kerberos para una instancia de base de datos de PostgreSQL, complete los siguientes pasos generales, que se describen con más detalle más adelante:
1. Utilice AWS Managed Microsoft AD para crear un directorio de AWS Managed Microsoft AD. Puede utilizar la Consola de administración de AWS, la AWS CLI o la API de Directory Service para crear el directorio. Asegúrese de abrir los puertos de salida relevantes en el grupo de seguridad del directorio para que el directorio pueda comunicarse con la instancia.
1. Cree un rol que proporcione a Amazon RDS acceso para realizar llamadas a su directorio de AWS Managed Microsoft AD. Para ello, cree un rol de AWS Identity and Access Management (IAM) que utilice la política administrada de IAM `AmazonRDSDirectoryServiceAccess`.
Para que el rol de IAM permita el acceso, el punto de enlace AWS Security Token Service (AWS STS) debe activarse en la región de AWS correcta para su cuenta de AWS. Los puntos de conexión de AWS STS están activos de forma predeterminada en todas las Regiones de AWS y puede usarlos sin ninguna acción posterior. Para obtener más información, consulte [Activación y desactivación de AWS STS en una región de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate) en la *Guía del usuario de IAM*.
1. Cree y configure usuarios en el directorio de AWS Managed Microsoft AD usando las herramientas de Microsoft Active Directory. Para obtener más información sobre la creación de usuarios en su Active Directory, consulte [Administrar usuarios y grupos en AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) en la *Guía de administración de Directory Service*.
1. Si piensa localizar el directorio y la instancia de base de datos en diferentes cuentas de AWS o nubes virtuales privadas (VPC), configure la interconexión de VPC. Para obtener más información, consulte [¿Qué es una interconexión de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) en la *Amazon VPC Peering Guide*.
1. Cree o modifique una instancia de base de datos de PostgreSQL desde la consola, la CLI o la API de RDS utilizando uno de los siguientes métodos:
+ [Creación de una instancia de base de datos de Amazon RDS](USER_CreateDBInstance.md)
+ [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md)
+ [Restauración a una instancia de base de datos](USER_RestoreFromSnapshot.md)
+ [Restauración de una instancia de base de datos a un momento especificado para Amazon RDS](USER_PIT.md)
Puede localizar la instancia en la misma Amazon Virtual Private Cloud (VPC) que el directorio o en una VPC o cuenta de AWS diferente. Cuando cree o modifique la instancia de base de datos de PostgreSQL, haga lo siguiente:
+ Proporcione el identificador de dominio (identificador `d-*`) que se generó cuando creó el directorio.
+ Proporcione el nombre del rol de IAM que ha creado.
+ Asegúrese de que el grupo de seguridad de la instancia de base de datos pueda recibir tráfico de entrada del grupo de seguridad del directorio.
1. Use las credenciales de usuario maestro de RDS para conectarse a la instancia de base de datos de PostgreSQL. Cree el usuario en PostgreSQL para que sea identificado externamente. Los usuarios identificados externamente pueden iniciar sesión en la instancia de base de datos de PostgreSQL utilizando la autenticación Kerberos.
# Configuración de autenticación Kerberos para instancias de base de datos de PostgreSQL
Utilice AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) para configurar la autenticación Kerberos para una instancia de base de datos de PostgreSQL. Para configurar la autenticación Kerberos, siga los pasos que se indican a continuación:
**Topics**
+ [Paso 1: crear un directorio con AWS Managed Microsoft AD](#postgresql-kerberos-setting-up.create-directory)
+ [Paso 2: (opcional) crear una relación de confianza entre su Active Directory en las instalaciones y Directory Service](#postgresql-kerberos-setting-up.create-trust)
+ [Paso 3: crear un rol de IAM para que Amazon RDS acceda a Directory Service](#postgresql-kerberos-setting-up.CreateIAMRole)
+ [Paso 4: crear y configurar usuarios](#postgresql-kerberos-setting-up.create-users)
+ [Paso 5: habilitar el tráfico entre VPC entre el directorio y la instancia de base de datos](#postgresql-kerberos-setting-up.vpc-peering)
+ [Paso 6: crear o modificar una instancia de base de datos de PostgreSQL](#postgresql-kerberos-setting-up.create-modify)
+ [Paso 7: crear usuarios de PostgreSQL para las entidades principales de Kerberos](#postgresql-kerberos-setting-up.create-logins)
+ [Paso 8: configurar un cliente de PostgreSQL](#postgresql-kerberos-setting-up.configure-client)
## Paso 1: crear un directorio con AWS Managed Microsoft AD
Directory Service crea un directorio de Active Directory completamente administrado en la nube de AWS. Al crear un directorio de AWS Managed Microsoft AD, Directory Service crea dos controladores de dominio y servidores DNS para usted. Los servidores de directorios se crean en diferentes subredes de una VPC. Esta redundancia ayuda a garantizar que su directorio permanezca accesible incluso si ocurre un error.
Cuando se crea un directorio de AWS Managed Microsoft AD, AWS Directory Service realiza las siguientes tareas en su nombre:
+ Configura un Active Directory dentro de la VPC.
+ Crea una cuenta de administrador del directorio con el nombre de usuario `Admin` y la contraseña especificada. Esta cuenta le permite administrar el directorio.
**importante**
Asegúrese de guardar esta contraseña. Directory Service no almacena esta contraseña y no se puede recuperar ni restablecer.
+ Crea un grupo de seguridad para los controladores del directorio. El grupo de seguridad debe permitir la comunicación con la instancia de base de datos de PostgreSQL.
Al lanzar AWS Directory Service for Microsoft Active Directory, AWS crea una unidad organizativa (OU) que contiene todos los objetos del directorio. Esta unidad organizativa, que tiene el nombre de NetBIOS que introdujo al crear el directorio, se encuentra en la raíz del dominio. La raíz del dominio es propiedad de AWS, que también se encarga de su administración.
La cuenta `Admin` que se creó con el directorio de AWS Managed Microsoft AD dispone de permisos para realizar las actividades administrativas más habituales para la unidad organizativa:
+ Crear, actualizar o eliminar usuarios
+ Añadir recursos a su dominio, como servidores de archivos o de impresión y, a continuación, asignar permisos para esos recursos a usuarios dentro de la unidad organizativa
+ Crear unidades organizativas y contenedores adicionales
+ Delegar autoridad
+ Restaurar objetos eliminados de la papelera de reciclaje de Active Directory
+ Ejecute módulos de Active Directory y Domain Name Service (DNS) para Windows Powershell en el servicio web de Active Directory
La cuenta `Admin` también tiene derechos para realizar las siguientes actividades en todo el dominio:
+ Administrar configuraciones DNS (agregar, quitar o actualizar registros, zonas y programas de envío).
+ Ver logs de eventos DNS
+ Ver logs de eventos de seguridad
**Para crear un directorio con AWS Managed Microsoft AD**
1. En el panel de navegación de la [consola de Directory Service](https://console.aws.amazon.com/directoryservicev2/), elija **Directories (Directorios)** y, a continuación, elija **Set up Directory (Configurar directorio)**.
1. Elija **AWS Managed Microsoft AD**. AWS Managed Microsoft AD es la única opción que se admite actualmente para usar con Amazon RDS.
1. Elija **Next (Siguiente)**.
1. En la página **Enter directory information (Especifique la información del directorio)**, facilite la siguiente información:
**Edición**
Elija la edición que se adapte a sus necesidades.
**Nombre de DNS del directorio**
El nombre completo del directorio, como por ejemplo **corp.example.com**.
**Nombre NetBIOS del directorio**
Un nombre abreviado del directorio opcional, como COR `CORP`.
**Descripción del directorio**
Descripción opcional del directorio.
**Contraseña de administrador**
Contraseña del administrador del directorio. Al crear el directorio, se crea también una cuenta de administrador con el nombre de usuario `Admin` y esta contraseña.
La contraseña del administrador del directorio no puede contener la palabra "admin". La contraseña distingue entre mayúsculas y minúsculas y debe tener un mínimo de 864 caracteres y un máximo de 64. También debe contener al menos un carácter de tres de las siguientes categorías:
+ Letras minúsculas (a–z)
+ Letras mayúsculas (A–Z)
+ Números (0–9)
+ Caracteres no alfanuméricos (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
**Confirm password**
Vuelva a escribir la contraseña de administrador.
Asegúrese de guardar esta contraseña. Directory Service no almacena esta contraseña y no se puede recuperar ni restablecer.
1. Elija **Next (Siguiente)**.
1. En la página **Choose VPC and subnets (Elegir la VPC y las subredes)**, proporcione la información siguiente:
**VPC**
Elija la VPC del directorio. Puede crear la instancia de base de datos de PostgreSQL en esta misma VPC o en una VPC diferente.
**Subredes**
Elija las subredes de los servidores del directorio. Las dos subredes deben estar en diferentes zonas de disponibilidad.
1. Elija **Next (Siguiente)**.
1. Revise la información del directorio. Si es necesario realizar algún cambio, seleccione **Previous (Anterior)** y realizar los cambios. Cuando la información sea correcta, seleccione **Create directory (Crear directorio)**.
![\[Detalles del directorio\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
La creación del directorio tarda varios minutos. Cuando se haya creado correctamente, el valor de **Status (Estado)** cambiará a **Active (Activo)**.
Para ver información acerca de su directorio, seleccione el ID del directorio en la lista de directorios. Anote el valor de **Directory ID (ID de directorio)**. Necesita este valor cuando cree o modifique su instancia de base de datos de PostgreSQL.
![\[Imagen de página de detalles\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## Paso 2: (opcional) crear una relación de confianza entre su Active Directory en las instalaciones y Directory Service
Si no planea usar su propio Microsoft Active Directory local, vaya a [Paso 3: crear un rol de IAM para que Amazon RDS acceda a Directory Service](#postgresql-kerberos-setting-up.CreateIAMRole).
Para obtener la autenticación Kerberos mediante Active Directory en las instalaciones, debe crear una relación de dominio de confianza entre Microsoft Active Directory en las instalaciones y el directorio AWS Managed Microsoft AD (creado en [Paso 1: crear un directorio con AWS Managed Microsoft AD](#postgresql-kerberos-setting-up.create-directory)). La confianza puede ser unidireccional, donde el directorio AWS Managed Microsoft AD confía en Microsoft Active Directory local. La confianza también puede ser bidireccional, donde ambos Active Directories confían entre sí. Para obtener más información acerca de la configuración de relaciones de confianza con Directory Service, consulte [Cuándo crear una relación de confianza](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html) en la *guía de administración de AWS Directory Service*.
**nota**
Si utiliza Microsoft Active Directory en las instalaciones, los clientes de Windows se conectan con el nombre de dominio del Directory Service en el punto de conexión en lugar de con rds.amazonaws.com. Para obtener más información, consulte [Conexión a PostgreSQL con autenticación Kerberos](postgresql-kerberos-connecting.md).
Asegúrese de que el nombre de dominio local de Microsoft Active Directory incluya un enrutamiento de sufijo DNS que corresponda a la relación de confianza recién creada. En la siguiente captura de pantalla, se muestra un ejemplo.
![\[El enrutamiento DNS corresponde a la confianza creada\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/kerberos-auth-trust.png)
## Paso 3: crear un rol de IAM para que Amazon RDS acceda a Directory Service
Para que Amazon RDS llame a Directory Service en su nombre, su cuenta de AWS se precisa un rol de IAM que utilice la política de IAM administrada `AmazonRDSDirectoryServiceAccess`. Este rol permite que Amazon RDS llame a Directory Service.
Cuando se crea una instancia de base de datos con la Consola de administración de AWS y la cuenta de usuario de la consola tiene el permiso `iam:CreateRole`, la consola crea automáticamente el rol de IAM necesario. En este caso, el nombre del rol es `rds-directoryservice-kerberos-access-role`. De no ser así, debe crear el rol de IAM manualmente. Cuando cree este rol de IAM, elija `Directory Service` y asocie la política administrada de AWS `AmazonRDSDirectoryServiceAccess` a este.
A fin de obtener más información acerca de la creación de roles de IAM para un servicio, consulte [Creación de un rol para delegar permisos a un servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la *guía del usuario de IAM*.
**nota**
El rol de IAM utilizado para la autenticación de Windows para RDS para Microsoft SQL Server no puede ser utilizado por Amazon RDS para PostgreSQL.
Como alternativa al uso de la política administrada de `AmazonRDSDirectoryServiceAccess`, puede crear políticas con los permisos necesarios. En este caso, el rol de IAM debe tener la siguiente política de confianza de IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
El rol debe también tener la siguiente política de rol de IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
Para suscribirse a Regiones de AWS, utilice las entidades principales de servicios específicos de la región en las políticas de confianza de roles de IAM. Cuando cree una política de confianza para servicios en estas regiones, especifique el código de región en la entidad principal de servicio.
En el siguiente ejemplo se muestra una política de confianza que incluye entidades principales de servicio específicas de la región:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.REGION-CODE.amazonaws.com",
"rds.REGION-CODE.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Reemplace REGION-CODE por el código de la región específica. Por ejemplo, utilice las siguientes entidades principales de servicio para la región Asia-Pacífico (Melbourne):
```
"Service": [
"directoryservice.rds.ap-southeast-4.amazonaws.com",
"rds.ap-southeast-4.amazonaws.com"
]
```
## Paso 4: crear y configurar usuarios
Puede crear usuarios usando la herramienta Usuarios y equipos de Active Directory. Es una de las herramientas Active Directory Domain Services y Active Directory Lightweight Directory Services. Para obtener más información, consulte [Agregar usuarios y equipos al dominio de Active Directory](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/create-an-active-directory-server#add-users-and-computers-to-the-active-directory-domain) en la documentación de Microsoft. En este caso, los usuarios son individuos u otras entidades, como sus equipos, que forman parte del dominio y cuyas identidades se mantienen en el directorio.
Para crear usuarios en un directorio de Directory Service, debe estar conectado a una instancia de Amazon EC2 con Windows que sea miembro del directorio de Directory Service. Al mismo tiempo, debe iniciar sesión como usuario con privilegios para crear usuarios. Para obtener más información, consulte [Crear un usuario](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_create_user.html) en la *Guía de administración de AWS Directory Service*.
## Paso 5: habilitar el tráfico entre VPC entre el directorio y la instancia de base de datos
Si prevé ubicar el directorio y la instancia de base de datos en la misma VPC, omita este paso y continúe con [Paso 6: crear o modificar una instancia de base de datos de PostgreSQL](#postgresql-kerberos-setting-up.create-modify).
Si tiene previsto ubicar el directorio y la instancia de base de datos en diferentes VPC, configure el tráfico entre VPC mediante la interconexión de VPC o [AWSTransit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html).
El siguiente procedimiento permite el tráfico entre VPC mediante la interconexión de VPC. Siga las instrucciones de [¿Qué es una interconexión de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) en la *Guía de interconexión de Amazon Virtual Private Cloud*.
**Para habilitar el tráfico entre VPC mediante la interconexión de VPC**
1. Configure las reglas de enrutamiento de VPC adecuadas para garantizar que el tráfico de red pueda fluir en ambos sentidos.
1. Asegúrese de que el grupo de seguridad de la instancia de base de datos pueda recibir tráfico de entrada del grupo de seguridad del directorio.
1. Asegúrese de que no haya una regla de lista de control de acceso (ACL) a la red para bloquear el tráfico.
Si una cuenta de AWS distinta es la propietaria del directorio, debe compartirlo.
**Para compartir el directorio entre cuentas de AWS**
1. Comience a compartir el directorio con la cuenta de AWS en la que se creará la instancia de base de datos mediante las instrucciones de [Tutorial: Uso compartido del directorio de AWS Managed Microsoft AD para realizar la unión al dominio de EC2 sin problemas](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) en la *Guía de administración de Directory Service*.
1. Inicie sesión en la consola de Directory Service utilizando la cuenta para la instancia de base de datos y asegúrese de que el dominio tiene el estado `SHARED` antes de continuar.
1. Una vez iniciada sesión en la consola de Directory Service utilizando la cuenta de la instancia de base de datos, anote el valor de **Directory ID (ID de directorio)**. Utilice este identificador de directorio para unir la instancia de base de datos al dominio.
## Paso 6: crear o modificar una instancia de base de datos de PostgreSQL
Cree o modifique una instancia de base de datos de PostgreSQL para usarla con su directorio. Puede utilizar la consola, la CLI o la API de RDS para asociar una instancia de base de datos con un directorio. Puede hacerlo de una de las siguientes formas:
+ Cree una nueva instancia de base de datos de PostgreSQL utilizando la consola, el comando de CLI [ create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) o la operación [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) de la API de RDS. Para obtener instrucciones, consulte [Creación de una instancia de base de datos de Amazon RDS](USER_CreateDBInstance.md).
+ Modifique una instancia de base de datos de PostgreSQL existente utilizando la consola, el comando de CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) o la operación [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) de la API de RDS. Para obtener instrucciones, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md).
+ Restaure una instancia de base de datos de PostgreSQL a partir de una instantánea de base de datos utilizando la consola, el comando de CLI [ restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) o la operación [ RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) de la API de RDS. Para obtener instrucciones, consulte [Restauración a una instancia de base de datos](USER_RestoreFromSnapshot.md).
+ Restaure una instancia de base de datos de PostgreSQL a partir de un punto en el tiempo utilizando la consola, el comando de CLI [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) o la operación [ RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) de la API de RDS. Para obtener instrucciones, consulte [Restauración de una instancia de base de datos a un momento especificado para Amazon RDS](USER_PIT.md).
La autenticación de Kerberos solo es compatible con de clústeres de base de datos de PostgreSQL en una VPC. La instancia de DB puede estar en la misma VPC que el directorio o en una VPC diferente. La instancia de base de datos debe usar un grupo de seguridad que permita el ingreso y la salida dentro de la VPC del directorio, de modo que la instancia de base de datos pueda comunicarse con el directorio.
### Consola
Si utiliza la consola para crear, modificar o restaurar una instancia de base de datos, elija **Password and Kerberos authentication (Contraseña y autenticación de Kerberos)** en la sección **Database authentication (Autenticación de base de datos)**. Luego, elija **Browse Directory** (Examinar directorio). Seleccione el directorio o elija **Create a new directory** (Crear un nuevo directorio) para utilizar Directory Service.
![\[Elegir Kerberos para la autenticación e identificar el directorio que se va a utilizar.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/rpg-authentication-use-kerberos.png)
### AWS CLI
Cuando utilice la AWS CLI, se necesitan los siguientes parámetros para que la instancia de base de datos pueda usar el directorio que ha creado:
+ Para el parámetro `--domain`, utilice el identificador de dominio (identificador "d-\$1") que se generó cuando creó el directorio.
+ Para el parámetro `--domain-iam-role-name`, utilice el rol que creó que usa la política `AmazonRDSDirectoryServiceAccess` de IAM administrada.
Por ejemplo, el siguiente comando de CLI modifica una instancia de base de datos para que use un directorio.
```
aws rds modify-db-instance --db-instance-identifier mydbinstance --domain d-Directory-ID --domain-iam-role-name role-name
```
**importante**
Si modifica una instancia de base de datos para habilitar la autenticación Kerberos, reinicie la instancia de base de datos después de hacer el cambio.
## Paso 7: crear usuarios de PostgreSQL para las entidades principales de Kerberos
En este punto, su instancia de base de datos de RDS para PostgreSQL se une al dominio AWS Managed Microsoft AD. Los usuarios que haya creado en el directorio en el [Paso 4: crear y configurar usuarios](#postgresql-kerberos-setting-up.create-users) deben configurarse como usuarios de la base de datos de PostgreSQL y tener privilegios para iniciar sesión en la base de datos. Para ello, inicie sesión como usuario de la base de datos con privilegios `rds_superuser`. Por ejemplo, si ha aceptado los valores predeterminados al crear la instancia de base de datos de RDS para PostgreSQL, utiliza `postgres`, tal como se muestra en los pasos siguientes.
**Para crear usuarios de la base de datos de PostgreSQL para las entidades principales de Kerberos**
1. Use `psql` para conectarse a su punto de conexión de la instancia de base de datos del RDS para PostgreSQL mediante `psql`. En el siguiente ejemplo, se usa la cuenta de `postgres` predeterminada del rol de `rds_superuser`.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Cree un nombre de usuario de base de datos para cada entidad principal de Kerberos (nombre de usuario de Active Directory) al que desee otorgar acceso a la base de datos. Utilice el nombre de usuario canónico (identidad) tal como se define en la instancia de Active Directory, es decir, un `alias` en minúsculas (nombre de usuario en Active Directory) y el nombre en mayúsculas del dominio de Active Directory para ese nombre de usuario. El nombre de usuario de Active Directory es un usuario autenticado externamente, así que utilice comillas alrededor del nombre tal como se muestra a continuación.
```
postgres=> CREATE USER "username@CORP.EXAMPLE.COM" WITH LOGIN;
CREATE ROLE
```
1. Otorgue el rol `rds_ad` al usuario de la base de datos.
```
postgres=> GRANT rds_ad TO "username@CORP.EXAMPLE.COM";
GRANT ROLE
```
Cuando termine de crear todos los usuarios de PostgreSQL para sus identidades de usuario de Active Directory, los usuarios podrán acceder a la instancia de base de datos de RDS para PostgreSQL con sus credenciales de Kerberos.
Es necesario que los usuarios de bases de datos que se autentican mediante Kerberos lo hagan desde máquinas de cliente que sean miembros del dominio de Active Directory.
Los usuarios de bases de datos a los que se les ha otorgado el rol `rds_ad` tampoco pueden tener el rol `rds_iam`. Esto se aplica también a las membresías anidadas. Para obtener más información, consulte [Autenticación de bases de datos de IAM para MariaDB, MySQL, and PostgreSQL](UsingWithRDS.IAMDBAuth.md).
## Paso 8: configurar un cliente de PostgreSQL
Para configurar un cliente de PostgreSQL, siga los pasos siguientes:
+ Cree un archivo krb5.conf (o equivalente) para apuntar al dominio.
+ Verifique que el tráfico puede fluir entre el host cliente y Directory Service. Use una utilidad de red como, por ejemplo, Netcat para lo siguiente:
+ Verificar el tráfico sobre DNS para el puerto 53.
+ Verificar el tráfico sobre TCP/UDP para el puerto 52 y para Kerberos, lo que incluye los puertos 88 y 464 para Directory Service.
+ Verifique que el tráfico puede fluir entre el host cliente y la instancia de base de datos sobre el puerto de base de datos. Por ejemplo, utilice psql para conectarse y acceder a la base de datos.
A continuación, se muestra el contenido krb5.conf para AWS Managed Microsoft AD.
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
```
A continuación, se muestra el contenido krb5.conf de ejemplo para un Microsoft Active Directory local.
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
ONPREM.COM = {
kdc = onprem.com
admin_server = onprem.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
.onprem.com = ONPREM.COM
onprem.com = ONPREM.COM
.rds.amazonaws.com = EXAMPLE.COM
.amazonaws.com.rproxy.goskope.com.cn = EXAMPLE.COM
.amazon.com = EXAMPLE.COM
```
# Administración de una instancia de base de datos de RDS para PostgreSQL en un dominio de Active Directory
Puede usar la consola, la CLI o la API de RDS para administrar la instancia de base de datos y su relación con Microsoft Active Directory. Puede, por ejemplo, asociar un Active Directory para habilitar la autenticación Kerberos. También puede eliminar la asociación para un Active Directory para deshabilitar la autenticación Kerberos. También puede mover una instancia de base de datos que va a ser autenticada externamente por un Microsoft Active Directory a otro.
Por ejemplo, con la CLI, puede hacer lo siguiente:
+ Para volver a intentar habilitar la autenticación Kerberos para una suscripción con error, use el comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) de la CLI. Especifique el ID de directorio de pertenencia actual para la opción `--domain`.
+ Para deshabilitar la autenticación Kerberos en una instancia de base de datos, utilice el comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) de la CLI. Especifique `none` para la opción `--domain`.
+ Para mover una instancia de base de datos desde un dominio a otro, utilice el comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) de la CLI. Especifique el identificador de dominio del nuevo dominio para la opción `--domain`.
## Descripción de la pertenencia a los dominios
Después de crear o modificar la instancia de base de datos, se convierte en un miembro del dominio. Puede ver el estado de la suscripción al dominio en la consola o ejecutando el comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) de la CLI. El estado de la instancia de base de datos puede ser uno de los siguientes:
+ `kerberos-enabled`: la instancia de base de datos tiene habilitada la autenticación Kerberos.
+ `enabling-kerberos` - AWS está en proceso de habilitar la autenticación Kerberos en esta instancia de base de datos.
+ `pending-enable-kerberos`: la habilitación de la autenticación Kerberos está pendiente en esta instancia de base de datos.
+ `pending-maintenance-enable-kerberos` - AWS intentará habilitar la autenticación Kerberos en la instancia de base de datos durante el próximo periodo de mantenimiento programado.
+ `pending-disable-kerberos`: la deshabilitación de la autenticación Kerberos está pendiente en esta instancia de base de datos.
+ `pending-maintenance-disable-kerberos` - AWS intentará desactivar la autenticación Kerberos en la instancia de base de datos durante el próximo periodo de mantenimiento programado.
+ `enable-kerberos-failed` - Un problema de configuración ha impedido que AWS habilite la autenticación Kerberos en la instancia de base de datos. Corrija el problema de configuración antes de volver a ejecutar el comando para modificar la instancia de base de datos.
+ `disabling-kerberos` - AWS está en proceso de desactivar la autenticación Kerberos en esta instancia de base de datos.
Una solicitud para habilitar la autenticación Kerberos puede generar un error a causa de un problema de conectividad de la red o de un rol de IAM incorrecto. En algunos casos, el intento de habilitar la autenticación Kerberos podría producir un error al crear o modificar una instancia de base de datos. En tal caso, asegúrese de que está utilizando el rol de IAM correcto, a continuación modifique la instancia de base de datos para unirse al dominio.
**nota**
Solo la autenticación Kerberos con RDS para PostgreSQL envía tráfico a los servidores DNS del dominio. Las otras solicitudes de DNS se tratan como acceso de red saliente en las instancias de bases de datos que ejecutan PostgreSQL. Para obtener más información acerca del acceso de red saliente con RDS para PostgreSQL, consulte [Uso de un servidor de DNS personalizado para el acceso a la red de salida.](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md).
# Conexión a PostgreSQL con autenticación Kerberos
Puede conectarse a PostgreSQL con autenticación Kerberos con la interfaz pgAdmin o con una interfaz de línea de comandos como, por ejemplo, psql. Para obtener más información acerca de las conexiones, consulte [Conexión a una instancia de base de datos que ejecuta el motor de base de datos de PostgreSQL](USER_ConnectToPostgreSQLInstance.md) . Para obtener información sobre cómo obtener el punto de conexión, el número de puerto y otros detalles necesarios para la conexión, consulte [Conexión a la instancia de base de datos PostgreSQL](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md#CHAP_GettingStarted.Connecting.PostgreSQL).
**nota**
La autenticación y el cifrado GSSAPI en PostgreSQL están implementados por la biblioteca Kerberos `libkrb5.so`. Características como `postgres_fdw` y `dblink` también se basan en esta misma biblioteca para las conexiones salientes con autenticación o cifrado Kerberos.
## pgAdmin
Para utilizar pgAdmin para conectarse a PostgreSQL con la autenticación Kerberos, siga estos pasos:
1. Lance la aplicación pgAdmin en su equipo cliente.
1. En la pestaña **Dashboard (Panel)**, elija **Add New Server (Añadir nuevo servidor)**.
1. En el cuadro de diálogo **Crear - Servidor**, escriba un nombre en la pestaña **General** para identificar el servidor en pgAdmin.
1. En la pestaña **Connection (Conexión)**, introduzca la siguiente información de su base de datos RDS for PostgreSQL de :
+ En **Host**, introduzca el punto de conexión de la Instancia de base de datos RDS para PostgreSQL. Un punto de conexión tiene un aspecto similar al siguiente:
```
RDS-DB-instance.111122223333.aws-region.rds.amazonaws.com
```
Para conectarse a un Microsoft Active Directory en las instalaciones desde un cliente de Windows, utilice el nombre de dominio del Active Directory administrado por AWS en lugar de `rds.amazonaws.com` en el punto de conexión del host. Por ejemplo, suponga que el nombre de dominio de AWS Managed Active Directory es `corp.example.com`. Luego, para **Host**, el punto de conexión se especificaría de la siguiente manera:
```
RDS-DB-instance.111122223333.aws-region.corp.example.com
```
+ En **Puerto**, escriba el puerto asignado.
+ En **Base de datos de mantenimiento**, escriba el nombre de la base de datos inicial a la que se conectará el cliente.
+ En **Nombre de usuario**, escriba el nombre de usuario que especificó para la autenticación Kerberos en [Paso 7: crear usuarios de PostgreSQL para las entidades principales de Kerberos](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins).
1. Seleccione **Save**.
## Psql
Para utilizar psql para conectar a PostgreSQL con autenticación Kerberos, siga los pasos siguientes:
1. En el símbolo del sistema, ejecute el siguiente comando.
```
kinit username
```
Sustituya *`username`* por el nombre de usuario. En el símbolo del sistema, introduzca la contraseña almacenada en Microsoft Active Directory para el usuario.
1. Si la instancia de base de datos de PostgreSQL utiliza una VPC accesible públicamente, coloque una dirección IP para su punto de conexión de instancia de base de datos en su archivo `/etc/hosts` en el cliente EC2. Por ejemplo, los comandos siguientes obtienen la dirección IP y, a continuación, la ponen en el archivo `/etc/hosts`.
```
% dig +short PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com
;; Truncated, retrying in TCP mode.
ec2-34-210-197-118.AWS-Region.compute.amazonaws.com.
34.210.197.118
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com" >> /etc/hosts
```
Si utiliza un Microsoft Active Directory en las instalaciones desde un cliente de Windows, tiene que conectarse mediante un punto de enlace especializado. En lugar de utilizar el dominio de Amazon `rds.amazonaws.com` en el punto de conexión del host, utilice el nombre de dominio de AWS Managed Active Directory.
Por ejemplo, suponga que el nombre de dominio de su AWS Managed Active Directory es `corp.example.com`. A continuación, use el formato `PostgreSQL-endpoint.AWS-Region.corp.example.com` para el punto de enlace y colóquelo en el archivo `/etc/hosts`.
```
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.corp.example.com" >> /etc/hosts
```
1. Utilice el comando psql siguiente para iniciar sesión en una instancia de de base de datos de PostgreSQL que está integrada con Active Directory.
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com postgres
```
Para iniciar sesión en el clúster de base de datos de PostgreSQL desde un cliente de Windows utilizando un Active Directory en las instalaciones, utilice el siguiente comando psql con el nombre de dominio del paso anterior (`corp.example.com`):
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.corp.example.com postgres
```
# Uso de un servidor de DNS personalizado para el acceso a la red de salida.
RDS for PostgreSQL admite ahora el acceso de red de salida en las instancias de base de datos y permite resoluciones del servicio de nombres de dominio (DNS) desde un servidor de DNS personalizado propiedad del cliente. Solo es posible resolver nombres de dominio completos desde una instancia de base de datos de RDS for PostgreSQL a través de un servidor DNS personalizado.
**Topics**
+ [Activación de la resolución de DNS personalizada](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Enable)
+ [Desactivación de la resolución de DNS personalizada](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Disable)
+ [Configuración de un servidor DNS personalizado](#Appendix.Oracle.CommonDBATasks.CustomDNS.Setup)
## Activación de la resolución de DNS personalizada
Para activar la resolución de DNS en la VPC de su cliente, debe asociar primero un grupo de parámetros de base de datos personalizado a su instancia de RDS for PostgreSQL. A continuación, active el parámetro `rds.custom_dns_resolution` configurándolo en 1 y luego reinicie la instancia de base de datos para que los cambios surtan efecto.
## Desactivación de la resolución de DNS personalizada
Para desactivar la resolución de DNS en la VPC del cliente, primero desactive el parámetro `rds.custom_dns_resolution` de su grupo de parámetros de base de datos personalizado estableciéndolo en 0. Luego reinicie la instancia de base de datos para que los cambios surtan efecto.
## Configuración de un servidor DNS personalizado
Después de configurar un servidor de nombres DNS personalizado, se tardan hasta 30 minutos en propagar los cambios a la instancia de base de datos. Una vez que se propaguen los cambios a la instancia de base de datos, todo el tráfico de red saliente que requiera una búsqueda de DNS consultará el servidor DNS personalizado a través del puerto 53.
**nota**
Si no configura un servidor DNS personalizado y configura `rds.custom_dns_resolution` en 1, los hosts se resuelven mediante una zona privada de Amazon Route 53. Para obtener más información, consulte [Uso de zonas alojadas privadas](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html).
**Para configurar un servidor DNS personalizado para una instancia de base de datos de RDS for PostgreSQL**
1. Desde el conjunto de opciones del protocolo de configuración dinámica de host (DHCP) asociado a la VPC, configure la opción `domain-name-servers` en la dirección IP del servidor de nombres DNS. Para obtener más información, consulte [Conjuntos de opciones de DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html).
**nota**
La opción `domain-name-servers` acepta hasta cuatro valores, pero la instancia de base de datos de Amazon RDS solo utiliza el primer valor.
1. Asegúrese de que el servidor DNS puede resolver todas las consultas de búsqueda, incluidos los nombres de DNS públicos, los nombres de DNS privados de Amazon EC2 y los nombres de DNS específicos del cliente. Si el tráfico de red saliente contiene búsquedas de DNS que el servidor DNS no puede resolver, este debe tener configurados los proveedores de DNS correspondientes.
1. Configure el servidor DNS para que genere respuestas de protocolo de datagramas de usuario (UDP) de 512 bytes como máximo.
1. Configure el servidor DNS para que genere respuestas de protocolo de control de transmisión (TCP) de 1024 bytes o menos.
1. Configure el servidor DNS para que permita el tráfico entrante desde las instancias de bases de datos de Amazon RDS a través del puerto 53. Si el servidor DNS está en una Amazon VPC, la VPC debe tener un grupo de seguridad que contenga reglas entrantes que permitan el tráfico UDP y TCP en el puerto 53. Si el servidor DNS no está en una Amazon VPC, debe tener la configuración de firewall apropiada para permitir el tráfico de entrada UDP y TCP en el puerto 53.
Para obtener más información, consulte [Grupos de seguridad de su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) y [Adición, eliminación y actualización de reglas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules).
1. Configure la VPC de la instancia de base de datos de Amazon RDS para que permita el tráfico saliente a través del puerto 53. La VPC debe tener un grupo de seguridad que contenga reglas salientes que permitan el tráfico UDP y TCP en el puerto 53.
Para obtener más información, consulte [Grupos de seguridad de su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) y [Adición y eliminación de reglas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules) en la *Guía del usuario de Amazon VPC*.
1. Asegúrese de que el trayecto de enrutamiento entre la instancia de base de datos de Amazon RDS y el servidor DNS esté configurado correctamente para permitir el tráfico de DNS.
Además, si la instancia de base de datos de Amazon RDS y el servidor DNS no están en la misma VPC, debe establecerse un emparejamiento entre ellos. Para obtener más información, consulte [¿Qué es un emparejamiento de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) en la *Guía de emparejamiento de VPC de Amazon*.
# Actualizaciones del motor de base de datos de RDS para PostgreSQL
Hay dos tipos de actualizaciones que se pueden administrar para su base de datos de PostgreSQL:
+ Actualizaciones del sistema operativo: a veces, Amazon RDS puede necesitar actualizar el sistema operativo subyacente de su base de datos para aplicar correcciones de seguridad o cambios del sistema operativo. Puede indicar cuándo Amazon RDS debe aplicar las actualizaciones del SO mediante la consola de RDS, la AWS Command Line Interface (AWS CLI) o la API de RDS. Para obtener más información acerca de las actualizaciones del sistema operativo, consulte [Aplicación de actualizaciones a una instancia de base de datos](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades).
+ Actualizaciones del motor de la base de datos: cuando Amazon RDS admita una nueva versión de un motor de base de datos, puede actualizar sus bases de datos a la nueva versión.
En este contexto, una *base de datos* es una instancia de base de datos de RDS para PostgreSQL o un clúster de base de datos Multi-AZ.
Hay dos tipos de actualizaciones de motores de bases de datos de PostgreSQL: actualizaciones de versiones principales y actualizaciones de versiones secundarias.
**Actualizaciones de la versión principal**
*Las actualizaciones de la versión principal* pueden contener cambios realizados en la base de datos que no son compatibles con las versiones anteriores de las aplicaciones. Por lo tanto, debe realizar manualmente las actualizaciones de versiones principales de sus bases de datos. Puede iniciar una actualización de versión principal modificando su instancia de base de datos o clúster de base de datos Multi-AZ. Antes de realizar la actualización de una versión principal, recomendamos que siga los pasos descritos en [Elección de una versión principal para una actualización de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
Amazon RDS gestiona las actualizaciones de las versiones principales de multi-AZ de las siguientes maneras:
+ **Implementación de instancia de base de datos multi-AZ**: Amazon RDS actualiza simultáneamente la instancia principal y cualquier instancia en espera. Es posible que la base de datos no esté disponible durante varios minutos mientras se completa la actualización.
+ **Implementación de clúster de base de datos multi-AZ**: Amazon RDS actualiza de forma simultánea las instancias del lector y del escritor. Es posible que la base de datos no esté disponible durante varios minutos mientras se completa la actualización.
Si actualiza una instancia de base de datos que tiene réplicas de lectura en la región, Amazon RDS actualiza las réplicas junto con la instancia de base de datos principal.
Amazon RDS no actualiza réplicas de lectura de clústeres de base de datos Multi-AZ. Si actualiza la versión principal de un clúster de base de datos multi-AZ, el estado de replicación de las réplicas de lectura cambia a **terminado**. Debe eliminar las réplicas de lectura y volver a crearlas de forma manual una vez finalizada la actualización.
Puede minimizar el tiempo de inactividad necesario para la actualización de una versión principal mediante una implementación azul/verde. Para obtener más información, consulte [Uso de las implementaciones azul/verde de Amazon RDS para actualizar las bases de datos](blue-green-deployments.md).
**Actualizaciones de la versión secundaria**
Por su parte, las *actualizaciones de versiones secundarias* solo incluyen cambios compatibles con las versiones anteriores de las aplicaciones. Puede iniciar manualmente una actualización de versiones secundarias modificando su base de datos. O puede habilitar la opción **Actualización automática de versiones secundarias** al crear o modificar una base de datos. Si lo hace, Amazon RDS actualizará automáticamente su base de datos tras probar y aprobar la nueva versión.
Amazon RDS gestiona las actualizaciones de las versiones secundarias de multi-AZ de las siguientes maneras:
+ **Implementación de instancia de base de datos multi-AZ**: Amazon RDS actualiza simultáneamente la instancia principal y cualquier instancia en espera. Es posible que la base de datos no esté disponible durante varios minutos mientras se completa la actualización.
+ **Implementación de clúster de base de datos multi-AZ**: Amazon RDS actualiza las instancias de base de datos del lector de una en una. A continuación, una de las instancias de base de datos de lector pasa a ser la nueva instancia de base de datos de escritor. Amazon RDS actualiza luego la antigua instancia de escritor (que ahora es una instancia de lector). Los clústeres de bases de datos multi-AZ suelen reducir el tiempo de inactividad de las actualizaciones de versiones secundarias a aproximadamente 35 segundos. Cuando se utilizan con RDS Proxy, se puede reducir aún más el tiempo de inactividad a un segundo o menos. Para obtener más información, consulte [Amazon RDS Proxy ](rds-proxy.md). Otra opción, puede utilizar un proxy de base de datos de código abierto como [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/), [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/) o el [controlador de contenedor JDBC avanzado de AWS](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/).
Si la base de datos tiene réplicas de lectura, debe actualizar primero todas las réplicas de lectura antes de actualizar la instancia o el clúster de origen.
Para obtener más información, consulte [Actualizaciones de versiones secundarias automáticas de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.Minor.md). Para obtener más información acerca de cómo realizar manualmente una actualización de versiones secundarias, consulte [Actualización manual de la versión del motor](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Para obtener más información acerca de las versiones del motor de base de datos y la política para dar de baja versiones del motor de base de datos, consulte [Versiones del motor de base de datos](https://aws.amazon.com/rds/faqs/#Database_Engine_Versions) en las Preguntas frecuentes de Amazon RDS.
**Topics**
+ [Aspectos a tener en cuenta sobre las actualizaciones de PostgreSQL](#USER_UpgradeDBInstance.PostgreSQL.Considerations)
+ [Búsqueda de objetivos de actualización válidos](#USER_UpgradeDBInstance.PostgreSQL.FindingTargets)
+ [Números de versión de PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.VersionID.md)
+ [Números de versión de RDS en RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.rds.version.md)
+ [Elección de una versión principal para una actualización de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
+ [Realización de una actualización de la versión principal de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)
+ [Actualizaciones de versiones secundarias automáticas de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.Minor.md)
+ [Actualización de las extensiones de PostgreSQL en bases de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)
+ [Supervisión de las actualizaciones del motor de RDS para PostgreSQL con eventos](USER_UpgradeDBInstance.PostgreSQL.Monitoring.md)
## Aspectos a tener en cuenta sobre las actualizaciones de PostgreSQL
Para actualizar de forma segura las bases de datos, Amazon RDS usa la utilidad `pg_upgrade` descrita en la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/pgupgrade.html).
Si el periodo de retención de copia de seguridad es mayor que 0, Amazon RDS toma dos instantáneas de base de datos durante el proceso de actualización. La primera instantánea de base de datos es la de la base de datos antes de que se haya llevado a cabo ningún cambio. Si la actualización de sus bases de datos da por resultado un error, puede restaurar esta instantánea para crear una base de datos en la que se ejecuta la versión antigua. La segunda instantánea de base de datos se crea cuando se completa la actualización. Estas instantáneas de bases de datos se eliminan automáticamente una vez que expira el periodo de retención de la copia de seguridad.
**nota**
Amazon RDS toma instantáneas de base de datos durante el proceso de actualización solo si ha definido el período de retención de copia de seguridad de su base de datos en un número mayor que 0. Para modificar el período de retención de copia de seguridad de una instancia de base de datos, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md). No puede configurar un período de retención de copia de seguridad personalizado para un clúster de base de datos Multi-AZ.
Al actualizar la versión principal de una instancia de base de datos, todas las réplicas de lectura dentro de la región también se actualizan automáticamente. Una vez que se inicia el flujo de trabajo de actualización, las réplicas de lectura esperan a que `pg_upgrade` se complete correctamente en la instancia de base de datos principal. A continuación, la actualización de la instancia de base de datos principal espera a que se complete la actualización de la réplica de lectura. Habrá una interrupción hasta que se complete la actualización. Cuando actualiza la versión principal de un clúster de base de datos Multi-AZ, el estado de replicación de las réplicas de lectura cambia a **terminado**.
Una vez completada una actualización, no puede volver a la versión anterior del motor de base de datos. Si desea volver a la versión anterior, restaure la instantánea de base de datos que se realizó antes de la actualización para crear una nueva base de datos.
## Búsqueda de objetivos de actualización válidos
Cuando se utiliza la Consola de administración de AWS para actualizar una base de datos, muestra los destinos de actualización válidos para la base de datos. También puede utilizar el siguiente comando de la AWS CLI para identificar los destinos de actualización válidos de una base de datos:
Para Linux, macOS o Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version version-number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Para Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version version-number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Por ejemplo, para identificar los destinos de actualización válidos para una base de datos de la versión 16.1 de PostgreSQL, ejecute el siguiente comando de la AWS CLI:
Para Linux, macOS o Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Para Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# Números de versión de PostgreSQL
La secuencia de numeración de versiones para el motor de base de datos PostgreSQL es la siguiente:
+ Para las versiones 10 y posteriores de PostgreSQL, el número de versión del motor tiene el formato *principal.secundaria*. El número de versión principal es la parte entera del número de versión. El número de versión secundaria es la parte fraccional del número de versión.
Una actualización de versión principal aumenta la parte entera del número de versión, como la actualización de 10.*secundaria* a 11.*secundaria*.
+ Para las versiones de PostgreSQL anteriores a 10, el número de versión del motor tiene el formato *principal.principal.secundaria*. El número de versión principal del motor es tanto el entero como la primera parte fraccional del número de versión. Por ejemplo, 9.6 es una versión principal. El número de versión secundaria es la tercera parte del número de versión. Por ejemplo, para la versión 9.6.12, el 12 es el número de versión secundaria.
Una actualización de versión principal aumenta la parte principal del número de versión. Por ejemplo, una actualización de *9.6*.12 a 11.14 es una actualización de versión principal, donde *9.6* y *11* son los números de la versión principal.
Para obtener información sobre la numeración de versiones del Soporte extendido de RDS, consulte [Nombre de versiones con el Soporte extendido de Amazon RDS](extended-support-versions.md#extended-support-naming).
# Números de versión de RDS en RDS para PostgreSQL
Los números de versión de RDS utilizan el esquema de nomenclatura `major.minor.patch`. Una versión de parche de RDS incluye correcciones de errores importantes que se agregan a una versión secundaria después de su lanzamiento. Para obtener información sobre la numeración de versiones del Soporte extendido de RDS, consulte [Nombre de versiones con el Soporte extendido de Amazon RDS](extended-support-versions.md#extended-support-naming).
Para identificar el número de versión de Amazon RDS de la base de datos, primero debe crear la extensión `rds_tools` mediante el siguiente comando:
```
CREATE EXTENSION rds_tools;
```
A partir del lanzamiento de la versión 15.2-R2 de PostgreSQL, puede averiguar el número de la versión de RDS de la base de datos de RDS para PostgreSQL con la siguiente consulta SQL:
```
postgres=> SELECT rds_tools.rds_version();
```
Por ejemplo, la consulta de una bases de datos de RDS para PostgreSQL 15.2 muestra lo siguiente:
```
rds_version
----------------
15.2.R2
(1 row)
```
# Elección de una versión principal para una actualización de RDS para PostgreSQL
Las actualizaciones de la versión principal pueden contener cambios realizados en la base de datos que no son compatibles con las versiones anteriores de la base de datos. La nueva funcionalidad puede hacer que sus aplicaciones existentes dejen de funcionar correctamente. Por este motivo, Amazon RDS no aplica automáticamente actualizaciones de la versión principal. Para realizar una actualización de versión principal, modifique la base de datos manualmente. Pruebe exhaustivamente cualquier actualización para comprobar que las aplicaciones funcionen correctamente antes de aplicar la actualización a sus bases de datos de producción. Cuando realice una actualización de versión principal de PostgreSQL, recomendamos que siga los pasos descritos en [Realización de una actualización de la versión principal de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Cuando actualiza una implementación de instancia de base de datos Multi-AZ o instancia de base de datos Single-AZ de PostgreSQL o a su siguiente versión principal, todas las réplicas de lectura asociadas a la base de datos también se actualizan a la siguiente versión principal. En algunos casos, cuando hace una actualización puede saltar hasta una versión principal superior. Si la actualización omite una versión principal, las réplicas de lectura también se actualizan a esa versión principal de destino. Las actualizaciones a la versión 11 que omiten otras versiones principales tienen ciertas limitaciones. Puede encontrar los detalles en los pasos descritos en [Realización de una actualización de la versión principal de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
La mayoría de las extensiones de PostgreSQL no se actualizan durante la actualización del motor PostgreSQL. Estas deben actualizarse por separado. Para obtener más información, consulte [Actualización de las extensiones de PostgreSQL en bases de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
Puede averiguar qué versiones principales están disponibles para su base de datos de RDS para PostgreSQL mediante la ejecución de las siguientes consultas de la:AWS CLI
```
aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
En la tabla siguiente se resumen los resultados de esta consulta para todas las versiones disponibles. Un asterisco (\$1) en el número de versión significa que la versión ya no es compatible. Si la versión actual ya nos es compatible, le recomendamos que actualice al destino de actualización de versión secundaria más reciente o a uno de los otros destinos de actualización disponibles para esa versión.
| Versión de origen actual | Destinos de actualización |
| --- | --- |
| 17.6 | Ninguno |
| 17.5 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 17.4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) |
| 17.3\$1, 17.2 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) |
| 17.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) |
| 16.10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 16.9 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 16.8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) |
| 16.7\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.7 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.6 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.5\$1, 16,4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) |
| 16.3 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) |
| 16.2\$1, 16.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) |
| 15.14 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 15.13 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 15.12, 15.11\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) |
| 15.10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) |
| 15.9\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15.8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15.7 | [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version167), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version165), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) |
| 15.6\$1, 15.5\$1, 15.4\$1, 15.3\$1, 15.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) |
| 14.19 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 14.18 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 14.17, 14.16\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) |
| 14.15 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) |
| 14.14\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) |
| 14.13 | [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414) |
| 14.12 | [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) |
| 14.11\$1, 14.10\$1, 14.9\$1, 14.8\$1, 14.7\$1, 14.6\$1, 14.5\$1, 14.4\$1, 14.3\$1, 14.2\$1, 14.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) |
| 13.22 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 13.21 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) |
| 13.20, 13.19\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 13.18, 13.17\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) |
| 13.16 | [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317) |
| 13.15 | [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) |
| 13.14\$1, 13.13\$1, 13.12\$1, 13.11\$1, 13.10\$1, 13.9\$1, 13.8\$1, 13.7\$1, 13.6\$1, 13.5\$1, 13.4\$1, 13.3\$1, 13.2\$1, 13.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) |
| 12.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 12.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.22, 12.21\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.20\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.19\$1, 12.18\$1, 12.17\$1, 12.16\$1, 12.15\$1, 12.14\$1, 12.13\$1, 12.12\$1, 12.11\$1, 12.10\$1, 12.9\$1, 12.8\$1, 12.7\$1, 12.6\$1, 12.5\$1, 12.4\$1, 12.3\$1, 12.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22-rds.20240509 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808), [11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121), [11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220), [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22, 11.21\$1, 11.20\$1, 11.19\$1, 11.18\$1, 11.17\$1, 11.16\$1, 11.15\$1, 11.14\$1, 11.13\$1, 11.12\$1, 11.11\$1, 11.10\$1, 11.9\$1, 11.8\$1, 11.7\$1, 11.6\$1, 11.5\$1, 11.4\$1, 11.2\$1, 11.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174), [17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222), [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220), [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240418](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240418), [11.22-rds.20240509](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240509), [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808), [11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121), [11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220), [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
\$1 Esta versión ya no es compatible.
# Realización de una actualización de la versión principal de RDS para PostgreSQL
Se recomienda seguir el siguiente proceso al realizar una actualización de versión principal en una base de datos de Amazon RDS para PostgreSQL:
1. **Tenga preparado un grupo de parámetros compatibles con la versión**: si utiliza un grupo de parámetros personalizado, tiene dos opciones. Puede especificar un grupo de parámetros predeterminado para la nueva versión del motor de base de datos. O bien puede crear su propio grupo de parámetros personalizado para la nueva versión del motor de base de datos. Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md) y [Trabajo con grupos de parámetros de clúster de base de datos para clústeres de base de datos Multi-AZ](USER_WorkingWithDBClusterParamGroups.md).
1. **Compruebe si hay clases de base de datos no admitidas**: compruebe que la clase de instancia de la base de datos sea compatible con la versión de PostgreSQL a la que está actualizando. Para obtener más información, consulte [Motores de base de datos compatibles para clases de instancia de base de datos](Concepts.DBInstanceClass.Support.md).
1. **Compruebe si hay algún uso no admitido:**
+ **Transacciones preparadas**: confirme o revierta todas las transacciones preparadas abiertas antes de intentar una actualización.
Puede usar la siguiente consulta para comprobar que no haya transacciones preparadas abiertas en la base de datos.
```
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
```
+ **Tipos de datos reg\$1**: elimine todos los tipos de datos *reg\$1* utilizados antes de intentar realizar una actualización. Salvo en el caso de `regtype` y `regclass`, no se puede actualizar los tipos de datos *reg\$1*. La utilidad `pg_upgrade` no puede hacer persistir este tipo de datos, que Amazon RDS utiliza para realizar la actualización.
Para comprobar que no se usan tipos de datos *reg\$1* incompatibles, utilice la consulta siguiente en cada base de datos.
```
SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
WHERE c.oid = a.attrelid
AND NOT a.attisdropped
AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
'pg_catalog.regprocedure'::pg_catalog.regtype,
'pg_catalog.regoper'::pg_catalog.regtype,
'pg_catalog.regoperator'::pg_catalog.regtype,
'pg_catalog.regconfig'::pg_catalog.regtype,
'pg_catalog.regdictionary'::pg_catalog.regtype)
AND c.relnamespace = n.oid
AND n.nspname NOT IN ('pg_catalog', 'information_schema');
```
1. **Compruebe si hay bases de datos no válidas:**
+ Asegúrese de que no haya bases de datos no válidas. La columna `datconnlimit` del catálogo de `pg_database` incluye un valor de `-2` para marcar como no válidas las bases de datos que se interrumpieron durante una operación `DROP DATABASE`.
Utilice la siguiente consulta para comprobar si hay bases de datos no válidas:
```
SELECT datname FROM pg_database WHERE datconnlimit = - 2;
```
+ La consulta anterior devuelve nombres de bases de datos no válidos. Puede utilizar `DROP DATABASE invalid_db_name;` para eliminar las bases de datos no válidas. También puede utilizar el siguiente comando para eliminar bases de datos no válidas:
```
SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec
```
Para obtener más información sobre las bases de datos no válidas, consulte [Comportamiento de autovacuum con bases de datos no válidas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/appendix.postgresql.commondbatasks.autovacuumbehavior.html).
1. **Gestione los espacios de replicación lógicos**: no se puede llevar a cabo una actualización si la base de datos tiene espacios de replicación lógicos. Los espacios de replicación lógicos se utilizan habitualmente para la migración de AWS DMS y la replicación de tablas de la base de datos a lagos de datos, herramientas de inteligencia empresarial (BI) y otros destinos. Antes de actualizar, asegúrese de conocer el propósito de los espacios de replicación lógicos que se están utilizando y confirme que es correcto eliminarlos. Si los espacios de replicación lógicos se siguen utilizando, no debe eliminarlos y no puede continuar con la actualización.
Si no se necesitan los espacios de replicación lógicos, puede eliminarlos con el siguiente SQL:
```
SELECT * FROM pg_replication_slots WHERE slot_type NOT LIKE 'physical';
SELECT pg_drop_replication_slot(slot_name);
```
Las configuraciones de replicación lógica que utilizan la extensión `pglogical` también deben tener espacios eliminados para que la actualización de la versión principal se realice correctamente. Para obtener información sobre cómo identificar y eliminar los espacios creados con la extensión `pglogical`, consulte [Administración de ranuras de replicación lógica para RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
En la versión 17 y posteriores, los espacios de replicación lógicos en réplicas que no son de lectura se pueden retener tras las actualizaciones. Los espacios de replicación lógicos creados en réplicas de lectura no se retienen tras las actualizaciones.
Asegúrese de que todas las transacciones y los mensajes de decodificación lógica se hayan consumido desde el espacio antes de iniciar la actualización. Si hay archivos de registro de escritura anticipada (WAL) no consumidos en los espacios de replicación lógicos, la actualización fallará y aparecerá un mensaje que identificará los espacios problemáticos. Consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-upgrade.html) para obtener más información.
En los clústeres Multi-AZ con versiones de origen anteriores a 17.8 o 18.2, asegúrese de que `flow_control` esté deshabilitado. Para obtener más información, consulte [Activación y desactivación del control de flujo para clústeres de bases de datos Multi-AZ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html#multi-az-db-clusters-concepts-replica-lag). Para desactivar el control de flujo, elimine la extensión de `shared_preload_libraries` y reinicie la instancia de base de datos.
1. **Gestione las réplicas de lectura**: una actualización de una implementación de una instancia de base de datos Single-AZ o una instancia de base de datos Multi-AZ también actualiza las réplicas de lectura dentro de la región junto con la instancia de base de datos principal. Amazon RDS no actualiza réplicas de lectura de clústeres de base de datos Multi-AZ.
No puede actualizar las réplicas de lectura por separado. Si pudiera, podría dar lugar a situaciones en las que las bases de datos principal y de réplica tienen distintas versiones principales de PostgreSQL. Sin embargo, las actualizaciones de réplica de lectura pueden aumentar el tiempo de inactividad en la instancia de base de datos principal. Para evitar una actualización de réplica de lectura, promueva la réplica a una instancia independiente o elimínela antes de iniciar el proceso de actualización.
El proceso de actualización vuelve a crear el grupo de parámetros de la réplica de lectura basado en el grupo de parámetros actual de la réplica de lectura. Puede aplicar un grupo de parámetros personalizado a una réplica de lectura solo una vez finalizada la actualización con la modificación de la réplica de lectura. Para obtener más información acerca de las réplicas de lectura, consulte [Uso de réplicas de lectura para Amazon RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md).
1. **Gestione los objetos grandes**: en PostgreSQL, los objetos grandes (también conocidos como BLOB) se utilizan para almacenar y administrar objetos binarios de gran tamaño (como archivos, imágenes, vídeos, etc.) que superan el tamaño máximo permitido para los tipos de datos de columna normales. Para obtener más información, consulte la [documentación de los objetos de gran tamaño de PostgreSQL](https://www.postgresql.org/docs/current/largeobjects.html).
Una actualización puede quedarse sin memoria y fallar si hay millones de objetos grandes y la instancia no puede gestionarlos durante una actualización. El proceso de actualización a la versión principal de PostgreSQL consta de dos amplias fases: el volcado del esquema a través de pg\$1dump y la restauración de este a través de pg\$1restore. Si su base de datos tiene millones de objetos de gran tamaño, debe asegurarse de que la instancia tenga memoria suficiente para gestionar pg\$1dump y pg\$1restore durante una actualización y escalarla a un tipo de instancia más grande.
Antes de comenzar una actualización, compruebe si la base de datos tiene objetos de gran tamaño. El catálogo `pg_largeobject_metadata` contiene metadatos asociados a objetos grandes. Los datos reales de objetos grandes se almacenan en `pg_largeobject`. Utilice la siguiente consulta para comprobar el número de objetos grandes:
```
SELECT count(*) FROM pg_largeobject_metadata;
```
Para limpiar los objetos grandes existentes u objetos grandes huérfanos, consulte [Administración de objetos grandes con el módulo lo](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_large_objects_lo_extension.html).
Al planificar una actualización de la versión principal, se recomienda utilizar un tipo de instancia que tenga al menos 32 GB de memoria si la base de datos contiene entre 25 y 30 millones de objetos de gran tamaño. Esta recomendación se basa en nuestras pruebas y puede variar según su carga de trabajo específica y la configuración de la base de datos. Si en la base de datos se incluyen objetos adicionales (como tablas, índices o vistas materializadas), recomendamos seleccionar un tipo de instancia más grande para garantizar un rendimiento óptimo durante el proceso de actualización.
1. **Gestión de las integraciones sin ETL**: si ya tiene una [integración sin ETL](zero-etl.md), [elimínela](zero-etl.deleting.md) antes de realizar una actualización de la versión principal. A continuación, tras completar la actualización, vuelva a crear la integración.
En las versiones de origen 17 y superiores, la integración sin ETL se puede retener mediante la actualización.
1. **Haga una copia de seguridad**: es recomendable que realice una copia de seguridad antes de ejecutar la actualización de versión principal a fin de tener un punto de restauración conocido para la base de datos. Si el período de retención de copia de seguridad es mayor que 0, el proceso de actualización crea instantáneas de base de datos de su base de datos antes y después de la actualización. Para cambiar el periodo de retención de copia de seguridad, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md) y [Modificación de un clúster de base de datos multi-AZ para Amazon RDS.](modify-multi-az-db-cluster.md).
Para realizar manualmente una copia de seguridad, consulte [Creación de una instantánea de base de datos para una instancia de base de datos single-AZ para Amazon RDS](USER_CreateSnapshot.md) y [Creación de una instantánea de clúster de base de datos multi-AZ](USER_CreateMultiAZDBClusterSnapshot.md).
1. **Actualice determinadas extensiones antes de la actualización de versión principal**: si prevé omitir una versión principal con la actualización, tiene que actualizar determinadas extensiones *antes* de llevar a cabo la actualización de versión principal. Por ejemplo, la actualización de las versiones 9.5.x o 9.6.x a las versiones 11.x omite una versión principal. Las extensiones que se van a actualizar incluyen PostGIS y las extensiones relacionadas para procesar datos espaciales.
+ `address_standardizer`
+ `address_standardizer_data_us`
+ `postgis_raster`
+ `postgis_tiger_geocoder`
+ `postgis_topology`
No puede actualizar directamente a la versión 17 de PostgreSQL si utiliza `rdkit` versión 4.6.0 o anterior y PostgreSQL versión 16 o anterior, debido a una incompatibilidad `rdkit`. A continuación se muestran las opciones de actualización:
+ Si utiliza la versión 13 o anterior de PostgreSQL, primero debe realizar una actualización de la versión principal a la versión 14.14 y a las versiones 14 posteriores, 15.9 y versiones 15 posteriores o 16.5 y versiones 16 posteriores primero y, a continuación, realizar la actualización a PostgreSQL 17.
+ Si utiliza las versiones 14, 15 o 16 de PostgreSQL, primero debe realizar una actualización de la versión secundaria a la versión 14.14 y a las versiones 14 posteriores, 15.9 y versiones 15 posteriores o 16.5 y versiones 16 posteriores y, a continuación, realizar la actualización a PostgreSQL versión 17.
Ejecute el comando siguiente para cada extensión que utilice:
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
Para obtener más información, consulte [Actualización de las extensiones de PostgreSQL en bases de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md). Para obtener más información acerca de la actualización de PostGIS, consulte [Paso 6: Actualice la extensión de PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update).
1. **Elimine determinadas extensiones antes de la actualización de la versión principal**: las extensiones que no sean compatibles con la versión de destino deben eliminarse, ya que, de lo contrario, la actualización fallará.
La extensión `plrust` se elimina a partir de la versión 18 de RDS PostgreSQL. La extensión `postgis_topology` no está disponible en las versiones 18.1 y 18.2 de RDS PostgreSQL debido a problemas conocidos [[1](https://trac.osgeo.org/postgis/ticket/5983)], [[2](https://trac.osgeo.org/postgis/ticket/6016)]. Estas extensiones deben eliminarse antes de realizar la actualización.
Una actualización que omite una versión principal y pasa directamente a la versión 11.x no admite la actualización de la extensión `pgRouting`. La actualización de las versiones 9.4.x, 9.5.x o 9.6.x a las versiones 11.x omite una versión principal. Es seguro eliminar la extensión `pgRouting` y, a continuación, volver a instalarla en una versión compatible después de la actualización. Para conocer las versiones de extensión que puede actualizar, consulte [Versiones de extensiones de PostgreSQL compatibles](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
Las extensiones `tsearch2` y `chkpass` ya no se admiten para PostgreSQL versiones 11 o posteriores.
Puede comprobar si una extensión está instalada con la siguiente consulta:
```
SELECT * FROM pg_extension WHERE extname in ('extension_name');
```
1. **Elimine los tipos de datos desconocidos**: elimine los tipos de datos `unknown` según la versión de destino.
En la versión 10 de PostgreSQL se dejo de admitir el tipo de datos `unknown`. Si una base de datos de versión 9.6 utiliza el tipo de datos `unknown`, una actualización a una versión 10 muestra un mensaje de error como el siguiente:
```
Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."
```
Para buscar el tipo de datos `unknown` en la base de datos de modo que pueda eliminar la columna problemática o cambiarla a un tipo de datos compatible, utilice el siguiente SQL:
```
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
```
1. **Ejecute un simulacro de actualización**: es muy recomendable probar la actualización de versión principal en un duplicado de la base de datos de producción antes de intentar llevarla a cabo en la base de datos de producción. Puede monitorizar los planes de ejecución de la base de datos de prueba duplicada para detectar posibles regresiones del plan de ejecución y evaluar su rendimiento. Para crear una instancia de prueba duplicada, puede restaurar su base de datos a partir de una instantánea reciente o realizar una restauración de un momento dado de su base de datos en el último momento que se pueda restaurar.
Para obtener más información, consulte [Restauración a partir de una instantánea](USER_RestoreFromSnapshot.md#USER_RestoreFromSnapshot.Restoring) o [Restauración de una instancia de base de datos a un momento especificado para Amazon RDS](USER_PIT.md). Para los clústeres de base de datos Multi-AZ, consulte [Restauración de una instantánea de clúster de base de datos Multi-AZ](USER_RestoreFromMultiAZDBClusterSnapshot.Restoring.md) o [Restauración de un clúster de base de datos Multi-AZ a un momento indicado](USER_PIT.MultiAZDBCluster.md).
Para obtener información detallada sobre la realización de la actualización, consulte [Actualización manual de la versión del motor](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
Al actualizar una base de datos de la versión 9.6 a la versión 10, tenga en cuenta que PostgreSQL 10 habilita consultas paralelas de forma predeterminada. Para probar el impacto del paralelismo *antes* de la actualización, cambie el parámetro `max_parallel_workers_per_gather` de la base de datos de prueba a 2.
**nota**
El valor predeterminado del parámetro `max_parallel_workers_per_gather` del grupo de parámetros de base de datos `default.postgresql10` es 2.
Para más información, consulte [Parallel Query](https://www.postgresql.org/docs/10/parallel-query.html) (Consulta paralela) en la documentación de PostgreSQL. Para desactivar el paralelismo en la versión 10, establezca el parámetro `max_parallel_workers_per_gather` a 0.
Durante la actualización de la versión principal, se cambia temporalmente el nombre de las bases de datos `public` y `template1`, y del esquema `public` en todas las bases de datos. Estos objetos aparecen en los registros con su nombre original y una cadena aleatoria añadida. La cadena se añade de manera que ajustes personalizados, como `locale` y `owner`, se conserven durante la actualización de la versión principal. Cuando se complete la actualización, el nombre de los objetos se vuelve a cambiar al original.
**nota**
Durante el proceso de actualización a la versión principal, no puede realizar una restauración a un momento dado de la instancia de base datos o el clúster de base de datos Multi-AZ. Cuando Amazon RDS finaliza la actualización, realiza una copia de seguridad automática de la base de datos. Puede realizar una restauración a momentos anteriores al inicio de la actualización y posteriores a la finalización que la copia de seguridad automática de la base de datos.
1. **Si una actualización devuelve un error de procedimiento de comprobación previa**: durante el proceso de actualización de versión principal, Amazon RDS for PostgreSQL primero ejecuta un procedimiento de comprobación previa para identificar algún problema que pueda provocar un error de actualización. El procedimiento de comprobación previa comprueba todas las posibles condiciones incompatibles en todas las bases de datos en la instancia.
Si la comprobación previa encuentra un error, crea un evento de registro que indica que se ha producido un error en la comprobación previa de actualización. Los detalles del proceso de comprobación previa están en un registro de actualización denominado `pg_upgrade_precheck.log` para todas las bases de datos de una base de datos. Amazon RDS agrega una marca temporal al nombre de archivo. Para obtener más información acerca de cómo visualizar los archivos de registro, consulte [Supervisión de archivos de registro de Amazon RDS](USER_LogAccess.md).
Si una actualización de réplica de lectura falla en la comprobación previa, la replicación en la réplica de lectura fallida se rompe y la réplica de lectura se pone en estado terminado. Elimine la réplica de lectura y vuelva a crear una nueva réplica de lectura basada en la instancia de base de datos principal actualizada.
Resuelva todos los problemas identificados en el registro de comprobación previa y, a continuación, vuelva a intentar la actualización de versión principal. A continuación se muestra un ejemplo de un registro de comprobación previa.
```
------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.
* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.
* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].
* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.
```
1. **Si se produce un error en una actualización de réplica de lectura al actualizar la base de datos, resuelva el problema**: una réplica de lectura con error se coloca en el estado `incompatible-restore` y la replicación termina en la base de datos. Elimine la réplica de lectura y vuelva a crear una nueva réplica de lectura basada en la instancia de base de datos principal actualizada.
**nota**
Amazon RDS no actualiza réplicas de lectura de clústeres de base de datos Multi-AZ. Si actualiza la versión principal de un clúster de base de datos multi-AZ, el estado de replicación de las réplicas de lectura cambia a **terminado**.
Una actualización de réplica de lectura puede devolver un error por los siguientes motivos:
+ No se ha podido poner al día con la instancia de base de datos principal incluso después de un tiempo de espera.
+ Se encontraba en un estado de ciclo de vida de terminal o incompatible, como almacenamiento completo, restauración incompatible, etc.
+ Cuando se inició la actualización de la instancia de base de datos principal, había una actualización de versión secundaria independiente ejecutándose en la réplica de lectura.
+ La instancia de réplica de lectura utilizó parámetros incompatibles.
+ La réplica de lectura no ha podido comunicarse con la instancia de base de datos principal para sincronizar la carpeta de datos.
1. **Actualice su base de datos de producción**: si el simulacro de actualización de la versión principal se ha completado correctamente, debe poder actualizar su base de datos de producción con confianza. Para obtener más información, consulte [Actualización manual de la versión del motor](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual).
1. Ejecute la operación `ANALYZE` para actualizar la tabla `pg_statistic`. Debe hacerlo para cada base de datos en todas las bases de datos de PostgreSQL. Las estadísticas del optimizador no se transfieren durante una actualización de la versión principal, por lo que debe regenerar todas las estadísticas para evitar problemas de rendimiento. Ejecute el comando sin parámetros para generar estadísticas para todas las tablas normales de la base de datos actual, de la siguiente manera:
```
ANALYZE VERBOSE;
```
La marca `VERBOSE` es opcional, pero su uso muestra el progreso. Para obtener más información, consulte [ANALYZE](https://www.postgresql.org/docs/10/sql-analyze.html) en la documentación de PostgreSQL.
Al analizar tablas específicas en lugar de utilizar ANALYZE VERBOSE, ejecute el comando ANALYZE para cada tabla de la siguiente manera:
```
ANALYZE table_name;
```
En el caso de las tablas particionadas, analice siempre la tabla principal. Este proceso:
+ Muestra automáticamente ejemplos de las filas de todas las particiones.
+ Actualiza las estadísticas de cada partición de forma recursiva.
+ Mantiene las estadísticas de planificación esenciales en el nivel principal.
Aunque las tablas principales no almacenan datos reales, analizarlas es vital para la optimización de las consultas. La ejecución de ANALYZE solo en particiones individuales puede provocar un rendimiento deficiente de las consultas, ya que el optimizador no dispondrá de las estadísticas exhaustivas necesarias para una planificación eficiente entre todas las particiones.
**nota**
Ejecute ANALYZE en el sistema después de la actualización para evitar problemas de rendimiento.
Una vez completada una actualización de versión principal, le recomendamos lo siguiente:
+ Una actualización de PostgreSQL no actualiza ninguna extensión de PostgreSQL. Para actualizar extensiones, consulte [Actualización de las extensiones de PostgreSQL en bases de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
+ Como opción, utilice Amazon RDS para ver dos registros que produce la utilidad `pg_upgrade`. Estos son `pg_upgrade_internal.log` y `pg_upgrade_server.log`. Amazon RDS agrega una marca temporal al nombre de archivo de estos registros. Puede ver estos registros como cualquier otro registro. Para obtener más información, consulte [Supervisión de archivos de registro de Amazon RDS](USER_LogAccess.md).
También puede cargar los registros de actualización en registros de Amazon Cloudwatch. Para obtener más información, consulte [Publicación de registros de PostgreSQL en Amazon CloudWatch Logs](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs).
+ Para comprobar que todo funciona del modo previsto, pruebe su aplicación en la base de datos actualizada con una carga de trabajo similar. Cuando haya comprobado la actualización, podrá eliminar esta instancia de prueba.
# Actualizaciones de versiones secundarias automáticas de RDS para PostgreSQL
Si habilita la opción **Actualización automática de versiones secundarias** al crear o modificar una instancia de base de datos o un clúster de base de datos Multi-AZ, puede hacer que la base de datos se actualice automáticamente.
Amazon RDS también admite la política de implementación de actualizaciones para administrar las actualizaciones automáticas de versiones secundarias en varios recursos de bases de datos y Cuentas de AWS. Para obtener más información, consulte [Uso de la política de implementación de actualizaciones de AWS Organizations para actualizaciones de versiones secundarias automáticas](RDS.Maintenance.AMVU.UpgradeRollout.md).
RDS asigna una versión secundaria como la versión de actualización automática para cada versión principal de RDS for PostgreSQL. Después de que Amazon RDS pruebe y apruebe una versión secundaria, la actualización de versión secundaria se produce automáticamente durante el periodo de mantenimiento. RDS no configura automáticamente versiones secundarias publicadas recientemente como la versión de actualización automática. Antes de que RDS asigne una versión de actualización automática más reciente, deben considerarse algunos criterios, como, por ejemplo, los que se indican a continuación:
+ Problemas de seguridad conocidos
+ Errores en la versión de la comunidad de PostgreSQL
+ Estabilidad general de la flota desde que se publicó la versión secundaria
Puede utilizar el siguiente comando de la AWS CLI para determinar la versión actual de destino de actualización secundaria automática para una versión secundaria de PostgreSQL especificada en una Región de AWS específica.
Para Linux, macOS o Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version minor-version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Para Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version minor-version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
Por ejemplo, el siguiente comando de la AWS CLI determina el destino de actualización secundaria automática para la versión secundaria 16.1 de PostgreSQL en la Región de AWS de Este de EE. UU. (Ohio) (us-east-2).
Para Linux, macOS o Unix:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Para Windows:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
Su resultado es similar al siguiente.
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| False | 16.2 |
| True | 16.3 |
| False | 16.4 |
| False | 16.5 |
| False | 16.6 |
| False | 17.1 |
| False | 17.2 |
+--------------+-----------------+
```
En este ejemplo, el valor `AutoUpgrade` es `True` para la versión 16.3 de PostgreSQL. Por lo tanto, el destino de actualización secundaria automática es la versión 16.3 de PostgreSQL, que está resaltado en el resultado.
Una base de datos de PostgreSQL se actualiza automáticamente durante el periodo de mantenimiento si se cumplen los siguientes criterios:
+ La base de datos tiene habilitada la **Actualización automática de versiones secundarias**.
+ La base de datos se ejecuta en una versión secundaria del motor de base de datos que es anterior a la versión secundaria de actualización automática actual.
Para obtener más información, consulte [Actualización automática de la versión secundaria del motor](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades).
**nota**
Una actualización de PostgreSQL no actualiza extensiones de PostgreSQL. Para actualizar extensiones, consulte [Actualización de las extensiones de PostgreSQL en bases de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
# Actualización de las extensiones de PostgreSQL en bases de datos de RDS para PostgreSQL
Una actualización del motor de PostgreSQL no actualiza la mayoría de las extensiones de PostgreSQL. Para actualizar una extensión después de una actualización de versiones, utilice el comando `ALTER EXTENSION UPDATE`.
**nota**
Para obtener información sobre la actualización de la extensión de PostGIS, consulte [Administración de datos espaciales con la extensión PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)([Paso 6: Actualice la extensión de PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)).
Para actualizar la extensión `pg_repack`, elimínela y, a continuación, cree la nueva versión en la base de datos actualizada. Para obtener más información, consulte [pg\$1repack installation](https://reorg.github.io/pg_repack/) (Instalación de pg\$1repack) en la documentación de `pg_repack`.
Para actualizar una extensión, utilice el siguiente comando.
```
ALTER EXTENSION extension_name UPDATE TO 'new_version';
```
Para consultar la lista de versiones compatibles de extensiones de PostgreSQL, vea [Versiones de extensiones de PostgreSQL compatibles](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md).
Para enumerar las extensiones instaladas actualmente, utilice el catálogo [pg\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) de PostgreSQL en el siguiente comando.
```
SELECT * FROM pg_extension;
```
Para ver una lista de las versiones específicas de la extensión que están disponibles para su instalación, utilice la visualización [ pg\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) de PostgreSQL en el siguiente comando.
```
SELECT * FROM pg_available_extension_versions;
```
# Supervisión de las actualizaciones del motor de RDS para PostgreSQL con eventos
Cuando se actualiza la versión del motor de una base de datos de RDS para PostgreSQL, Amazon RDS emite un evento específico durante cada fase del proceso. Para realizar un seguimiento del progreso de una actualización, puede ver estos eventos o suscribirse a ellos.
Para obtener más información sobre los eventos de RDS, consulte [Supervisión de eventos de Amazon RDS](working-with-events.md).
Para obtener información detallada sobre un evento específico de Amazon RDS que se produce durante la actualización del motor, consulte [Categorías y mensajes de eventos de Amazon RDS ](USER_Events.Messages.md).
# Actualización de una versión del motor de instantáneas de base de datos de PostgreSQL
Con Amazon RDS, puede crear una instantánea de base de datos de volumen de almacenamiento de su instancia de base de datos de PostgreSQL. Cuando se crea una instantánea de base de datos, se basa en la versión del motor empleada por la instancia de Amazon RDS. Puede actualizar la versión del motor para las instantáneas de base de datos.
Después de restaurar una instantánea de base de datos actualizada a una nueva versión del motor, asegúrese que la actualización se ha realizado correctamente. Para obtener más información acerca de una actualización de versión principal, consulte [Actualizaciones del motor de base de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md). Para aprender a restaurar una instantánea de base de datos, consulte [Restauración a una instancia de base de datos](USER_RestoreFromSnapshot.md).
Puede actualizar las instantáneas de base de datos manuales que están cifradas o no.
Para ver las versiones de motor disponibles para la instantánea de base de datos de RDS para PostgreSQL, utilice el siguiente ejemplo de AWS CLI.
```
aws rds describe-db-engine-versions --engine postgres --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text --include-all
```
Para obtener más información sobre las versiones de motor disponibles para las instantáneas de base de datos de RDS para PostgreSQL, consulte [Elección de una versión principal para una actualización de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
**nota**
No puede actualizar las instantáneas de base de datos automatizadas que se creen durante el proceso de backup automatizado.
## Consola
**Para actualizar una instantánea de base de datos**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija **Snapshots (Instantáneas)**.
1. Elija la instantánea que desea actualizar.
1. En **Actions (Acciones)**, seleccione **Upgrade Snapshot (Actualizar instantánea)**. Aparece la página **Upgrade snapshot**.
1. Elija la **New engine version (Nueva versión del motor)** a la que actualizarse.
1. Elija **Save changes (Guardar cambios)** para actualizar la instantánea.
Durante el proceso de actualización, todas las acciones están deshabilitadas para esta instantánea de base de datos. Además, el estado de la instantánea de base de datos cambia de **available** a **upgrading** y después cambia a **active** al completarse. Si la instantánea de base de datos no se puede actualizar porque se ha dañado, el estado cambia a **unavailable**. No puede recuperar el snapshot desde este estado.
**nota**
Si la actualización de la base de datos falla, la instantánea se revierte al estado original con la versión original.
## AWS CLI
Para actualizar una instantánea de base de datos a una nueva versión del motor de base de datos, use el comando [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html) de la AWS CLI.
**Parameters**
+ `--db-snapshot-identifier`: identificador de la instantánea de base de datos que se va a actualizar. El identificador debe ser un Nombre de recurso de Amazon (ARN). Para obtener más información, consulte [Nombres de recursos de Amazon (ARN) en Amazon RDS](USER_Tagging.ARN.md).
+ `--engine-version`: versión del motor a la que se va a actualizar la instantánea de base de datos.
**Example**
Para Linux, macOS o Unix:
```
1. aws rds modify-db-snapshot \
2. --db-snapshot-identifier my_db_snapshot \
3. --engine-version new_version
```
Para Windows:
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
## API de RDS
Para actualizar una instantánea de base de datos a una nueva versión del motor de base de datos, llame a la operación [ ModifyDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) de la API de Amazon RDS.
+ `DBSnapshotIdentifier`: identificador de la instantánea de base de datos que se va a actualizar. El identificador debe ser un Nombre de recurso de Amazon (ARN). Para obtener más información, consulte [Nombres de recursos de Amazon (ARN) en Amazon RDS](USER_Tagging.ARN.md).
+ `EngineVersion`: versión del motor a la que se va a actualizar la instantánea de base de datos.
# Uso de réplicas de lectura para Amazon RDS para PostgreSQL
Puede escalar las lecturas de sus instancias de base de datos de Amazon RDS para PostgreSQL añadiendo réplicas de lectura a las instancias. Al igual que con otros motores de bases de datos de Amazon RDS, RDS para PostgreSQL utiliza los mecanismos de replicación nativos de PostgreSQL para mantener las réplicas de lectura actualizadas con los cambios en la base de datos de origen. Para obtener información general acerca de las réplicas y Amazon RDS, consulte [Trabajo con réplicas de lectura de instancias de base de datos](USER_ReadRepl.md).
A continuación, encontrará información específica sobre cómo utilizar réplicas de lectura con RDS para PostgreSQL.
## Limitaciones de las réplicas de lectura con PostgreSQL
A continuación se indican las limitaciones de las réplicas de lectura de PostgreSQL:
+ Las réplicas de lectura de PostgreSQL son de solo lectura. Aunque una réplica de lectura no es una instancia de base de datos grabable, puede promocionarla para que se convierta en un RDS independiente para una instancia de base de datos de PostgreSQL. Sin embargo, el proceso no es reversible.
+ No puede crear una réplica de lectura a partir de otra réplica de lectura si su instancia de base de datos de RDS para PostgreSQL ejecuta una versión de PostgreSQL anterior a la 14.1. RDS para PostgreSQL solo admite réplicas de lectura en cascada en RDS para PostgreSQL versión 14.1 y versiones superiores. Para obtener más información, consulte [Uso de réplicas de lectura en cascada con RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Si promociona una réplica de lectura de PostgreSQL, se convierte en una instancia de base de datos grabable. Deja de recibir archivos de write-ahead log (WAL, registro de escritura anticipada) de una instancia de base de datos de origen y ya no es una instancia de solo lectura. Puede crear nuevas réplicas de lectura a partir de la instancia de base de datos promocionada como lo hace para cualquier instancia de base de datos de RDS para PostgreSQL. Para obtener más información, consulte [Promoción de una réplica de lectura para convertirla en una instancia de base de datos independiente](USER_ReadRepl.Promote.md).
+ Si promociona una réplica de lectura de PostgreSQL desde una cadena de replicación (una serie de réplicas de lectura en cascada), cualquier réplica de lectura descendente existente continúa recibiendo archivos WAL de la instancia promocionada, automáticamente. Para obtener más información, consulte [Uso de réplicas de lectura en cascada con RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Si no se están ejecutando transacciones de usuario en la instancia de base de datos de origen, la réplica de lectura de PostgreSQL asociada registra un retardo de replicación de hasta cinco minutos. El retraso de la réplica se calcula como `currentTime - lastCommitedTransactionTimestamp`, lo que significa que cuando no se procesan transacciones, el valor del retraso de la réplica aumenta durante un período de tiempo hasta que cambia el segmento del registro de escritura anticipada (WAL). De forma predeterminada, RDS para PostgreSQL cambia el segmento WAL cada 5 minutos, lo que da como resultado un registro de transacciones y una disminución del retardo comunicado.
+ No puede activar las copias de seguridad automatizadas para las réplicas de lectura de RDS para PostgreSQL de versiones anteriores a 14.1. Las copias de seguridad automatizadas para réplicas de lectura se admiten únicamente para RDS para PostgreSQL 14.1 y versiones posteriores. Para RDS para PostgreSQL 13 y versiones anteriores, cree una instantánea a partir de una réplica de lectura si desea realizar una copia de seguridad de ella.
+ La Point-in-time recovery (PITR, recuperación en un momento dado) no se admite para las réplicas de lectura. Puede utilizar PITR solo con una instancia principal (escritor), no con una réplica de lectura. Para obtener más información, consulte [Restauración de una instancia de base de datos a un momento especificado para Amazon RDS](USER_PIT.md).
+ Las réplicas de lectura para las versiones 12 y menores de PostgreSQL se reinician automáticamente durante el periodo de mantenimiento de 60 a 90 días para aplicar la rotación de contraseñas. Si la réplica pierde conexión al origen antes del reinicio programado, seguirá reiniciándose para que se reanude la replicación. Para las versiones 13 y superiores de PostgreSQL, las réplicas de lectura pueden sufrir breves desconexiones y reconexiones de replicación durante el proceso de rotación de contraseñas.
# Configuración de réplicas de lectura con PostgreSQL
RDS para PostgreSQL utiliza la replicación de streaming nativa de PostgreSQL para crear una copia de solo lectura de una instancia de base de datos de origen. La instancia de base de datos de réplica de lectura es una réplica física de la instancia de la base de datos de origen creada de forma asíncrona. Se crea mediante una conexión especial que transmite los datos de los registros de escritura previa (WAL) entre la instancia de base de datos de origen y la réplica de lectura. Para obtener más información, consulte [Replicación de streaming](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) en la documentación de PostgreSQL.
PostgreSQL transmite de forma asíncrona los cambios de la base de datos a esta conexión segura a medida que se realizan en la instancia de base de datos de origen. Puede cifrar las comunicaciones de las aplicaciones cliente a la instancia de base de datos de origen o cualquier réplica de lectura configurando el parámetro `ssl` en `1`. Para obtener más información, consulte [Uso de SSL con una instancia de base de datos PostgreSQL](PostgreSQL.Concepts.General.SSL.md) .
PostgreSQL usa un rol de *replicación* para realizar la replicación en streaming. El rol tiene privilegios, pero no se puede usar para modificar ningún dato. PostgreSQL usa un único proceso para gestionar la replicación.
Puede crear una réplica de lectura de PostgreSQL sin que afecte a las operaciones o usuarios de la instancia de base de datos de origen. Amazon RDS establece los parámetros y los permisos necesarios en la instancia de base de datos de origen y la réplica de lectura sin que afecte al servicio. Se toma una instantánea de la instancia de base de datos de origen, y esta instantánea se utiliza para crear la réplica de lectura. Si elimina la réplica de lectura en algún momento futuro, no se produce ninguna interrupción.
Puede crear hasta 15 réplicas de lectura a partir de una instancia de base de datos de origen dentro de la misma región. A partir de RDS para PostgreSQL 14.1, también puede crear hasta tres niveles de réplica de lectura en una cadena (cascada) a partir de una instancia de base de datos de origen. Para obtener más información, consulte [Uso de réplicas de lectura en cascada con RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). En todos los casos, la instancia de base de datos de origen debe tener configuradas copias de seguridad automatizadas. Para ello, debe establecer el periodo de retención de copia de seguridad en su instancia de base de datos en cualquier valor distinto de 0. Para obtener más información, consulte [Creación de una réplica de lectura](USER_ReadRepl.Create.md).
Puede crear réplicas de lectura para su instancia de base de datos de RDS para PostgreSQL en la misma Región de AWS que la instancia de base de datos de origen. Esto se denomina replicación *dentro de la región*. También puede crear réplicas de lectura en una Regiones de AWS diferente de la instancia de base de datos de origen. Esto se denomina replicación *entre regiones*. Para obtener información sobre la configuración de réplicas de lectura entre regiones, consulte [Creación de una réplica de lectura en una distinta Región de AWS](USER_ReadRepl.XRgn.md). Los diversos mecanismos que admiten el proceso de replicación para dentro de la región y entre regiones difieren ligeramente en función de la versión de RDS para PostgreSQL, como se explica en [Cómo funciona la replicación de streaming en diferentes versiones de RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md).
Para que la replicación sea eficaz, cada réplica de lectura debe tener la misma cantidad de recursos de computación y de almacenamiento que la instancia de base de datos de origen. Si modifica la escala de la instancia de base de datos de origen, asegúrese de ajustar también la escala de las réplicas de lectura.
Amazon RDS anula los parámetros incompatibles de una réplica de lectura si impiden que la réplica de lectura se inicie. Por ejemplo, supongamos que el valor del parámetro `max_connections` es mayor en la instancia de base de datos de origen que en la réplica de lectura. En ese caso, Amazon RDS actualiza el parámetro en la réplica de lectura para que tenga el mismo valor que el de la instancia de base de datos de origen.
Las réplicas de lectura de RDS para PostgreSQL tienen acceso a bases de datos externas que están disponibles a través de foreign data wrappers (FDW, envoltorios de datos externos) en la instancia de base de datos de origen. Por ejemplo, suponga que su instancia de base de datos de RDS para PostgreSQL utiliza el envoltorio `mysql_fdw` para acceder a los datos de RDS para MySQL. Si es así, las réplicas de lectura también pueden acceder a esos datos. Otros FDW admitidos incluyen `oracle_fdw`, `postgres_fdw` y `tds_fdw`. Para obtener más información, consulte [Uso de los contenedores de datos externos compatibles para Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
## Uso de RDS para réplicas de lectura de PostgreSQL con configuraciones Multi-AZ
Puede crear una réplica de lectura a partir de una instancia de base de datos Single-AZ o Multi-AZ. Puede utilizar implementaciones Multi-AZ para mejorar la durabilidad y la disponibilidad de los datos críticos, con una réplica en espera. Una *réplica en espera* es una réplica de lectura dedicada que puede asumir la carga de trabajo si la base de datos de origen falla. No puede usar su réplica en espera para servir tráfico de lectura. Sin embargo, puede crear réplicas de lectura a partir de una instancia de base de datos Multi-AZ con un tráfico elevado para descargar las consultas de solo lectura. Para obtener más información sobre las implementaciones Multi-AZ, consulte [Habilitación de implementaciones de instancias de bases de datos multi-AZ para Amazon RDS](Concepts.MultiAZSingleStandby.md).
Si la instancia de base de datos de origen de una implementación Multi-AZ conmuta por error, las réplicas de lectura asociadas cambian para utilizar la instancia en espera (ahora principal) como origen de replicación. Es posible que las réplicas de lectura deban reiniciarse, según la versión de RDS para PostgreSQL, de la siguiente manera:
+ **PostgreSQL 13 y versiones superiores**: no es obligatorio reiniciar. Las réplicas de lectura se sincronizan automáticamente con el nuevo elemento principal. Sin embargo, en algunos casos, la aplicación cliente podría almacenar en caché los detalles del Domain Name Service (DNS, servicio de nombres de dominio) de las réplicas de lectura. Si es así, configure el valor de time-to-live (TTL, tiempo de vida) en menos de 30 segundos. Esto impide que la réplica de lectura se mantenga en una dirección IP obsoleta (y, por lo tanto, impide que se sincronice con el nuevo elemento principal). Para obtener más información sobre esta y otras prácticas recomendadas, consulte [Directrices operativas básicas de Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).
+ **PostgreSQL 12 y todas las versiones anteriores**: las réplicas de lectura se reinician automáticamente después de una conmutación por error en la réplica en espera porque la espera (ahora principal) tiene una dirección IP y un nombre de instancia diferente. El reinicio sincroniza la réplica de lectura con el nuevo elemento principal.
Para obtener más información sobre la conmutación por error, consulte [Conmutación por error de una instancia de base de datos multi-AZ para Amazon RDS](Concepts.MultiAZ.Failover.md). Para obtener más información sobre cómo funcionan las réplicas de lectura en una implementación Multi-AZ, consulte [Trabajo con réplicas de lectura de instancias de base de datos](USER_ReadRepl.md).
Para proporcionar soporte de conmutación por error para una réplica de lectura, puede crear la réplica de lectura como una instancia de base de datos Multi-AZ para que Amazon RDS cree una espera de su réplica en otra zona de disponibilidad (AZ). La creación de su réplica de lectura como instancia de base de datos Multi-AZ es independiente de si la base de datos de origen es una instancia de base de datos Multi-AZ.
# Decodificación lógica en una réplica de lectura
RDS para PostgreSQL admite la replicación lógica desde instancias en espera con PostgreSQL 16.1. Esto le permite crear una decodificación lógica desde una instancia en espera de solo lectura, lo que reduce la carga de la instancia de base de datos principal. Puede lograr una mayor disponibilidad para las aplicaciones que necesitan sincronizar datos en varios sistemas. Esta característica aumenta el rendimiento del almacenamiento de datos y del análisis de datos.
Además, las ranuras de replicación de una instancia en espera determinada mantienen la promoción de esa instancia en espera a una principal. Esto significa que, en caso de que se produzca una conmutación por error de una instancia de base de datos principal o de que se promueva una instancia en espera para ser la nueva instancia principal, las ranuras de replicación se mantendrán y los suscriptores en espera anteriores no se verán afectados.
**Creación de una decodificación lógica en una réplica de lectura**
1. **Active la replicación lógica**: para crear una decodificación lógica en una instancia en espera, debe activar la replicación lógica en la instancia de base de datos de origen y en su réplica física. Para obtener más información, consulte [Configuración de réplicas de lectura con PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md).
+ **Para activar la replicación lógica de una instancia de base de datos de RDS para PostgreSQL recién creada**: cree un nuevo grupo de parámetros personalizados de base de datos y establezca el parámetro estático `rds.logical_replication` en `1`. A continuación, asocie este grupo de parámetros de base de datos a la instancia de base de datos de origen y a su réplica de lectura física. Para obtener más información, consulte [Asociación de un grupo de parámetros de base de datos con una instancia de base de datos en Amazon RDS](USER_WorkingWithParamGroups.Associating.md).
+ **Para activar la replicación lógica de una instancia de base de datos de RDS para PostgreSQL existente**: modifique el grupo de parámetros personalizados de base de datos de la instancia de base de datos de origen y su réplica de lectura física para establecer el parámetro estático `rds.logical_replication` en `1`. Para obtener más información, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**nota**
Debe reiniciar las instancias de base de datos para aplicar estos cambios en los parámetros.
Puede utilizar la siguiente consulta para comprobar los valores de `wal_level` y `rds.logical_replication` en la instancia de base de datos de origen y su réplica de lectura física.
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **Cree una tabla en la base de datos de origen**: conéctese a la base de datos de su instancia de base de datos de origen. Para obtener más información, consulte [Conexión a una instancia de base de datos que ejecuta el motor de base de datos de PostgreSQL](USER_ConnectToPostgreSQLInstance.md).
Utilice las siguientes consultas para crear una tabla en la base de datos de origen e insertar valores:
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **Cree una publicación para la tabla de origen**: utilice la siguiente consulta para crear una publicación para la tabla en la instancia de base de datos de origen.
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
Utilice una consulta SELECT para comprobar los detalles de la publicación que se creó tanto en la instancia de base de datos de origen como en la instancia de réplica de lectura física.
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **Cree una suscripción a partir de una instancia de réplica lógica**: cree otra instancia de base de datos de RDS para PostgreSQL como instancia de réplica lógica. Asegúrese de que la VPC esté configurada correctamente para garantizar que esta instancia de réplica lógica pueda acceder a la instancia de réplica de lectura física. Para obtener más información, consulte [VPC de Amazon y Amazon RDS](USER_VPC.md). Si la instancia de base de datos de origen está inactiva, es posible que se produzcan problemas de conectividad y que la instancia principal no envíe los datos a la instancia en espera.
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
Utilice una consulta SELECT para comprobar los detalles de la suscripción en la instancia de la réplica lógica.
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **Inspeccione el estado de la ranura de replicación lógica**: solo puede ver la ranura de replicación física en la instancia de base de datos de origen.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
Sin embargo, en la instancia de la réplica de lectura, puede ver la ranura de replicación lógica y el valor de `confirmed_flush_lsn` cambia a medida que la aplicación consume activamente los cambios lógicos.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# Uso de réplicas de lectura en cascada con RDS para PostgreSQL
A partir de la versión 14.1, RDS para PostgreSQL admite réplicas de lectura en cascada. Con *réplicas de lectura en cascada*, puede escalar las lecturas sin agregar sobrecarga a su instancia de base de datos de RDS para PostgreSQL de origen. La instancia de base de datos de origen no envía las actualizaciones del registro WAL a cada réplica de lectura. En cambio, cada réplica de lectura de una serie en cascada envía actualizaciones de registro WAL a la siguiente réplica de lectura de la serie. Esto reduce la carga de la instancia de base de datos de origen.
Con réplicas de lectura en cascada, la instancia de base de datos de RDS para PostgreSQL envía datos WAL a la primera réplica de lectura de la cadena. Esa réplica de lectura envía datos WAL a la segunda réplica de la cadena, etc. El resultado final es que todas las réplicas de lectura de la cadena tienen los cambios de la instancia de base de datos de RDS para PostgreSQL, pero sin la sobrecarga únicamente en la instancia de base de datos de origen.
Puede crear una serie de hasta tres réplicas de lectura en cadena a partir de una instancia de base de datos RDS para PostgreSQL de origen. Por ejemplo, suponga que tiene una instancia de base de datos de RDS para PostgreSQL 14.1, `rpg-db-main`. Se puede hacer lo siguiente:
+ A partir de `rpg-db-main`, cree la primera réplica de lectura de la cadena, `read-replica-1`.
+ A continuación, a partir de `read-replica-1`, cree la siguiente réplica de lectura de la cadena, `read-replica-2`.
+ Por último, a partir de `read-replica-2`, cree la tercera réplica de lectura de la cadena, `read-replica-3`.
No se puede crear otra réplica de lectura más allá de esta tercera réplica de lectura en cascada de la serie para `rpg-db-main`. Una serie completa de instancias desde una instancia de base de datos de origen de RDS para PostgreSQL hasta el final de una serie de réplicas de lectura en cascada puede constar de cuatro instancias de base de datos como máximo.
Para que las réplicas de lectura en cascada funcionen, active las copias de seguridad automáticas en su RDS para PostgreSQL. Cree primero la réplica de lectura y, a continuación, active las copias de seguridad automáticas en la instancia de base de datos de RDS para PostgreSQL. El proceso es el mismo que para otros motores de base de datos de Amazon RDS. Para obtener más información, consulte [Creación de una réplica de lectura](USER_ReadRepl.Create.md).
Al igual que con cualquier réplica de lectura, puede promocionar una réplica de lectura que forma parte de una cascada. La promoción de una réplica de lectura desde dentro de una cadena de réplicas de lectura elimina esa réplica de la cadena. Por ejemplo, suponga que desea quitar parte de la carga de trabajo de su Instancia de base de datos de `rpg-db-main` a una nueva instancia para que la utilice únicamente el departamento de contabilidad. Tomando la cadena de tres réplicas de lectura del ejemplo, decide promocionar `read-replica-2`. La cadena se ve afectada de la siguiente manera:
+ Promover `read-replica-2` la elimina de la cadena de replicación.
+ Ahora es una instancia de base de datos de lectura o escritura completa.
+ Continúa replicando en `read-replica-3`, tal como hacía antes de la promoción.
+ Su `rpg-db-main` sigue replicándose en `read-replica-1`.
Para obtener más información acerca de la promoción de réplicas de lectura, consulte [Promoción de una réplica de lectura para convertirla en una instancia de base de datos independiente](USER_ReadRepl.Promote.md).
**nota**
RDS para PostgreSQL no admite actualizaciones de versiones principales para réplicas en cascada. Antes de realizar una actualización de versión principal, debe eliminar las réplicas en cascada. Puede volver a crearlas después de completar la actualización en la instancia de base de datos de origen y en las réplicas de primer nivel.
Para las réplicas de lectura en cascada, RDS para PostgreSQL admite 15 réplicas de lectura para cada instancia de base de datos de origen en el primer nivel de replicación y 5 réplicas de lectura para cada instancia de base de datos de origen en el segundo y tercer nivel de replicación.
# Creación de réplicas de lectura en cascada entre regiones con RDS para PostgreSQL
RDS para PostgreSQL admite las réplicas de lectura en cascada entre regiones. Puede crear una réplica entre regiones a partir de la instancia de base de datos de origen y, a continuación, crear réplicas de la misma región a partir de ella. Puede crear una réplica de la misma región a partir de la instancia de base de datos de origen y, a continuación, crear réplicas entre regiones a partir de ella.
**Creación de una réplica entre regiones y, a continuación, de réplicas de la misma región**
Puede usar una instancia de base de datos de RDS para PostgreSQL con la versión 14.1 o superior, `rpg-db-main`, para hacer lo siguiente:
1. Comience con `rpg-db-main` (US-EAST-1) y cree la primera réplica de lectura entre regiones de la cadena, `read-replica-1` (US-WEST-2).
1. Con la primera `read-replica-1` (US-WEST-2) entre regiones, cree la segunda réplica de lectura en la cadena, `read-replica-2` (US-WEST-2).
1. Con `read-replica-2`, cree la tercera réplica de lectura de la cadena, `read-replica-3` (US-WEST-2).
**Creación de una réplica de la misma región y, a continuación, de réplicas entre regiones**
Puede usar una instancia de base de datos de RDS para PostgreSQL con la versión 14.1 o superior, `rpg-db-main`, para hacer lo siguiente:
1. Comience con `rpg-db-main` (US-EAST-1) y cree la primera réplica de lectura en la cadena, `read-replica-1` (US-EAST-1).
1. Con `read-replica-1` (US-EAST-1), cree la primera réplica de lectura entre regiones de la cadena, `read-replica-2` (US-WEST-2).
1. Con `read-replica-2` (US-WEST-2), cree la tercera réplica en la cadena, `read-replica-3` (US-WEST-2).
**Limitaciones en la creación de réplicas de lectura entre regiones**
+ Una cadena en cascada de réplicas de bases de datos entre regiones puede abarcar un máximo de dos regiones, con un máximo de cuatro niveles. Los cuatro niveles incluyen el origen de la base de datos y tres réplicas de lectura.
**Ventajas de usar réplicas de lectura en cascada**
+ Escalabilidad de lectura mejorada: al distribuir las consultas de lectura entre varias réplicas, la replicación en cascada contribuye a equilibrar la carga. Esto mejora el rendimiento, sobre todo en aplicaciones de lectura intensiva, al reducir la tensión en la base de datos del escritor.
+ Distribución geográfica: las réplicas en cascada se pueden colocar en diferentes ubicaciones geográficas. Esto reduce la latencia de los usuarios que se encuentran lejos de la base de datos principal y proporciona una réplica de lectura local, lo que mejora el rendimiento y la experiencia del usuario.
+ Alta disponibilidad y recuperación de desastres: en caso de que se produzca un fallo en el servidor principal, las réplicas se pueden convertir en principales, lo que garantiza la continuidad. La replicación en cascada mejora aún más esta situación, ya que proporciona varios niveles de opciones de conmutación por error, lo que mejora la resiliencia general del sistema.
+ Flexibilidad y crecimiento modular: a medida que el sistema crece, se pueden agregar nuevas réplicas en diferentes niveles sin necesidad de una reconfiguración importante de la base de datos principal. Este enfoque modular permite un crecimiento escalable y administrable de la configuración de replicación.
**Práctica recomendada para usar réplicas de lectura entre regiones**
+ Antes de promocionar una réplica, cree réplicas adicionales. Esto ahorrará tiempo y proporcionará un manejo eficiente de la carga de trabajo.
# Cómo funciona la replicación de streaming en diferentes versiones de RDS para PostgreSQL
Como se discute en [Configuración de réplicas de lectura con PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md), RDS para PostgreSQL utiliza el protocolo de replicación de streaming nativo de PostgreSQL para enviar datos WAL desde la instancia de base de datos de origen. Envía datos WAL de origen a réplicas de lectura tanto para réplicas de lectura dentro de la región como entre regiones. Con la versión 9.4, PostgreSQL introdujo slots de replicación física como mecanismo de soporte para el proceso de replicación.
Una *slot de replicación física* impide que una instancia de base de datos de origen elimine los datos WAL antes de que todas las réplicas de lectura los consuman. Cada réplica de lectura tiene su propia slot física en la instancia de base de datos de origen. La slot realiza un seguimiento del WAL más antiguo (por número de secuencia lógica, LSN) que podría necesitar la réplica. Después de que todas las slots y conexiones de base de datos hayan progresado más allá de un WAL (LSN) determinado, ese LSN se convierte en candidato para su eliminación en el siguiente punto de control.
Amazon RDS utiliza Amazon S3 para archivar datos WAL. En las réplicas de lectura dentro de la región, puede utilizar estos datos archivados para recuperar la réplica de lectura cuando sea necesario. Un ejemplo de cuándo podría hacerse es si la conexión entre la base de datos de origen y la réplica de lectura se interrumpe por cualquier motivo.
En la tabla siguiente, encontrará un resumen de las diferencias entre las versiones de PostgreSQL y los mecanismos de soporte para dentro de la región y entre regiones que utiliza RDS para PostgreSQL.
| Versión | En región | Entre regiones |
| --- | --- | --- |
| PostgreSQL 14.1 y versiones posteriores | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 y versiones anteriores | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
Para obtener más información, consulte [Supervisión y ajuste del proceso de replicación](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md).
## Descripción de los parámetros que controlan la replicación de PostgreSQL
Los siguientes parámetros afectan al proceso de replicación y determinan qué tal se actualizan las réplicas de lectura con la instancia de base de datos de origen:
**max\$1wal\$1senders**
El parámetro `max_wal_senders` especifica el número máximo de conexiones que la instancia de base de datos de origen puede admitir al mismo tiempo a través del protocolo de replicación de streaming.
El valor predeterminado varía para las versiones de RDS para PostgreSQL:
+ Para las versiones 13, 14 y 15, el valor predeterminado es 20.
+ Para las versiones 16 y posteriores, el valor predeterminado es 35.
Este parámetro debe establecerse en ligeramente superior al número real de réplicas de lectura. Si este parámetro se establece demasiado bajo para el número de réplicas de lectura, la replicación se detiene.
Para obtener más información, consulte [see max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) enla documentación de PostgreSQL.
`max_wal_senders` es un parámetro estático que requiere un reinicio de la instancia de base de datos para que los cambios surtan efecto.
**wal\$1keep\$1segments**
El parámetro `wal_keep_segments` especifica el número de archivos de registro de escritura anticipada (WAL) que mantiene la instancia de base de datos de origen en el directorio `pg_wal`. La configuración predeterminada es 32.
Si `wal_keep_segments` no tiene un valor lo suficientemente grande para su implementación, una réplica de lectura puede quedarse tan rezagada que se detenga la replicación en streaming. Si es así, Amazon RDS genera un error de replicación e inicia la recuperación en la réplica de lectura. Para ello, reproduce los datos WAL archivados de la instancia de base de datos de origen desde Amazon S3. Este proceso de recuperación continúa hasta que la réplica de lectura reduce el retraso lo suficiente para seguir con la replicación en streaming. Puede ver este proceso en acción tal como lo captó el registro de PostgreSQL en [Ejemplo: Cómo se recupera una réplica de lectura de las interrupciones de la replicaciónEjemplo: Recuperación de una réplica de lectura de las interrupciones de la replicación](#USER_PostgreSQL.Replication.example-how-it-works).
En la versión 13 de PostgreSQL, el parámetro `wal_keep_segments` se denomina `wal_keep_size`. Tiene el mismo propósito que `wal_keep_segments`, pero su valor predeterminado está en megabytes (MB) (2048 MB) en lugar del número de archivos. Para obtener más información, consulte [wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) y [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) en la documentación de PostgreSQL.
**max\$1slot\$1wal\$1keep\$1size**
El parámetro `max_slot_wal_keep_size` controla la cantidad de datos WAL que conserva la instancia de base de datos de RDS para PostgreSQL en el directorio `pg_wal` para servir slots. Este parámetro se utiliza para configuraciones que utilizan slots de replicación. El valor predeterminado para este parámetro es `-1`, lo que significa que no hay límite en cuanto a la cantidad de datos WAL que se conservan en la instancia de base de datos de origen. Para obtener información sobre cómo supervisar las slots de replicación, consulte [Supervisión de las slots de replicación de su instancia de base de datos de RDS para PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots).
Para obtener más información sobre este parámetro, consulte [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE) en la documentación de PostgreSQL.
Siempre que se interrumpe el flujo que proporciona los datos de WAL a una réplica de lectura, PostgreSQL cambia al modo de recuperación. Restaura la réplica de lectura mediante datos de WAL archivados de Amazon S3 o mediante el uso de datos de WAL asociados a la ranura de replicación. Cuando finaliza este proceso, PostgreSQL restablece la replicación en streaming.
### Ejemplo: Cómo se recupera una réplica de lectura de las interrupciones de la replicación
En el siguiente ejemplo, encontrará los detalles del registro que muestran el proceso de recuperación de una réplica de lectura. El ejemplo procede de una instancia de base de datos de RDS para PostgreSQL que ejecuta la versión 12.9 de PostgreSQL en la misma Región de AWS que la base de datos de origen, por lo que no se utilizan slots de replicación. El proceso de recuperación es el mismo para otras instancias de base de datos de PostgreSQL que ejecutan PostgreSQL anterior a la versión 14.1 con réplicas de lectura dentro de la región.
Cuando la réplica de lectura perdió el contacto con la instancia de base de datos de origen, Amazon RDS registra el problema en el registro como el mensaje `FATAL: could not receive data from WAL stream`, junto con `ERROR: requested WAL segment ... has already been removed`. Como se muestra en la línea en negrita, Amazon RDS recupera la réplica reproduciendo un archivo WAL archivado.
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Cuando Amazon RDS reproduce suficientes datos de WAL archivados en la réplica para ponerse al corriente, el streaming a la réplica de lectura comienza de nuevo. Cuando se reanuda el streaming, Amazon RDS escribe una entrada en el archivo de registro, similar a la siguiente.
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## Configuración de los parámetros que controlan la memoria compartida
Los parámetros que establezca determinan el tamaño de la memoria compartida para rastrear los identificadores de las transacciones, los bloqueos y las transacciones preparadas. **La estructura de la memoria compartida de una instancia en espera debe ser igual o mayor que la de una instancia principal.** Esto garantiza que la primera no se quede sin memoria compartida durante la recuperación. Si los valores de los parámetros de la réplica son inferiores a los valores de los parámetros de la principal, Amazon RDS ajustará automáticamente los parámetros de la réplica y reiniciará el motor.
Los parámetros afectados son:
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
Para evitar que RDS reinicie las réplicas por falta de memoria, se recomienda aplicar los cambios de los parámetros como un reinicio progresivo en cada réplica. Al configurar los parámetros, debe aplicar las siguientes reglas:
+ **Aumentar los valores de los parámetros:**
+ En primer lugar, siempre debe aumentar los valores de los parámetros de todas las réplicas de lectura y realizar un reinicio progresivo de todas las réplicas. A continuación, aplique los cambios de los parámetros a la instancia principal y reinicie.
+ **Disminuir los valores de los parámetros:**
+ En primer lugar, debe reducir los valores de los parámetros de la instancia principal y llevar a cabo un reinicio. A continuación, aplique los cambios de los parámetros a todas las réplicas de lectura asociadas y lleve a cabo un reinicio progresivo.
# Supervisión y ajuste del proceso de replicación
Le recomendamos encarecidamente que supervise de forma rutinaria su instancia de base de datos de RDS para PostgreSQL y réplicas de lectura. Debe asegurarse de que las réplicas de lectura se mantengan al día con los cambios en la instancia de base de datos de origen. Amazon RDS recupera de forma transparente sus réplicas de lectura cuando se producen interrupciones en el proceso de replicación. Sin embargo, es mejor evitar la necesidad de recuperarse en absoluto. La recuperación mediante slots de replicación es más rápida que utilizar el archivo de Amazon S3, pero cualquier proceso de recuperación puede afectar al rendimiento de lectura.
Para determinar qué tal se mantienen las réplicas de lectura con la instancia de base de datos de origen, puede hacer lo siguiente:
+ **Compruebe la cantidad de `ReplicaLag` entre la instancia de base de datos de origen y las réplicas.** El *retardo de réplica* es la cantidad de retardo, en segundos, que una réplica de lectura acumula con respecto a la instancia de base de datos de origen. Esta métrica informa del resultado de la siguiente consulta.
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
El retraso de réplica indica qué tal se mantiene una réplica de lectura con la instancia de base de datos de origen. Es la cantidad de latencia entre la instancia de base de datos de origen y una instancia de lectura específica. Un valor elevado para el retraso de réplica puede indicar una discrepancia entre las clases de instancia de base de datos o los tipos de almacenamiento (o ambos) utilizados por la instancia de base de datos de origen y sus réplicas de lectura. La clase de instancia de base de datos y los tipos de almacenamiento de la instancia de origen de base de datos y todas las réplicas de lectura deben ser iguales.
El retraso de la réplica también puede ser el resultado de problemas de conexión intermitentes. Puede monitorizar el retardo de replicación en Amazon CloudWatch mediante la visualización de la métrica `ReplicaLag` de Amazon RDS. Para obtener más información sobre `ReplicaLag` y otras métricas de Amazon RDS, consulte [Métricas de Amazon CloudWatch para Amazon RDS](rds-metrics.md).
+ **Consulte el registro de PostgreSQL para obtener información que puede utilizar para ajustar la configuración.** En cada punto de control, el registro de PostgreSQL captura el número de archivos de registro de transacciones reciclados, como se muestra en el siguiente ejemplo.
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
Puede utilizar esta información para averiguar cuántos archivos de transacciones se reciclarán en un periodo de tiempo determinado. Puede cambiar la configuración de `wal_keep_segments` si es necesario. Suponga, por ejemplo, que el registro de PostgreSQL `checkpoint complete` muestra `35 recycled` durante un intervalo de 5 minutos. En este caso, el valor predeterminado de `wal_keep_segments` de 32 no es suficiente para seguir el ritmo de la actividad de streaming, con lo que debe aumentar el valor de este parámetro.
+ **Utilice Amazon CloudWatch para supervisar las métricas que pueden predecir problemas de replicación.** En lugar de analizar el registro de PostgreSQL directamente, puede utilizar Amazon CloudWatch para comprobar las métricas recopiladas. Por ejemplo, puede comprobar el valor de la métrica `TransactionLogsGeneration` para ver cuántos datos WAL está generando la instancia de base de datos de origen. En algunos casos, la carga de trabajo de la instancia de base de datos podría generar una gran cantidad de datos WAL. De ser así, puede que tenga que cambiar la clase de la instancia de base de datos de origen y de las réplicas de lectura. El uso de una clase de instancia con un rendimiento de red alto (10 Gbps) puede reducir el retraso de las réplicas.
## Supervisión de las slots de replicación de su instancia de base de datos de RDS para PostgreSQL
Todas las versiones de RDS para PostgreSQL utilizan slots de replicación para réplicas de lectura entre regiones. RDS para PostgreSQL 14.1 y versiones posteriores utilizan slots de replicación para réplicas de lectura en región. Las réplicas de lectura dentro de la región también utilizan Amazon S3 para archivar datos WAL. En otras palabras, si la instancia de base de datos y las réplicas de lectura ejecutan PostgreSQL 14.1 o superior, las slots de replicación y los archivos de Amazon S3 están disponibles para recuperar la réplica de lectura. La recuperación de una réplica de lectura mediante su slot de replicación es más rápida que la recuperación del archivo Amazon S3. Por lo tanto, le recomendamos que supervise las slots de replicación y las métricas relacionadas.
Puede ver las slots de replicación en sus instancias de base de datos de RDS para PostgreSQL consultando la vista de `pg_replication_slots`, de la siguiente manera.
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
El `wal_status` del valor `reserved` significa que la cantidad de datos WAL que mantiene la slot se encuentra dentro de los límites del parámetro `max_wal_size`. En otras palabras, la slot de replicación tiene el tamaño adecuado. Otros posibles valores de los estados son los siguientes:
+ `extended`: la slot supera el ajuste `max_wal_size`, pero los datos de WAL se conservan.
+ `unreserved`: la slot ya no tiene todos los datos WAL necesarios. Parte se eliminará en el siguiente punto de control.
+ `lost`: se han eliminado algunos datos de WAL obligatorios. La slot ya no se puede utilizar.
Los estados `unreserved` y `lost` de `wal_status` solo se ven cuando `max_slot_wal_keep_size` no es negativo.
La vista de `pg_replication_slots` muestra el estado actual de las slots de replicación. Para evaluar el rendimiento de sus slots de replicación, puede utilizar Amazon CloudWatch y supervisar las siguientes métricas:
+ **`OldestReplicationSlotLag`** – muestra la cantidad de datos del registro de escritura anticipada (WAL) en el origen que no ha consumido la réplica más retrasada.
+ **`TransactionLogsDiskUsage`** – muestra cuánto almacenamiento se usa para los datos de WAL. Cuando una réplica de lectura se retrasa significativamente, el valor de esta métrica puede aumentar sustancialmente.
Para obtener más información acerca del uso de Amazon CloudWatch y las métricas de RDS para PostgreSQL, consulte [Supervisión de métricas de Amazon RDS con Amazon CloudWatch](monitoring-cloudwatch.md). Para obtener más información sobre cómo supervisar la replicación de streaming en sus instancias de base de datos de RDS para PostgreSQL, consulte [Best practices for Amazon RDS PostgreSQL replication](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) en *AWSDatabase Blog*.
# Configuración de la replicación retrasada con RDS para PostgreSQL
## Información general y beneficios
La característica de replicación retrasada de RDS para PostgreSQL le permite retrasar intencionadamente la replicación de los cambios de datos de la base de datos principal a uno o más servidores en espera (réplica de lectura). Esto proporciona una protección valiosa contra la corrupción de los datos, la pérdida accidental de datos o las transacciones erróneas que, de otro modo, podrían propagarse inmediatamente a todas las réplicas.
La replicación retrasada es compatible con las siguientes versiones de RDS para PostgreSQL:
+ Versión 14.19 y otras versiones 14 superiores
+ Versión 15.14 y otras versiones 15 superiores
+ Versión 16.10 y otras versiones 16 superiores
+ Versión 17.6 y otras versiones 17 superiores
Al ingresar un intervalo de tiempo en el proceso de replicación, tendrá la oportunidad de detectar y responder a los incidentes relacionados con los datos antes de que afecten a todo el clúster de base de datos. Algunos de los beneficios clave de la replicación retrasada son los siguientes:
+ Le permite recuperarse de eliminaciones accidentales, actualizaciones u otros errores lógicos.
+ Proporciona un búfer para evitar que los datos dañados se propaguen por el clúster de base de datos.
+ Ofrece una opción de punto de recuperación adicional para complementar sus estrategias de copia de seguridad tradicionales.
+ Le permite configurar el periodo de retraso en función de las necesidades específicas y la tolerancia al riesgo de la organización.
## Habilitación y configuración de la replicación retrasada
Para habilitar la replicación retrasada en una réplica de lectura de RDS para PostgreSQL, siga estos pasos:
**nota**
Para las réplicas de lectura en cascada, utilice el mismo parámetro y los mismos pasos de `recovery_min_apply_delay` que se describen a continuación.
**Habilitación de la replicación retrasada**
1. Cree un nuevo grupo de parámetros personalizado o modifique uno existente. Para obtener más información, consulte [Grupos de parámetros de base de datos para instancias de Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
1. En el grupo de parámetros, configure el parámetro `recovery_min_apply_delay`:
+ Establezca el valor en el retraso deseado en milisegundos. Por ejemplo, 3 600 000 para un retraso de 1 hora.
+ Rango permitido: de 0 a 86 400 000 ms (de 0 a 24 horas)
+ Predeterminado: 0
1. Aplique el grupo de parámetros a la instancia de réplica de lectura que desee configurar para la replicación retrasada.
1. Reinicie la instancia de la réplica de lectura para que los cambios surtan efecto.
**nota**
El parámetro `recovery_min_apply_delay` es dinámico. Si modifica un grupo de parámetros existente que ya está adjunto a la instancia, los cambios se aplicarán inmediatamente sin necesidad de reiniciarlo. Sin embargo, al aplicar un nuevo grupo de parámetros a la instancia, debe reiniciar para que los cambios surtan efecto.
## Administración de la recuperación de la replicación retrasada
La replicación retrasada es particularmente útil en situaciones en las que los métodos tradicionales de recuperación en un momento dado pueden resultar insuficientes o consumir demasiado tiempo.
Durante el periodo de replicación retrasada, puede utilizar las siguientes funciones de PostgreSQL para administrar el proceso de recuperación:
+ `pg_wal_replay_pause()`: solicite pausar el proceso de recuperación en la réplica retrasada.
+ `pg_wal_replay_resume()`: reinicie el proceso de recuperación si ya estaba pausado anteriormente.
+ `pg_is_wal_replay_paused()`: compruebe si el proceso de recuperación está pausado actualmente.
+ `pg_get_wal_replay_pause_state()`: obtenga el estado actual del proceso de recuperación (no pausado, pausa solicitada o pausado).
Los usuarios con el rol `rds_superuser` tienen los privilegios EXECUTE en `pg_wal_replay_pause()` y `pg_wal_replay_resume()`. Si otros usuarios de la base de datos necesitan acceder a estas funciones, debe concederles el rol `rds_superuser`. Para obtener más información acerca de los roles de `rds_superuser`, consulte [Descripción del rol rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
El acceso a otras funciones como `pg_is_wal_replay_paused()` y `pg_get_wal_replay_pause_state()` no requiere el rol `rds_superuser`.
Puede utilizar los siguientes parámetros del objetivo de recuperación para controlar con precisión el momento en el que se recupera la réplica retrasada. Estos parámetros son estáticos y es necesario reiniciar la base de datos para aplicar los cambios:
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**importante**
Solo puede especificar un parámetro de destino de recuperación a la vez. La configuración de varios parámetros de destino de recuperación en el archivo de configuración produce un error.
## Consideraciones sobre la planificación
Tenga en cuenta lo siguiente al planificar la replicación retrasada con RDS para PostgreSQL:
+ Durante la rotación automática de las credenciales de `rdsrepladmin` (que se produce cada 90 días), las réplicas de lectura retrasadas pueden pasar temporalmente a un estado `REPLICATION_ERROR`. Si la réplica retrasada tiene suficientes registros de WAL para mantener el retraso configurado, puede detener el proceso del receptor WAL y provocar la acumulación de WAL en el origen. Debe supervisar el estado de la replicación en la réplica y el consumo de almacenamiento en el origen para evitar que se llene el almacenamiento.
+ Cuando las réplicas de lectura retrasadas detectan eventos del sistema (como un reinicio), pasan a un estado `REPLICATION_ERROR` en el que el proceso del receptor WAL permanece inactivo hasta que venza el periodo de retraso configurado. Este comportamiento puede provocar la acumulación de WAL en la instancia de origen, lo que podría provocar el agotamiento del almacenamiento. Considere las siguientes medidas de prevención:
+ Configure las alarmas de CloudWatch para supervisar el uso del almacenamiento en las instancias de origen.
+ Habilite el escalado automático del almacenamiento para gestionar el crecimiento inesperado de WAL.
+ Establezca el parámetro `max_slot_wal_keep_size` en la instancia de origen para limitar la retención de WAL por ranura de replicación.
+ Supervise periódicamente el retraso de la replicación y el estado de las ranuras.
+ Los retrasos más prolongados aumentan los registros de WAL en las réplicas y consumen más almacenamiento. Supervise el espacio de almacenamiento mediante las alarmas de CloudWatch, habilite el escalado automático o recupere las réplicas cuando sea necesario.
+ Cuando se promociona una réplica de lectura retrasada, no se respeta el parámetro `recovery_min_apply_delay` y todos los registros de WAL pendientes se aplican inmediatamente.
+ El parámetro `recovery_min_apply_delay` es independiente en cada nivel de una configuración de replicación en cascada. El establecimiento de un retraso en una réplica no aumenta el retraso de ninguna réplica en cascada.
Para obtener más información, consulte la [documentación de réplicas de lectura de RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) y la [documentación de recuperación ante desastres de RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html).
## Limitaciones de la comprensión
La característica de replicación retrasada de Amazon RDS para PostgreSQL presenta las siguientes limitaciones:
+ Las implementaciones azul/verde tienen las siguientes limitaciones a la hora de configurar la replicación retrasada:
+ **Instancia de origen verde**: no se tiene en cuenta `recovery_min_apply_delay parameter`, aunque se configure en el grupo de parámetros. Los ajustes de retraso de la instancia de origen verde no surten efecto.
+ **Instancia de réplica verde**: `recovery_min_apply_delay parameter` es totalmente compatible y se aplica al archivo de configuración de PostgreSQL. Los ajustes de retraso funcionan según lo previsto durante el flujo de trabajo de transición.
+ Implementaciones azul/verde de RDS para actualizaciones de versiones principales
+ Durante las actualizaciones de versiones principales, cualquier réplica de lectura retrasada se cancelará automáticamente para permitir que la instancia de origen continúe con el proceso de actualización y garantizar un tiempo de inactividad mínimo. Una vez que la instancia de origen haya completado la actualización, debe volver a crear manualmente las réplicas retrasadas.
+ La replicación retrasada no es compatible con las siguientes características.
+ Replicación lógica de RDS para PostgreSQL
+ Clústeres multi-AZ de RDS para PostgreSQL (incluida la replicación de entrada y de salida)
+ Aurora PostgreSQL
# Solución de problemas de réplicas de lectura de RDS para PostgreSQL
A continuación, encontrará ideas para solucionar algunos problemas comunes de las réplicas de lectura de RDS para PostgreSQL.
**Finalice la consulta que provoca el retardo de la réplica de lectura**
Las transacciones activas o inactivas en un estado de transacción que se estén ejecutando durante mucho tiempo en la base de datos pueden interferir con el proceso de replicación de WAL y, por lo tanto, aumentar el retardo de la replicación. Por lo tanto, asegúrese de supervisar el tiempo de ejecución de estas transacciones con la vista `pg_stat_activity` de PostgreSQL.
Ejecute una consulta en la instancia principal similar a la siguiente para encontrar el ID de proceso (PID) de la consulta que lleva mucho tiempo ejecutándose:
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Tras identificar el PID de la consulta, puede optar por finalizarla.
Ejecute una consulta en la instancia principal similar a la siguiente para finalizar la consulta que lleva mucho tiempo ejecutándose:
```
SELECT pg_terminate_backend(PID);
```
# Mejora del rendimiento de las consultas de RDS para PostgreSQL con lecturas optimizadas para Amazon RDS
Puede lograr un procesamiento de consultas más rápido en RDS para PostgreSQL con las lecturas optimizadas para Amazon RDS. Una instancia de base de datos de RDS para PostgreSQL o un clúster de base de datos Multi-AZ que utilice lecturas optimizadas para RDS puede procesar las consultas hasta un 50 % más rápido en comparación con una instancia que no las use.
**Topics**
+ [Información general de las lecturas optimizadas para RDS en PostgreSQL](#USER_PostgreSQL.optimizedreads-overview)
+ [Casos de uso de lecturas optimizadas para RDS](#USER_PostgreSQL.optimizedreads-use-cases)
+ [Prácticas recomendadas para lecturas optimizadas de RDS](#USER_PostgreSQL.optimizedreads-best-practices)
+ [Uso de lecturas optimizadas de RDS](#USER_PostgreSQL.optimizedreads-using)
+ [Supervisión de instancias de base de datos que utilizan lecturas optimizadas de RDS](#USER_PostgreSQL.optimizedreads-monitoring)
+ [Limitaciones de las lecturas optimizadas para RDS en PostgreSQL](#USER_PostgreSQL.optimizedreads-limitations)
## Información general de las lecturas optimizadas para RDS en PostgreSQL
Las lecturas optimizadas están disponibles de forma predeterminada en RDS para PostgreSQL versiones 15.2 y posteriores, 14.7 y posteriores y 13.10 y posteriores al usar clases de instancias de base de datos basadas en NVMe. Para ver las especificaciones de hardware que indican qué instancias utilizan NVMe, consulte [Especificaciones de hardware para clases de instancia de base de datos ](Concepts.DBInstanceClass.Summary.md).
Cuando utiliza una instancia de base de datos de RDS para PostgreSQL o un clúster de base de datos Multi-AZ que tiene activadas las lecturas optimizadas para RDS, consigue un rendimiento de consulta hasta un 50 % más rápido utilizando el almacenamiento local a nivel de bloque basado en unidades de estado sólido (SSD) de memoria rápida no volátil (NVMe). Puede procesar las consultas más rápido si coloca las tablas temporales generadas por PostgreSQL en el almacenamiento local, lo que reduce el tráfico a Elastic Block Storage (EBS) a través de la red.
En PostgreSQL, los objetos temporales se asignan a un espacio de nombres temporal que se elimina automáticamente al final de la sesión. Al borrar el espacio de nombres temporal, se eliminan todos los objetos que dependen de la sesión, incluidos los objetos que cumplen los requisitos del esquema, como tablas, funciones, operadores o incluso extensiones.
En RDS para PostgreSQL, el parámetro `temp_tablespaces` se configura para esta área de trabajo temporal donde se almacenan los objetos temporales.
Las siguientes consultas devuelven el nombre del espacio de tablas y su ubicación.
```
postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
rds_temp_tablespace
(1 row)
```
`rds_temp_tablespace` es un espacio de tabla configurado por RDS que apunta hacia el almacenamiento local de NVMe. Siempre puede volver al almacenamiento de Amazon EBS modificando este parámetro en el `Parameter group` con la Consola de administración de AWS para apuntar a cualquier espacio de tablas que no sea `rds_temp_tablespace`. Para obtener más información, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). También puede utilizar el comando SET para modificar el valor del parámetro `temp_tablespaces` a `pg_default` a nivel de sesión. La modificación del parámetro redirige el área de trabajo temporal a Amazon EBS. Resulta útil volver a Amazon EBS cuando el almacenamiento local de la instancia o el clúster de RDS no es suficiente para realizar una operación SQL específica.
```
postgres=> SET temp_tablespaces TO 'pg_default';
SET
```
```
postgres=> show temp_tablespaces;
temp_tablespaces
------------------
pg_default
```
## Casos de uso de lecturas optimizadas para RDS
Estos son algunos casos de uso que pueden beneficiarse de las lecturas optimizadas:
+ Consultas analíticas que incluyen expresiones comunes de tabla (CTE), tablas derivadas y operaciones de agrupación.
+ Réplicas de lectura que gestionan consultas no optimizadas de una aplicación.
+ Consultas de informes dinámicas o bajo demanda con operaciones complejas, como GROUP BY y ORDER BY, que no siempre pueden utilizar los índices adecuados.
+ Otras cargas de trabajo que utilizan tablas temporales internas.
+ Operaciones `CREATE INDEX` o `REINDEX` de ordenación.
## Prácticas recomendadas para lecturas optimizadas de RDS
Utilice estas prácticas recomendadas para utilizar lecturas optimizadas de RDS:
+ Añada una lógica de reintento para las consultas de solo lectura en caso de que fallen debido a que el almacén de instancias está lleno durante la ejecución.
+ Supervise el espacio de almacenamiento disponible en el almacén de instancias con la métrica de CloudWatch `FreeLocalStorage`. Si el almacén de instancias está alcanzando su límite debido a la carga de trabajo de la instancia de base de datos o del clúster de base de datos Multi-AZ, modifíquelo para usar una clase de instancia de base de datos más grande.
## Uso de lecturas optimizadas de RDS
Al aprovisionar una instancia de base de datos RDS para PostgreSQL con una de las clases de instancia de base de datos basadas en NVMe en una implementación de instancia de base de datos Single-AZ, en una implementación de instancia de base de datos Multi-AZ o en una implementación de clúster de base de datos Multi-AZ, la instancia de base de datos utiliza automáticamente lecturas optimizadas de RDS.
Para obtener más información sobre la implementación multi-AZ, consulte [Configuración y administración de una implementación multi-AZ para Amazon RDS](Concepts.MultiAZ.md).
Para activar las lecturas optimizadas de RDS, realice una de las siguientes acciones:
+ Para crear una instancia de base de datos de RDS para PostgreSQL o un clúster de base de datos Multi-AZ, utilice una de las clases de instancia de base de datos basadas en NVMe. Para obtener más información, consulte [Creación de una instancia de base de datos de Amazon RDS](USER_CreateDBInstance.md).
+ Modifique una instancia de base de datos de RDS para PostgreSQL o un clúster de base de datos Multi-AZ para utilizar una de las clases de instancia de base de datos basadas en NVMe. Para obtener más información, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md).
Las lecturas optimizadas de RDS están disponibles en todas las Regiones de AWS donde se admite una o más de las clases de instancia de base de datos con almacenamiento SSD NVMe local. Para obtener más información, consulte [Clases de instancia de base de datos de ](Concepts.DBInstanceClass.md).
Para volver a una instancia de RDS con lecturas no optimizadas, modifique la clase de instancia de base de datos de su instancia de RDS o del clúster por una clase de instancia similar que solo admita el almacenamiento de EBS para las cargas de trabajo de la base de datos. Por ejemplo, si la clase de instancia de base de datos actual es db.r6gd.4xlarge, elija db.r6g.4xlarge para volver atrás. Para obtener más información, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md).
## Supervisión de instancias de base de datos que utilizan lecturas optimizadas de RDS
Puede supervisar las instancias de base de datos que utilizan lecturas optimizadas para RDS con las siguientes métricas de CloudWatch:
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
Estas métricas proporcionan datos sobre el almacén de instancias disponible, las IOPS y el rendimiento. Para obtener más información sobre estas métricas, consulte [Métricas de nivel de instancia de Amazon CloudWatch para Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
Para supervisar el uso actual del almacenamiento local, inicie sesión en la base de datos y ejecute la siguiente consulta:
```
SELECT
spcname AS "Name",
pg_catalog.pg_size_pretty(pg_catalog.pg_tablespace_size(oid)) AS "size"
FROM
pg_catalog.pg_tablespace
WHERE
spcname IN ('rds_temp_tablespace');
```
Para obtener más información sobre los archivos temporales y su uso, consulte [Administración de archivos temporales con PostgreSQL](PostgreSQL.ManagingTempFiles.md).
## Limitaciones de las lecturas optimizadas para RDS en PostgreSQL
Las limitaciones siguientes se aplican a las lecturas optimizadas para RDS en PostgreSQL:
+ Las transacciones pueden fallar cuando el almacén de instancias está lleno.
# Importación de datos en PostgreSQL en Amazon RDS
Supongamos que tiene una implementación de PostgreSQL existente que quiere pasar a Amazon RDS. La complejidad de la tarea dependerá del tamaño de la base de datos y de los tipos de objetos de base de datos que se van a transferir. Por ejemplo, considere una base de datos que contenga conjuntos de datos de tamaños del orden de gigabytes, junto con disparadores y procedimientos almacenados. Esta base de datos será más complicada que una base de datos sencilla con tan solo unos cuantos megabytes de datos de prueba sin disparadores ni procedimientos almacenados.
Es recomendable usar las herramientas de migración de bases de datos de PostgreSQL nativas si se dan las condiciones siguientes:
+ Se trata de una migración homogénea, en la que se migra desde una base de datos con el mismo motor de base de datos que la base de datos de destino.
+ Se va a migrar una base de datos completa.
+ Las herramientas nativas permiten migrar el sistema con un tiempo de inactividad mínimo.
En la mayoría de los demás casos, realizar una migración de base de datos mediante Database Migration Service (AWS DMS) de AWS es el mejor enfoque. AWS DMS puede migrar bases de datos sin tiempo de inactividad y, para numerosos motores de base de datos, continuar la reproducción en curso hasta que todo esté preparado para cambiar a la base de datos de destino. Puede migrar al mismo motor de base de datos o a un motor de base de datos diferente con DMS de AWS. Si va a migrar a un motor de base de datos distinto del de la base de datos origen, puede usar la AWS Schema Conversion Tool (AWS SCT). Se utiliza AWS SCT para migrar objetos de esquema que AWS DMS no ha migrado. Para obtener más información acerca del uso de DMS de AWS, consulte [¿Qué es AWS Database Migration Service?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)
Modifique el grupo de parámetros de base de datos para incluir la siguiente configuración *solo para su importación*. Debe probar la configuración de los parámetros para encontrar los ajustes más eficientes para el tamaño de su instancia de base de datos. También tiene que volver a los valores de producción para esos parámetros cuando se complete la importación.
Modifique la configuración de su instancia de base de datos como se indica a continuación:
+ Deshabilite los backups de la instancia de base de datos (defina backup\$1retention como 0).
+ Deshabilite el uso de Multi-AZ.
Modifique el grupo de parámetros de base de datos para incluir la siguiente configuración. Solo debe usar estos ajustes al importar los datos. Debe probar la configuración de los parámetros para encontrar los ajustes más eficientes para el tamaño de su instancia de base de datos. También tiene que volver a los valores de producción para esos parámetros cuando se complete la importación.
| Parámetro | Valor recomendado al importar | Descripción |
| --- | --- | --- |
| `maintenance_work_mem` | 524288, 1048576, 2097152, o 4194304 (in KB). Estos valores son comparables a 512 MB, 1 GB, 2 GB y 4 GB. | El valor de este ajuste depende del tamaño de su host. Este parámetro se usa en las declaraciones CREATE INDEX y cada comando paralelo puede usar esa cantidad de memoria. Calcule el mejor valor para no elegir uno demasiado alto y quedarse sin memoria. |
| `max_wal_size` | 256 (para la versión 9.6), 4096 (para las versiones 10 y posteriores) | Tamaño máximo para permitir que el WAL crezca durante los puntos de control automáticos. Aumentar este parámetro puede aumentar la cantidad de tiempo necesario para la recuperación de fallos. Este parámetro reemplaza `checkpoint_segments` a la versión 9.6 y versiones posteriores de PostgreSQL. Para la versión 9.6 de PostgreSQL, este valor está en unidades de 16 MB. Para versiones posteriores, el valor está en unidades de 1 MB. Por ejemplo, en la versión 9.6, 128 significa 128 fragmentos que tienen un tamaño de 16 MB cada uno. En la versión 12.4, 2048 significa 2048 fragmentos que tienen un tamaño de 1 MB cada uno. |
| `checkpoint_timeout` | 1800 | El valor de este ajuste reduce la frecuencia de la rotación de WAL. |
| `synchronous_commit` | Desact. | Deshabilite este ajuste para acelerar las operaciones de escritura. La desactivación de este parámetro puede aumentar el riesgo de pérdida de datos si se bloquea el servidor (no desactive FSYNC). |
| `wal_buffers` | 8192 | Este valor está en unidades de 8 KB. Esto mejora la velocidad de generación de WAL. |
| `autovacuum` | 0 | Deshabilite el parámetro autovacuum de PostgreSQL mientras carga los datos para que no consuma recursos. |
Use los comandos `pg_dump -Fc` (comprimido) o `pg_restore -j` (paralelo) con estos ajustes.
**nota**
El comando PostgreSQL `pg_dumpall` requiere permisos de super\$1user que no se conceden al crear una instancia de base de datos, por lo que no se puede usar para importar los datos.
**Topics**
+ [Importación de una base de datos de PostgreSQL desde una instancia Amazon EC2](PostgreSQL.Procedural.Importing.EC2.md)
+ [Uso del comando \$1copy para importar datos en una tabla en una instancia de base de datos PostgreSQL](PostgreSQL.Procedural.Importing.Copy.md)
+ [Importación de datos de Amazon S3 en una instancia de base de datos de RDS para PostgreSQL](USER_PostgreSQL.S3Import.md)
+ [Transporte de bases de datos de PostgreSQL entre instancias de base de datos](PostgreSQL.TransportableDB.md)
# Importación de una base de datos de PostgreSQL desde una instancia Amazon EC2
Si tiene datos en un servidor de PostgreSQL en una instancia de Amazon EC2 y desea moverlos a una instancia de base de datos de PostgreSQL, puede seguir este proceso para migrar los datos.
1. Use pg\$1dump para crear un archivo que contenga los datos que se van a cargar
1. Cree la instancia de base de datos de destino
1. Use *psql* para crear la base de datos en la instancia de base de datos y cargar los datos
1. Cree una instantánea de base de datos de la instancia de la base de datos
En las siguientes secciones. se proporciona más información sobre cada uno de los pasos mencionados anteriormente.
## Paso 1: cree un archivo utilizando pg\$1dump que contiene los datos que se van a cargar
La utilidad `pg_dump` usa el comando COPY para crear un esquema y un volcado de datos de una base de datos de PostgreSQL. El script de volcado generado por `pg_dump` carga los datos en una base de datos con el mismo nombre y vuelve a crear las tablas, los índices y las claves externas. Puede usar el comando `pg_restore` y el parámetro `-d` para restaurar los datos en una base de datos con un nombre diferente.
Antes de crear el volcado de datos, debe consultar las tablas que se van a volcar para obtener un recuento de filas que le permita confirmar el recuento en la instancia de base de datos de destino.
El siguiente comando crea un archivo de volcado llamado mydb2dump.sql para una base de datos llamada mydb2.
```
prompt>pg_dump dbname=mydb2 -f mydb2dump.sql
```
## Paso 2: cree la instancia de base de datos de destino
Cree la instancia de base de datos PostgreSQL de destino con la consola de Amazon RDS, la AWS CLI o la API. Cree la instancia con el ajuste de retención de backup definido en 0 y deshabilite el uso de Multi-AZ. Esto le permitirá acelerar la importación de los datos. Debe crear una instancia de base de datos en la instancia para poder volcar los datos. La base de datos puede tener el mismo nombre que la base de datos que contiene los datos volcados. Si lo prefiere, puede crear una base de datos con un nombre diferente. En este caso, puede usar el comando `pg_restore` y el parámetro `-d` para restaurar los datos en la base de datos que acaba de nombrar.
Por ejemplo, los siguientes comandos se pueden usar para volcar, restaurar y cambiar de nombre una base de datos.
```
pg_dump -Fc -v -h [endpoint of instance] -U [master username] [database] > [database].dump
createdb [new database name]
pg_restore -v -h [endpoint of instance] -U [master username] -d [new database name] [database].dump
```
## Paso 3: use psql para crear la base de datos en la instancia de base de datos y cargar los datos
Puede usar la misma conexión que utilizó para ejecutar el comando pg\$1dump para conectar con la instancia de base de datos de destino y volver a crear la base de datos. Con *psql*, puede usar el nombre del usuario maestro y la contraseña maestra para crear la base de datos en la instancia de base de datos.
El ejemplo siguiente usa *psql* y un archivo de volcado llamado mydb2dump.sql para crear una base de datos llamada mydb2 en una instancia de base de datos PostgreSQL llamada mypginstance:
Para Linux, macOS o Unix:
```
psql \
-f mydb2dump.sql \
--host mypginstance.555555555555.aws-region.rds.amazonaws.com \
--port 8199 \
--username myawsuser \
--password password \
--dbname mydb2
```
Para Windows:
```
psql ^
-f mydb2dump.sql ^
--host mypginstance.555555555555.aws-region.rds.amazonaws.com ^
--port 8199 ^
--username myawsuser ^
--password password ^
--dbname mydb2
```
**nota**
Especifique una contraseña distinta de la que se muestra aquí como práctica recomendada de seguridad.
## Paso 4: cree una instantánea de base de datos de la instancia de base de datos
Una vez que haya comprobado que los datos se han cargado en su instancia de base de datos, es recomendable que cree una instantánea de base de datos de la instancia de base de datos PostgreSQL de destino. Las instantáneas de base de datos son copias de seguridad completos de una instancia de base de datos que se pueden usar para restaurarla a un estado conocido. Una instantánea de base de datos tomada inmediatamente después de la carga le evita tener que volver a cargar los datos en caso de error. También puede usar dicha instantánea para inicializar nuevas instancias de bases de datos. Para obtener más información acerca de la creación de una instantánea de base de datos, consulte [Creación de una instantánea de base de datos para una instancia de base de datos single-AZ para Amazon RDS](USER_CreateSnapshot.md).
# Uso del comando \$1copy para importar datos en una tabla en una instancia de base de datos PostgreSQL
El comando `\copy` PostgreSQL es un metacomando disponible desde la herramienta de cliente interactiva de `psql`. Puede usar `\copy` para importar datos a una tabla de su instancia de base de datos de RDS for PostgreSQL. Para usar el comando `\copy`, primero debe crear la estructura de la tabla en la instancia de base de datos de destino para que `\copy` tenga un destino para los datos que se copian.
Puede usar `\copy` para cargar los datos de un archivo de valores separados por comas (CSV), como uno que se haya exportado y guardado en su estación de trabajo de cliente.
Para importar los datos CSV a la instancia de base de datos de RDS for PostgreSQL de destino, primero conéctese a la instancia de base de datos de destino con `psql`.
```
psql --host=db-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=target-db
```
A continuación, se ejecuta el comando `\copy` con los siguientes parámetros para identificar el destino de los datos y su formato.
+ `target_table`: el nombre de la tabla que debe recibir los datos que se copian del archivo CSV.
+ `column_list`: las especificaciones de las columnas de la tabla.
+ `'filename'`: la ruta completa del archivo CSV en la estación de trabajo local.
```
\copy target_table from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV;
```
Si el archivo CSV tiene información sobre el encabezamiento de las columnas, puede utilizar esta versión del comando y los parámetros.
```
\copy target_table (column-1, column-2, column-3, ...)
from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV HEADER;
```
Si el comando `\copy` falla, PostgreSQL genera mensajes de error.
Creación de una nueva instancia de base de datos en el entorno de vista previa de bases de datos utilizando el comando `psql` con el metacomando `\copy`, tal y como se muestra en los siguientes ejemplos. Este ejemplo usa *source-table* como nombre de la tabla de origen, *source-table.csv* como archivo .csv y *target-db* como base de datos de destino:
Para Linux, macOS o Unix:
```
$psql target-db \
-U \
-p \
-h \
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Para Windows:
```
$psql target-db ^
-U ^
-p ^
-h ^
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Para obtener más información sobre el comando `\copy`, consulte la página de [psql](http://www.postgresql.org/docs/current/static/app-psql.html) en la documentación de PostgreSQL, en la sección *Meta-Commands* (Metacomandos).
# Importación de datos de Amazon S3 en una instancia de base de datos de RDS para PostgreSQL
Puede importar los datos que se hayan almacenado mediante Amazon Simple Storage Service a una tabla en una instancia de base de datos de RDS para PostgreSQL. Para ello, primero debe instalar la extensión de RDS para PostgreSQL `aws_s3`. Esta extensión proporciona las funciones que se utilizan para importar datos de un bucket de Amazon S3. Un *bucket* es un contenedor de objetos o archivos de Amazon S3. Los datos pueden estar en un archivo de valores separados por comas (CSV), un archivo de texto o un archivo comprimido (gzip). A continuación, aprenderá a instalar la extensión y a importar datos de Amazon S3 en una tabla.
Para hacer la importación de Simple Storage Service (Amazon S3) hacia RDS for PostgreSQL, la base de datos debe ejecutar la versión de PostgreSQL 10.7 o superior.
Si no tiene datos almacenados en Amazon S3, primero debe crear un bucket y almacenar los datos. Para obtener más información, consulte los siguientes temas en la *guía del usuario de Amazon Simple Storage Service*.
+ [Crear un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)
+ [Añadir un objeto a un bucket. ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#uploading-an-object-bucket)
Se admite la importación entre cuentas desde Amazon S3. Para obtener más información, consulte [Concesión de permisos entre cuentas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) en la *Guía del usuario de Amazon Simple Storage Service*.
Puede utilizar la clave administrada por el cliente para el cifrado al importar datos desde S3. Para obtener más información, consulte [Claves de KMS almacenadas en AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) en la *Guía del usuario de Amazon Simple Storage Service*.
**Topics**
+ [Instalación de la extensión aws\$1s3](USER_PostgreSQL.S3Import.InstallExtension.md)
+ [Información general sobre la importación de datos desde los datos de Amazon S3](USER_PostgreSQL.S3Import.Overview.md)
+ [Configuración del acceso a un bucket de Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md)
+ [Importación de datos de Amazon S3 a una instancia de base de datos de RDS para PostgreSQL](USER_PostgreSQL.S3Import.FileFormats.md)
+ [Referencia de funciones](USER_PostgreSQL.S3Import.Reference.md)
# Instalación de la extensión aws\$1s3
Antes de poder usar Amazon S3 con su instancia de base de datos de RDS para PostgreSQL, debe instalar la extensión `aws_s3`. Esta extensión proporciona funciones para importar datos desde Amazon S3. También proporciona funciones para exportar datos desde una instancia de base de datos de RDS para PostgreSQL a un bucket de Amazon S3. Para obtener más información, consulte [Exportación de datos de una de Amazon S3](postgresql-s3-export.md). La extensión `aws_s3` depende de algunas de las funciones de ayuda en la extensión de `aws_commons`, que se instala automáticamente cuando es necesario.
**Para instalar la extensión de `aws_s3`**
1. Utilice psql (o pgAdmin) para conectarse a la instancia de base de datos de RDS para PostgreSQL como usuario que tiene privilegios de `rds_superuser`. Si mantuvo el nombre predeterminado durante el proceso de configuración, conéctese como `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Para instalar la extensión, ejecute el siguiente comando:
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Para comprobar que la extensión está instalada, puede usar el metacomando psql `\dx`.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Ya están disponibles las funciones para importar datos de Amazon S3 y para exportar datos a Amazon S3.
# Información general sobre la importación de datos desde los datos de Amazon S3
**Para importar datos de S3 en Amazon RDS, realice el siguiente procedimiento:**
Primero, reúna los detalles que necesita proporcionar a la función. Entre ellos se incluye el nombre de la tabla en la instancia de base de datos RDS para PostgreSQL, y el nombre del bucket, la ruta del archivo, el tipo de archivo y la Región de AWS donde se almacenan los datos de Amazon S3. Para obtener más información, consulte el tema para [ver un objeto](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) en la *guía del usuario de Amazon Simple Storage Service*.
**nota**
Actualmente no se admite la importación de datos multiparte desde Amazon S3.
1. Obtenga el nombre de la tabla en la que la función `aws_s3.table_import_from_s3` va a importar los datos. A modo de ejemplo, el siguiente comando crea una tabla `t1` que se puede utilizar en pasos posteriores.
```
postgres=> CREATE TABLE t1
(col1 varchar(80),
col2 varchar(80),
col3 varchar(80));
```
1. Obtenga información sobre el bucket de Amazon S3 y los datos que se van a importar. Para ello, abra la consola de Amazon S3 en [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) y elija **Buckets**. Busque el bucket que contiene sus datos en la lista. Elija el bucket, abra la página de información general de objetos y, a continuación, Properties (Propiedades).
Anote el nombre del bucket, la ruta, la Región de AWS y el tipo de archivo. Necesitará el nombre de recurso de Amazon (ARN) más adelante para configurar el acceso a Amazon S3 a través de un rol de IAM. Para obtener más información, consulte [Configuración del acceso a un bucket de Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md). En la siguiente imagen se muestra un ejemplo.
![\[Imagen de un objeto de archivo en un bucket de Amazon S3.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/aws_s3_import-export_s3_bucket-info.png)
1. Para verificar la ruta a los datos en el bucket de Amazon S3, utilice el comando de AWS CLI `aws s3 cp`. Si la información es correcta, este comando descarga una copia del archivo de Amazon S3.
```
aws s3 cp s3://amzn-s3-demo-bucket/sample_file_path ./
```
1. Configure los permisos de instancia de base de datos de RDS para PostgreSQL para permitir el acceso al archivo en el bucket de Amazon S3. Para ello, utilice un rol de AWS Identity and Access Management (IAM) o las credenciales de seguridad. Para obtener más información, consulte [Configuración del acceso a un bucket de Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md).
1. Proporcione la ruta y otros detalles del objeto de Amazon S3 recopilados (consulte el paso 2) para la función `create_s3_uri` para construir un objeto URI de Amazon S3. Para obtener más información sobre esta función, consulte [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri). A continuación se muestra un ejemplo de cómo construir este objeto durante una sesión de psql.
```
postgres=> SELECT aws_commons.create_s3_uri(
'docs-lab-store-for-rpg',
'versions_and_jdks_listing.csv',
'us-west-1'
) AS s3_uri \gset
```
En el paso siguiente, pase este objeto (`aws_commons._s3_uri_1`) a la función `aws_s3.table_import_from_s3` para importar los datos a la tabla.
1. Invoque la función `aws_s3.table_import_from_s3` para importar los datos de Amazon S3 a la tabla. Para obtener información de referencia, consulte [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3). Para ver ejemplos, consulte [Importación de datos de Amazon S3 a una instancia de base de datos de RDS para PostgreSQL](USER_PostgreSQL.S3Import.FileFormats.md).
# Configuración del acceso a un bucket de Amazon S3
Para importar datos de un archivo de Amazon S3, conceda permiso a la instancia de base de datos de RDS for PostgreSQL del para obtener acceso al bucket de Amazon S3 en el que se encuentra el archivo. Puede proporcionar acceso a un bucket de Amazon S3 de una de las dos formas siguientes, tal y como se describe en los siguientes temas.
**Topics**
+ [Uso de un rol de IAM para obtener acceso a un bucket de Amazon S3](#USER_PostgreSQL.S3Import.ARNRole)
+ [Uso de credenciales de seguridad para obtener acceso a un bucket de Amazon S3](#USER_PostgreSQL.S3Import.Credentials)
+ [Solución de errores de acceso a Amazon S3](#USER_PostgreSQL.S3Import.troubleshooting)
## Uso de un rol de IAM para obtener acceso a un bucket de Amazon S3
Antes de cargar los datos de un archivo de Amazon S3, conceda permiso a la instancia de RDS para la base de datos de PostgreSQL para obtener acceso al bucket de Amazon S3 en el que se encuentra el archivo. De esta forma, no tiene que facilitar ni administrar información adicional de credenciales en la llamada a la función [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
Para ello, cree una política de IAM que proporcione acceso al bucket de Amazon S3. Cree un rol de IAM y conecte la política a dicho rol. A continuación, asigne el rol de IAM a la instancia de base de datos.
**Para dar a una instancia de RDS para la base de datos PostgreSQL acceso a Amazon S3 a través de un rol de IAM, realice el siguiente procedimiento:**
1. Cree una política de IAM.
Esta política concede los permisos de bucket y objeto que permiten que la instancia de RDS para base de datos de PostgreSQL tenga acceso a Amazon S3.
Incluya las siguientes acciones requeridas en la política para permitir la transferencia de archivos de un bucket de Amazon S3 a Amazon RDS:
+ `s3:GetObject`
+ `s3:ListBucket`
Incluya los siguientes recursos en la política para identificar el bucket de Amazon S3 y los objetos incluidos en este. A continuación se muestra el formato de nombre de recurso de Amazon (ARN) para obtener acceso a Amazon S3.
+ arn:aws:s3:::*amzn-s3-demo-bucket*
+ arn:aws:s3:::*amzn-s3-demo-bucket*/\$1
Para obtener información adicional sobre cómo crear una política de IAM para RDS para PostgreSQL, consulte [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Consulte también el [Tutorial: Crear y asociar su primera política administrada por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) en la *Guía del usuario de IAM*.
El siguiente comando de la AWS CLI crea una política de IAM denominada `rds-s3-import-policy` con estas opciones. Otorga acceso a un bucket denominado *amzn-s3-demo-bucket*.
**nota**
Anote el Nombre de recurso de Amazon (ARN) de la política que devolvió este comando. Al asociar la política a un rol de IAM, se necesita el ARN para realizar un paso posterior.
**Example**
Para Linux, macOS o Unix:
```
aws iam create-policy \
--policy-name rds-s3-import-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
Para Windows:
```
aws iam create-policy ^
--policy-name rds-s3-import-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Crear un rol de IAM.
Haga esto para que Amazon RDS pueda asumir este rol de IAM para obtener acceso a los buckets de Amazon S3. Para obtener más información, vea [Crear un rol para delegar permisos a un usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) en *Guía del usuario de IAM. *
Le recomendamos que utilice las claves de contexto de condición globales de `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` y `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` en las políticas basadas en recursos para limitar los permisos del servicio a un recurso específico. Esta es la forma más eficaz de protegerse contra el [problema del suplente confuso](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
Si utiliza claves de contexto de condición globales y el valor `aws:SourceArn` contiene el ID de cuenta, el valor `aws:SourceAccount` y la cuenta en el valor `aws:SourceArn` deben utilizar el mismo ID de cuenta cuando se utiliza en la misma instrucción de política.
+ Use `aws:SourceArn` si quiere acceso entre servicios para un único recurso.
+ Use `aws:SourceAccount` si quiere permitir que cualquier recurso de esa cuenta se asocie al uso entre servicios.
En la política, asegúrese de utilizar la clave de contexto de condición global `aws:SourceArn` con el ARN completo del recurso. En el siguiente ejemplo se muestra cómo se usa el comando de la AWS CLI para crear un rol denominado `rds-s3-import-role`.
**Example**
Para Linux, macOS o Unix:
```
aws iam create-role \
--role-name rds-s3-import-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Para Windows:
```
aws iam create-role ^
--role-name rds-s3-import-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Asocie la política de IAM que creó al rol de IAM creado.
El siguiente comando AWS CLI adjunta la política creada en el paso anterior al rol denominado `rds-s3-import-role`. Sustituya `your-policy-arn` por el ARN de la política que ha anotado en un paso anterior.
**Example**
Para Linux, macOS o Unix:
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-import-role
```
Para Windows:
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-import-role
```
1. Añada el rol de IAM a la instancia de base de datos.
Para ello, utilice la Consola de administración de AWS o la AWS CLI, tal y como se describe a continuación.
### Consola
**Para añadir un rol de IAM para una instancia de base de datos de PostgreSQL utilizando la consola**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Seleccione el nombre de instancia de base de datos de PostgreSQL para mostrar sus detalles.
1. En la pestaña **Connectivity & security (Conectividad y seguridad)**, en la sección **Manage IAM roles (Administrar roles de IAM)**, elija el rol que desee agregar en la instancia **Add IAM roles to this (Agregar roles de IAM a este clúster) **.
1. En Feature **Feature** (Característica), elija **s3Import**.
1. Seleccione **Add role (Añadir rol)**.
### AWS CLI
**Para añadir un rol de IAM para una instancia de base de datos de PostgreSQL utilizando la CLI**
+ Utilice el siguiente comando para añadir el rol a la instancia de base de datos de PostgreSQL denominada `my-db-instance`. Sustituya *`your-role-arn`* por el ARN del rol que ha anotado en el paso anterior. Utilice `s3Import` para el valor de la opción `--feature-name`.
**Example**
Para Linux, macOS o Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Import \
--role-arn your-role-arn \
--region your-region
```
Para Windows:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Import ^
--role-arn your-role-arn ^
--region your-region
```
### API de RDS
Para agregar un rol de IAM para una instancia de base de datos de PostgreSQL mediante la API de Amazon RDS, llame a la operación [AddRoleToDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddRoleToDBInstance.html).
## Uso de credenciales de seguridad para obtener acceso a un bucket de Amazon S3
Si lo prefiere, puede utilizar credenciales de seguridad para proporcionar acceso a un bucket de Amazon S3, en lugar de proporcionar acceso con un rol de IAM. Para ello, especifique el parámetro `credentials` en la llamada a la función [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
El parámetro `credentials` es una estructura de tipo `aws_commons._aws_credentials_1`, que contiene credenciales de AWS. Utilice la función [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) para establecer la clave de acceso y la clave secreta en una estructura `aws_commons._aws_credentials_1`, como se muestra a continuación.
```
postgres=> SELECT aws_commons.create_aws_credentials(
'sample_access_key', 'sample_secret_key', '')
AS creds \gset
```
Tras crear la estructura `aws_commons._aws_credentials_1 `, utilice la función [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) con el parámetro `credentials` para importar los datos, tal y como se muestra a continuación.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
:'creds'
);
```
O bien puede incluir la llamada a la función [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) insertada dentro de la llamada a la función `aws_s3.table_import_from_s3`.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
## Solución de errores de acceso a Amazon S3
Si tiene problemas de conexión al intentar importar los datos de Amazon S3, consulte las recomendaciones que se indican a continuación:
+ [Solución de problemas de identidades y accesos en Amazon RDS](security_iam_troubleshoot.md)
+ [Solución de problemas de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) en la *Guía del usuario de Amazon Simple Storage Service*
+ [Solución de problemas de Amazon S3 e IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) en la *Guía del usuario de IAM*
# Importación de datos de Amazon S3 a una instancia de base de datos de RDS para PostgreSQL
Para importar datos desde su bucket de Amazon S3, utilice la función `table_import_from_s3` de la extensión aws\$1s3. Para obtener información de referencia, consulte [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
**nota**
En los siguientes ejemplos se utiliza el método de rol de IAM para permitir el acceso al bucket de Amazon S3. Por tanto, no hay parámetros de credenciales en las llamadas a la función `aws_s3.table_import_from_s3`.
A continuación se muestra un ejemplo típico.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't1',
'',
'(format csv)',
:'s3_uri'
);
```
Los parámetros son los siguientes:
+ `t1`: nombre de la tabla en la instancia de base de datos de PostgreSQL en la que desea copiar los datos.
+ `''`: lista opcional de columnas en la tabla de la base de datos. Puede utilizar este parámetro para indicar qué columnas de los datos de S3 van en las columnas de la tabla. Si no se especifica ninguna columna, se copian en la tabla todas las columnas. Para obtener un ejemplo de uso de una lista de columnas, consulte [Importación de un archivo de Amazon S3 que utiliza un delimitador personalizado](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
+ `(format csv)`: argumentos de COPY de PostgreSQL. El proceso de copia utiliza los argumentos y el formato del comando [COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html) para importar los datos. Las opciones de formato incluyen un valor separado por comas (CSV), como se muestra en este ejemplo, texto y binario. El valor predeterminado es texto.
+ `s3_uri`: una estructura que contiene la información que identifica el archivo de Amazon S3. Para ver un ejemplo de cómo utilizar la función [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) para crear una estructura `s3_uri`, consulte [Información general sobre la importación de datos desde los datos de Amazon S3](USER_PostgreSQL.S3Import.Overview.md).
Para obtener más información acerca de esta función, consulte [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
La función `aws_s3.table_import_from_s3` devuelve texto. Para especificar otros tipos de archivos que se van a importar desde un bucket de Amazon S3, consulte uno de los siguientes ejemplos.
**nota**
Si importa 0 bytes, se producirá un error.
**Topics**
+ [Importación de un archivo de Amazon S3 que utiliza un delimitador personalizado](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter)
+ [Importación de un archivo comprimido (gzip) de Amazon S3](#USER_PostgreSQL.S3Import.FileFormats.gzip)
+ [Importación de un archivo de Amazon S3 codificado](#USER_PostgreSQL.S3Import.FileFormats.Encoded)
## Importación de un archivo de Amazon S3 que utiliza un delimitador personalizado
En el siguiente ejemplo se muestra cómo importar un archivo que utiliza un delimitador personalizado. También se muestra cómo controlar dónde colocar los datos en la tabla de la base de datos usando el parámetro `column_list` de la función [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
En este ejemplo, supongamos que la siguiente información está organizada en columnas delimitadas por barras verticales en el archivo de Amazon S3.
```
1|foo1|bar1|elephant1
2|foo2|bar2|elephant2
3|foo3|bar3|elephant3
4|foo4|bar4|elephant4
...
```
**Para importar un archivo que utiliza un delimitador personalizado**
1. Cree una tabla en la base de datos para los datos importados.
```
postgres=> CREATE TABLE test (a text, b text, c text, d text, e text);
```
1. Utilice el siguiente formulario de la función [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) para importar datos desde el archivo de Amazon S3.
Puede incluir la llamada a la función [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) insertada dentro de la llamada a la función `aws_s3.table_import_from_s3` para especificar el archivo.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test',
'a,b,d,e',
'DELIMITER ''|''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'pipeDelimitedSampleFile', 'us-east-2')
);
```
Los datos se encuentran ahora en la tabla en las siguientes columnas.
```
postgres=> SELECT * FROM test;
a | b | c | d | e
---+------+---+---+------+-----------
1 | foo1 | | bar1 | elephant1
2 | foo2 | | bar2 | elephant2
3 | foo3 | | bar3 | elephant3
4 | foo4 | | bar4 | elephant4
```
## Importación de un archivo comprimido (gzip) de Amazon S3
El siguiente ejemplo muestra cómo importar un archivo comprimido con gzip desde Amazon S3. El archivo que se importa debe tener los siguientes metadatos de Simple Storage Service (Amazon S3):
+ Clave: `Content-Encoding`
+ Valor:: `gzip`
Si carga el archivo con la Consola de administración de AWS, el sistema suele aplicar los metadatos. Para obtener información sobre cómo cargar archivos en Simple Storage Service (Amazon S3) con la Consola de administración de AWS, la AWS CLI o la API, consulte [Carga de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) en la *Guía del usuario de Amazon Simple Storage Service*.
Para obtener más información acerca de los metadatos de Simple Storage Service (Amazon S3) y detalles acerca de los metadatos proporcionados por el sistema, consulte [Edición de metadatos de objeto en la consola de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) en la *Guía del usuario de Amazon Simple Storage Service*.
Importe el archivo gzip en su instancia de RDS para la base de datos PostgreSQL como se muestra a continuación.
```
postgres=> CREATE TABLE test_gzip(id int, a text, b text, c text, d text);
postgres=> SELECT aws_s3.table_import_from_s3(
'test_gzip', '', '(format csv)',
'amzn-s3-demo-bucket', 'test-data.gz', 'us-east-2'
);
```
## Importación de un archivo de Amazon S3 codificado
El siguiente ejemplo muestra cómo importar un archivo desde Amazon S3 que tenga codificación Windows-1252.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test_table', '', 'encoding ''WIN1252''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'SampleFile', 'us-east-2')
);
```
# Referencia de funciones
**Topics**
+ [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3)
+ [aws\$1commons.create\$1s3\$1uri](#USER_PostgreSQL.S3Import.create_s3_uri)
+ [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials)
## aws\$1s3.table\$1import\$1from\$1s3
Importa datos de Amazon S3 en una tabla Amazon RDS. La extensión `aws_s3` proporciona la función `aws_s3.table_import_from_s3`. El valor de devolución es texto.
### Sintaxis
Los parámetros obligatorios son `table_name`, `column_list` y `options`. Estos identifican la tabla de la base de datos y especifican cómo se copian los datos en la tabla.
Asimismo, puede utilizar los siguientes parámetros:
+ El parámetro `s3_info` especifica el archivo Amazon S3 que se va a importar. Cuando utilice este parámetro, se proporciona acceso a Amazon S3 mediante un rol de IAM para la instancia de base de datos de PostgreSQL.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1
)
```
+ El parámetro `credentials` especifica las credenciales para acceder a Amazon S3. Cuando utilice este parámetro, no utilice un rol de IAM.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
```
### Parameters
*table\$1name*
Cadena de texto obligatoria que contiene el nombre de la tabla de la base de datos de PostgreSQL a la que importar los datos.
*column\$1list*
Cadena de texto obligatoria que contiene una lista opcional de las columnas de la tabla de la base de datos de PostgreSQL en la que se copiarán los datos. Si la cadena está vacía, se utilizan todas las columnas de la tabla. Para ver un ejemplo, consulte [Importación de un archivo de Amazon S3 que utiliza un delimitador personalizado](USER_PostgreSQL.S3Import.FileFormats.md#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
*Opciones de*
Cadena de texto obligatoria que contiene argumentos para el comando `COPY` de PostgreSQL. Estos argumentos especifican cómo se copian los datos en la tabla PostgreSQL. Para obtener más detalles, consulte la [documentación de COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*s3\$1info*
Tipo compuesto `aws_commons._s3_uri_1` que contiene la siguiente información sobre el objeto de S3:
+ `bucket`: el nombre del bucket de Amazon S3 que contiene el archivo.
+ `file_path` –: la ruta de Amazon S3 del archivo.
+ `region`: la región de AWS en la que se encuentra el archivo. Para ver una lista de los nombres de regiones de AWS y los valores asociados, consulte [Regiones, zonas de disponibilidad y Local Zones](Concepts.RegionsAndAvailabilityZones.md).
*credenciales*
Tipo compuesto `aws_commons._aws_credentials_1` que contiene las siguientes credenciales para usar en la operación de importación:
+ Clave de acceso
+ Clave secreta
+ Token de sesión
Para obtener información sobre la creación de una estructura compuesta `aws_commons._aws_credentials_1`, consulte [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials).
### Sintaxis alternativa
Como ayuda en las pruebas, puede utilizar un conjunto de parámetros expandido en lugar de los parámetros `s3_info` y `credentials`. A continuación, se incluyen variaciones de sintaxis adicionales para la función:`aws_s3.table_import_from_s3`
+ En lugar de utilizar el parámetro `s3_info` para identificar un archivo de Amazon S3, utilice la combinación de los parámetros `bucket`, `file_path` y `region`. Con esta forma de la función, se facilita acceso a Amazon S3 mediante un rol de IAM en la instancia de base de datos de PostgreSQL.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text
)
```
+ En lugar de utilizar el parámetro `credentials` para especificar el acceso a Amazon S3, utilice la combinación de parámetros `access_key`, `session_key` y `session_token`.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text
)
```
### Parámetros alternativos
*Bucket de*
Cadena de texto que incluye el nombre del bucket de Amazon S3 que contiene el archivo.
*file\$1path*
Cadena de texto que contiene la ruta de Amazon S3 del archivo.
*region*
Una cadena de texto que identifique la ubicación de Región de AWS del archivo. Para ver una lista de los nombres de Región de AWS y los valores asociados, consulte [Regiones, zonas de disponibilidad y Local Zones](Concepts.RegionsAndAvailabilityZones.md).
*access\$1key*
Cadena de texto que contiene la clave de acceso que se va a utilizar para la operación de importación. El valor predeterminado es NULL.
*secret\$1key*
Cadena de texto que contiene la clave secreta que se va a usar para la operación de importación. El valor predeterminado es NULL.
*session\$1token*
(Opcional) Cadena de texto que contiene la clave de la sesión que se va a utilizar para la operación de importación. El valor predeterminado es NULL.
## aws\$1commons.create\$1s3\$1uri
Crea una estructura `aws_commons._s3_uri_1` para contener la información de archivos de Amazon S3. Utilice los resultados de la función `aws_commons.create_s3_uri` en el parámetro `s3_info` de la función [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3).
### Sintaxis
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```
### Parameters
*Bucket de*
Cadena de texto obligatoria que contiene el nombre del bucket de Amazon S3 del archivo.
*file\$1path*
Cadena de texto requerida que contiene la ruta de Amazon S3 del archivo.
*region*
Cadena de texto obligatoria que contiene la Región de AWS en la que se encuentra el archivo. Para ver una lista de los nombres de Región de AWS y los valores asociados, consulte [Regiones, zonas de disponibilidad y Local Zones](Concepts.RegionsAndAvailabilityZones.md).
## aws\$1commons.create\$1aws\$1credentials
Establece una clave de acceso y una clave secreta en una estructura `aws_commons._aws_credentials_1`. Utilice los resultados de la función `aws_commons.create_aws_credentials` en el parámetro `credentials` de la función [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3).
### Sintaxis
```
aws_commons.create_aws_credentials(
access_key text,
secret_key text,
session_token text
)
```
### Parameters
*access\$1key*
Cadena de texto obligatoria que contiene la clave de acceso que se va a utilizar para importar un archivo de Amazon S3. El valor predeterminado es NULL.
*secret\$1key*
Cadena de texto obligatoria que contiene la clave secreta que se va a utilizar para importar un archivo de Amazon S3. El valor predeterminado es NULL.
*session\$1token*
Cadena de texto opcional que contiene el token de la sesión que se va a utilizar para importar un archivo de Amazon S3. El valor predeterminado es NULL. Si facilita un `session_token` opcional, puede usar credenciales temporales.
# Transporte de bases de datos de PostgreSQL entre instancias de base de datos
Cuando utilice bases de datos transportables de PostgreSQL para Amazon RDS, puede trasladar una base de datos de PostgreSQL entre dos instancias de base de datos. Es una forma muy rápida de migrar bases de datos grandes entre distintas instancias de base de datos. Para utilizar este enfoque, ambas instancias de base de datos deben ejecutar la misma versión principal de PostgreSQL.
Esta capacidad requiere que instale la extensión `pg_transport` tanto en la instancia de base de datos de origen como en la de destino. La extensión `pg_transport` proporciona un mecanismo físico de transporte que traslada los archivos de base de datos con un procesamiento mínimo. Este mecanismo traslada los datos mucho más rápido que los procesos tradicionales de volcado y carga, con menos tiempo de inactividad.
**nota**
Las bases de datos transportables de PostgreSQL están disponibles para la versión 11.5 y las versiones posteriores de RDS for PostgreSQL, al igual que para la versión 10.10 y las versiones posteriores.
Para transportar una instancia de base de datos de PostgreSQL de una instancia de base de datos de RDS for PostgreSQL a otra, primero configure las instancias de origen y destino según se detalla en [ Configuración de una instancia de base de datos para transporte](PostgreSQL.TransportableDB.Setup.md). A continuación, puede transportar la base de datos mediante la función descrita en [ Transporte de una base de datos de PostgreSQL](PostgreSQL.TransportableDB.Transporting.md).
**Topics**
+ [Lo que ocurre durante el transporte de base de datos](#PostgreSQL.TransportableDB.DuringTransport)
+ [Limitaciones del uso de bases de datos transportables de PostgreSQL](#PostgreSQL.TransportableDB.Limits)
+ [Configuración de transporte de una base de datos de PostgreSQL](PostgreSQL.TransportableDB.Setup.md)
+ [Transporte de una base de datos PostgreSQL al destino desde el origen](PostgreSQL.TransportableDB.Transporting.md)
+ [Referencia de función de bases de datos transportables](PostgreSQL.TransportableDB.transport.import_from_server.md)
+ [Referencia de parámetros de bases de datos transportables](PostgreSQL.TransportableDB.Parameters.md)
## Lo que ocurre durante el transporte de base de datos
La característica de bases de datos transportables de PostgreSQL utiliza un modelo de extracción para importar la base de datos de la instancia de base de datos de origen a la de destino. La función `transport.import_from_server` crea la base de datos en tránsito en la instancia de base de datos de destino. No se puede acceder a la base de datos en tránsito en la instancia de base de datos de destino mientras dura el transporte.
Cuando el transporte comienza, finalizan todas las sesiones actuales en la base de datos de origen. Cualquier base de datos distinta a la base de datos de origen en la instancia de base de datos de origen no se ve afectada por el transporte.
La base de datos de origen se pone en un modo de solo lectura especial. Mientras está en este modo, puede conectar a la base de datos de origen y ejecutar consultas de solo lectura. Sin embargo, las consultas habilitadas para escritura y algunos otros tipos de comandos están bloqueados. Solo la base de datos de origen específica que se transporta se ve afectada por estas restricciones.
Durante el transporte, no puede restaurar la instancia de base de datos de destino a un momento en el tiempo. Esto se debe a que el transporte no es transaccional y no utiliza el registro antes de la escritura de PostgreSQL para registrar cambios. Si la instancia de base de datos de destino tiene habilitadas las copias de seguridad automáticas, se realiza automáticamente una copia de seguridad una vez que se completa el transporte. Las restauraciones a un momento dado están disponibles para momentos *después* de que finalice la copia de seguridad.
Si el transporte devuelve un error, la extensión `pg_transport` intenta deshacer todos los cambios en las instancias de base de datos de origen y de destino. Esto incluye eliminar la base de datos transportada parcialmente del destino. En función del tipo de error, la base de datos de origen podría seguir rechazando consultas habilitadas para escritura. Si esto ocurre, utilice el comando siguiente para permitir consultas habilitadas para escritura.
```
ALTER DATABASE db-name SET default_transaction_read_only = false;
```
## Limitaciones del uso de bases de datos transportables de PostgreSQL
Las bases de datos transportables tienen las limitaciones siguientes:
+ **Réplicas de lectura**: no puede utilizar bases de datos transportables en réplicas de lectura o instancias principales de réplicas de lectura.
+ **Tipos de columna no admitidos**: no puede usar los tipos de datos `reg` en las tablas de base de datos que tenga previsto transportar con este método. Estos tipos depende de los ID de objeto (OID) de catálogo del sistema, que suelen cambiar durante el transporte.
+ **Espacios de tablas**: todos los objetos de base de datos de origen deben estar en el espacio de tablas `pg_default` predeterminado.
+ **Compatibilidad**: tanto las instancias de base de datos de origen como destino deben ejecutar la misma versión principal de PostgreSQL.
+ **Extensiones**: la instancia de base de datos de origen solo puede tener la extensión `pg_transport` instalada.
+ **Roles y ACL**: los privilegios de acceso y base de datos de origen y la información de propiedad no se traslada a la base de datos de destino. Todos los objetos de base de datos los crea y son propiedad del usuario de destino local del transporte.
+ **Transportes simultáneos**: una única instancia de base de datos puede admitir hasta 32 transportes simultáneos, incluidas tanto las importaciones como las exportaciones, si los procesos de trabajo se han configurado correctamente.
+ **Únicamente para instancias de bases de datos de RDS for PostgreSQL**: las bases de datos transportables de PostgreSQL solo son compatibles en instancias de bases de datos de RDS for PostgreSQL. No puede usarlo con bases de datos locales o bases de datos que se ejecutan en Amazon EC2.
# Configuración de transporte de una base de datos de PostgreSQL
Antes de comenzar, asegúrese de que las instancias de base de datos de RDS for PostgreSQL cumplan los siguientes requisitos:
+ Las instancias de base de datos de RDS for PostgreSQL de origen y destino deben ejecutar la misma versión de PostgreSQL.
+ La base de datos de destino no puede tener una base de datos del mismo nombre que la base de datos de origen que desea transportar.
+ La cuenta que utiliza para gestionar el transporte necesita privilegios `rds_superuser` tanto en la base de datos de origen como en la base de datos de destino.
+ El grupo de seguridad de la instancia de base de datos de origen debe permitir el acceso entrante desde la instancia de base de datos de destino. Es posible que esto ya ocurra si las instancias de base de datos de origen y destino se encuentran en la VPC. Para obtener más información acerca de los grupos de seguridad, consulte [Control de acceso con grupos de seguridad](Overview.RDSSecurityGroups.md).
El transporte de bases de datos desde una instancia de base de datos de origen a una instancia de base de datos de destino requiere varios cambios en el grupo de parámetros de base de datos asociado a cada instancia. Esto significa que debe crear un grupo de parámetros de base de datos personalizado para la instancia de base de datos de origen y otro para la instancia de base de datos de destino.
**nota**
Si las instancias de base de datos ya están configuradas mediante grupos de parámetros de base de datos personalizados, puede comenzar con el paso 2 del siguiente procedimiento.
**Para configurar los parámetros de grupo de bases de datos personalizados para transportar bases de datos**
Para los siguientes pasos, utilice una cuenta que tenga privilegios `rds_superuser`.
1. Si las instancias de base de datos de origen y destino utilizan un grupo de parámetros de base de datos predeterminado, debe crear un grupo de parámetros de base de datos personalizado con la versión adecuada para sus instancias. Haga esto para poder cambiar los valores de varios parámetros. Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
1. En el grupo de parámetros de base de datos personalizado, cambie los valores de los siguientes parámetros:
+ `shared_preload_libraries` – Agregue `pg_transport` a la lista de bibliotecas.
+ `pg_transport.num_workers` – El valor predeterminado es 3. Aumente o reduzca este valor según sea necesario para su base de datos. Para una base de datos de 200 GB, recomendamos que no sea superior a 8. Tenga en cuenta que si aumenta el valor predeterminado de este parámetro, también debe aumentar el valor de `max_worker_processes`.
+ `pg_transport.work_mem` – El valor predeterminado es 128 MB o 256 MB, según la versión de PostgreSQL. Por lo general, la configuración predeterminada se puede dejar sin cambios.
+ `max_worker_processes`: el valor de este parámetro debe establecerse utilizando el siguiente cálculo:
```
(3 * pg_transport.num_workers) + 9
```
Este valor es necesario en el destino para gestionar varios procesos de trabajo en segundo plano involucrados en el transporte. Para obtener más información sobre `max_worker_processes,` y otros parámetros, consulte [Consumo de recursos](https://www.postgresql.org/docs/current/runtime-config-resource.html) en la documentación de PostgreSQL.
Para obtener más información acerca de los parámetros `pg_transport`, consulte [Referencia de parámetros de bases de datos transportables](PostgreSQL.TransportableDB.Parameters.md).
1. Reinicie la instancia de base de datos de origen de RSD for PostgreSQL y la instancia de destino para que la configuración de los parámetros surta efecto.
1. Conéctese a una instancia de base de datos de origen de RDS for PostgreSQL.
```
psql --host=source-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Elimine extensiones extrañas del esquema público de la instancia de base de datos. Solo se permite la extensión `pg_transport` durante la operación de transporte real.
1. Instale la extensión `pg_transport` de la siguiente manera:
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
1. Conéctese a una instancia de base de datos de destino de RDS for PostgreSQL. Elimine las extensiones extrañas y, a continuación, instale la extensión `pg_transport`.
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
# Transporte de una base de datos PostgreSQL al destino desde el origen
Después de completar el proceso descrito en [Configuración de transporte de una base de datos de PostgreSQL](PostgreSQL.TransportableDB.Setup.md), puede comenzar el transporte. Para ello, ejecute la función `transport.import_from_server` en la instancia de base de datos de destino. En la siguiente sintaxis, puede encontrar los parámetros de la función.
```
SELECT transport.import_from_server(
'source-db-instance-endpoint',
source-db-instance-port,
'source-db-instance-user',
'source-user-password',
'source-database-name',
'destination-user-password',
false);
```
El valor `false` que se muestra en el ejemplo indica a la función que no se trata de una prueba. Para probar la configuración de transporte, puede especificar `true` para la opción `dry_run` cuando ejecute la función, como se muestra a continuación:
```
postgres=> SELECT transport.import_from_server(
'docs-lab-source-db.666666666666aws-region.rds.amazonaws.com', 5432,
'postgres', '********', 'labdb', '******', true);
INFO: Starting dry-run of import of database "labdb".
INFO: Created connections to remote database (took 0.03 seconds).
INFO: Checked remote cluster compatibility (took 0.05 seconds).
INFO: Dry-run complete (took 0.08 seconds total).
import_from_server
--------------------
(1 row)
```
Las líneas de INFO se generan porque el parámetro `pg_transport.timing` se establece en su valor predeterminado `true`. Configure `dry_run` en `false` cuando ejecute el comando y la base de datos de origen se importe al destino, como se muestra a continuación:
```
INFO: Starting import of database "labdb".
INFO: Created connections to remote database (took 0.02 seconds).
INFO: Marked remote database as read only (took 0.13 seconds).
INFO: Checked remote cluster compatibility (took 0.03 seconds).
INFO: Signaled creation of PITR blackout window (took 2.01 seconds).
INFO: Applied remote database schema pre-data (took 0.50 seconds).
INFO: Created connections to local cluster (took 0.01 seconds).
INFO: Locked down destination database (took 0.00 seconds).
INFO: Completed transfer of database files (took 0.24 seconds).
INFO: Completed clean up (took 1.02 seconds).
INFO: Physical transport complete (took 3.97 seconds total).
import_from_server
--------------------
(1 row)
```
Esta función requiere que proporcione contraseñas de usuario de base de datos. De esta manera, le recomendamos que cambie las contraseñas de los roles de usuario que ha utilizado después de completar el transporte. O, puede utilizar variables de enlace SQL para crear roles de usuario temporales. Utilice estos roles temporales para el transporte y, a continuación, descarte los roles con posterioridad.
Si el transporte no se realiza correctamente, es posible que vea un mensaje de error similar al siguiente:
```
pg_transport.num_workers=8 25% of files transported failed to download file data
```
El mensaje de error “Failed to download file data” (No se pudo descargar los datos de archivo) indica que el número de procesos de trabajo no está configurado correctamente para el tamaño de la base de datos. Es posible que tenga que aumentar o disminuir el valor establecido para `pg_transport.num_workers`. Cada error informa el porcentaje de finalización, de modo que pueda ver el impacto de los cambios. Por ejemplo, cambiar la configuración de 8 a 4 en un caso dio lugar a lo siguiente:
```
pg_transport.num_workers=4 75% of files transported failed to download file data
```
Tenga en cuenta que el parámetro `max_worker_processes` también se tiene en cuenta durante el proceso de transporte. En otras palabras, es posible que tenga que modificar tanto `pg_transport.num_workers` como `max_worker_processes` para transportar correctamente la base de datos. El ejemplo que se muestra finalmente funcionó cuando `pg_transport.num_workers` se estableció en 2:
```
pg_transport.num_workers=2 100% of files transported
```
Para obtener más información sobre la funcionalidad `transport.import_from_server` y sus parámetros, consulte [Referencia de función de bases de datos transportables](PostgreSQL.TransportableDB.transport.import_from_server.md).
# Referencia de función de bases de datos transportables
La función `transport.import_from_server` transporta una base de datos de PostgreSQL importándola desde una instancia de base de datos de origen en una instancia de base de datos de destino. Lo hace utilizando un mecanismo de transporte de conexión de base de datos física.
Antes de iniciar el transporte, esta función verifica que las instancias de base de datos de origen y de destino sean la misma versión y sean compatibles para la migración. También confirma que la instancia de base de datos de destino tenga suficiente espacio para la de origen.
**Sintaxis**
```
transport.import_from_server(
host text,
port int,
username text,
password text,
database text,
local_password text,
dry_run bool
)
```
**Valor de retorno**
Ninguno.
**Parámetros**
Puede buscar las descripciones de los parámetros de función `transport.import_from_server` en la tabla siguiente.
****
| Parámetro | Descripción |
| --- | --- |
| host | El punto de enlace de una instancia de base de datos de origen. |
| port | Un entero que representa el puerto de la instancia de base de datos de origen. Las instancias de base de datos de PostgreSQL suelen utilizar el puerto 5432. |
| username | El usuario de la instancia de base de datos de origen. Este usuario debe ser un miembro del rol `rds_superuser`. |
| password | La contraseña de usuario de la instancia de base de datos de origen. |
| database | El nombre de la base de datos en la instancia de base de datos de origen que transportar. |
| local\$1password | La contraseña local del usuario actual para la instancia de base de datos de destino. Este usuario debe ser un miembro del rol `rds_superuser`. |
| dry\$1run | Un valor booleano opcional que especifique si realizar un simulacro. El valor predeterminado es `false`, lo que significa que el transporte continúa.Para confirmar la compatibilidad entre las instancias de base de datos de origen y destino sin llevar a cabo el transporte real, defina dry\$1run en true. |
**Ejemplo**
Para ver un ejemplo, consulte [Transporte de una base de datos PostgreSQL al destino desde el origen](PostgreSQL.TransportableDB.Transporting.md).
# Referencia de parámetros de bases de datos transportables
Varios parámetros controlan el comportamiento de la extensión `pg_transport`. A continuación, puede encontrar las descripciones de estos parámetros.
**`pg_transport.num_workers`**
El número de empleados que se necesitarán para el proceso de transporte. El valor predeterminado es 3. Los valores válidos están comprendidos entre 1 y 32. Incluso los transportes de base de datos más grandes normalmente requieren menos de 8 empleados. El valor de esta configuración en la instancia de base de datos de destino se utiliza tanto en las instancias de base de datos de destino y de origen durante el transporte.
**`pg_transport.timing` **
Especifica si se debe notificar la información de tiempo durante el transporte. El valor predeterminado es `true`, lo que significa que se informa la información de los plazos. Le recomendamos que deje este parámetro configurado en `true` para que pueda supervisar el progreso. Para ejemplo de salida, consulte [Transporte de una base de datos PostgreSQL al destino desde el origen](PostgreSQL.TransportableDB.Transporting.md).
**`pg_transport.work_mem`**
La cantidad de memoria máxima que asignar para cada proceso de trabajo. El valor predeterminado es 131 072 kilobytes (KB) o 262 144 KB (256 MB), según la versión de PostgreSQL. El valor mínimo es 64 megabytes (65 536 KB). Los valores válidos están en kilobytes (KB) como unidades binarias de base 2, donde 1 KB = 1024 bytes.
El transporte podría utilizar menos memoria que la que se especifica en este parámetro. Incluso los transportes de base de datos grandes normalmente requieren menos de 256 MB (262 144 KB) de memoria por proceso de trabajo.
# Exportación de datos de una de Amazon S3
Puede consultar datos de una RDS for PostgreSQL y exportarlos directamente a archivos almacenados en un bucket de Amazon S3. Para ello, primero debe instalar la extensión de RDS para PostgreSQL `aws_s3`. Esta extensión le proporciona las funciones que utiliza para exportar los resultados de las consultas a Amazon S3. A continuación, puede averiguar cómo instalar la extensión y cómo exportar datos de Amazon S3.
**nota**
No se ha agregado compatibilidad con la exportación entre cuentas a Amazon S3.
Todas las versiones disponibles actualmente de RDS para PostgreSQL admiten la exportación de datos a Amazon Simple Storage Service. Para obtener información detallada sobre la versión, consulte las [actualizaciones de Amazon RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html) en las *notas de la versión de Amazon RDS para PostgreSQL*.
Si no tienes un bucket configurado para la exportación, consulta los siguientes temas: *Guía del usuario de Amazon Simple Storage Service*.
+ [Configuración de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html)
+ [Crear un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)
De forma predeterminada, los datos exportados desde RDS para PostgreSQL a Amazon S3 utilizan cifrado del servidor con una Clave administrada de AWS. Si utiliza cifrado de buckets, el bucket de Amazon S3 debe cifrarse con una clave AWS Key Management Service (AWS KMS) (SSE-KMS). En la actualidad, no se admiten buckets cifrados con claves administradas de Amazon S3 (SSE-S3).
**nota**
Puede guardar datos de instantáneas de base de datos en Amazon S3 mediante la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS. Para obtener más información, consulte [Exportación de datos de instantáneas de bases de datos a Amazon S3 para Amazon RDS](USER_ExportSnapshot.md).
**Topics**
+ [Instalación de la extensión aws\$1s3](#USER_PostgreSQL.S3Export.InstallExtension)
+ [Información general de la exportación de datos a Amazon S3](#postgresql-s3-export-overview)
+ [Especificación de la ruta del archivo de Amazon S3 a exportar](#postgresql-s3-export-file)
+ [Configuración del acceso a un bucket de Amazon S3](postgresql-s3-export-access-bucket.md)
+ [Exportación de datos de consulta mediante la función aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md)
+ [Referencia de funciones](postgresql-s3-export-functions.md)
+ [Solución de errores de acceso a Amazon S3](postgresql-s3-export-troubleshoot.md)
## Instalación de la extensión aws\$1s3
Antes de poder usar Amazon Simple Storage Service con su Instancia de base de datos de RDS para PostgreSQL, debe instalar la extensión `aws_s3`. Esta extensión proporciona funciones para exportar datos desde una instancia de base de datos de RDS para PostgreSQL a un bucket de Amazon S3. También proporciona funciones para importar datos desde Amazon S3. Para obtener más información, consulte [Importación de datos de Amazon S3 en una instancia de base de datos de RDS para PostgreSQL](USER_PostgreSQL.S3Import.md). La extensión `aws_s3` depende de algunas de las funciones de ayuda en la extensión de `aws_commons`, que se instala automáticamente cuando es necesario.
**Para instalar la extensión de `aws_s3`**
1. Utilice psql (o pgAdmin) para conectarse a la instancia de base de datos de RDS para PostgreSQL como usuario que tiene privilegios de `rds_superuser`. Si mantuvo el nombre predeterminado durante el proceso de configuración, conéctese como `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Para instalar la extensión, ejecute el siguiente comando:
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. Para comprobar que la extensión está instalada, puede usar el metacomando psql `\dx`.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Ya están disponibles las funciones para importar datos de Amazon S3 y para exportar datos a Amazon S3.
### Confirme que su versión de RDS para PostgreSQL admite exportaciones a Amazon S3.
Puede comprobar que su versión de RDS para PostgreSQL admite la exportación a Amazon S3 mediante el comando `describe-db-engine-versions`. En el siguiente ejemplo se verifica la compatibilidad con la versión 10.14.
```
aws rds describe-db-engine-versions --region us-east-1
--engine postgres --engine-version 10.14 | grep s3Export
```
Si en la salida se recoge la cadena de texto `"s3Export"`, el motor admite las exportaciones de Amazon S3 . Si no es así, el motor no las admite.
## Información general de la exportación de datos a Amazon S3
Para exportar datos almacenados en una RDS for PostgreSQL a un bucket de Amazon S3, utilice el siguiente procedimiento.
**Para exportar RDS for PostgreSQL datos a S3**
1. Identifique la ruta de archivo de Amazon S3 que se va a utilizar para exportar datos. Para obtener más información sobre este proceso, consulte [Especificación de la ruta del archivo de Amazon S3 a exportar](#postgresql-s3-export-file).
1. Conceda permiso para acceder al bucket de Amazon S3.
Para exportar datos a un archivo de Amazon S3, conceda permiso a la instancia de base de datos de RDS para PostgreSQL para obtener acceso al bucket de Amazon S3 que la exportación usará para el almacenamiento. Esto incluye los siguientes pasos:
1. Cree una política de IAM que proporcione acceso al bucket de Amazon S3 al que se desea exportar.
1. Cree un rol de IAM.
1. Asocie la política que ha creado al rol que ha creado.
1. Agregue este rol de IAM a la instancia de base de datos.
Para obtener más información sobre este proceso, consulte [Configuración del acceso a un bucket de Amazon S3](postgresql-s3-export-access-bucket.md).
1. Identifique una consulta de base de datos para obtener los datos. Exporte los datos de consulta llamando a la función `aws_s3.query_export_to_s3`.
Después de completar las tareas de preparación anteriores, utilice la función [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) para exportar los resultados de la consulta a Amazon S3. Para obtener más información sobre este proceso, consulte [Exportación de datos de consulta mediante la función aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
## Especificación de la ruta del archivo de Amazon S3 a exportar
Especifique la siguiente información para identificar la ubicación de Amazon S3 a la que desea exportar los datos:
+ Nombre de bucket: un *bucket* es un contenedor para objetos o archivos de Amazon S3.
Para obtener más información sobre cómo almacenar datos con Amazon S3, consulte [Crear un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) y [Trabajar con objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-downloading-objects.html) en la *Guía del usuario de Amazon Simple Storage Service*.
+ Ruta del archivo: la ruta del archivo identifica dónde se almacena la exportación en el bucket de Amazon S3. La ruta del archivo consta de lo siguiente:
+ Un prefijo de ruta opcional que identifica una ruta de carpeta virtual.
+ Un prefijo de archivo que identifica uno o varios archivos que se van a almacenar. Las exportaciones más grandes se almacenan en varios archivos, cada uno con un tamaño máximo de aproximadamente 6 GB. Los nombres de archivo adicionales tienen el mismo prefijo de archivo, pero con `_partXX` anexado. `XX` representa 2, luego 3, y así sucesivamente.
Por ejemplo, una ruta de archivo con una carpeta `exports` y un prefijo de archivo `query-1-export` es `/exports/query-1-export`.
+ Región de AWS (opcional): la región de AWS donde se encuentra el bucket de Amazon S3. Si no especifica un valor de región de AWS, Amazon RDS guarda sus archivos en Amazon S3, en la misma región de AWS que la instancia de base de datos de exportación.
**nota**
Actualmente, la región de AWS debe ser la misma región que la del e instancia de base de datos de exportación.
Para ver una lista de los nombres de regiones de AWS y los valores asociados, consulte [Regiones, zonas de disponibilidad y Local Zones](Concepts.RegionsAndAvailabilityZones.md).
Para mantener la información del archivo de Amazon S3 acerca de dónde se va a almacenar la exportación, puede utilizar la función [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) para crear una estructura compuesta `aws_commons._s3_uri_1` de la siguiente manera.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Más adelante, proporcione este valor `s3_uri_1` como un parámetro en la llamada a la función [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Para ver ejemplos, consulte [Exportación de datos de consulta mediante la función aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
# Configuración del acceso a un bucket de Amazon S3
Para exportar datos a Amazon S3, conceda permiso a la instancia de base de datos de PostgreSQL para acceder al bucket de Amazon S3 al que irán los archivos.
Para ello, siga el procedimiento que se indica a continuación.
**Para proporcionar a la instancia de base de datos de PostgreSQL acceso a Amazon S3 a través de un rol de IAM**
1. Cree una política de IAM.
Esta política concede los permisos de bucket y objeto que permiten a la instancia de base de datos de PostgreSQL acceder a Amazon S3.
Como parte de la creación de esta política, realice los siguientes pasos:
1. Incluya las siguientes acciones necesarias en la política para permitir la transferencia de archivos de la instancia de base de datos de PostgreSQL a un bucket de Amazon S3:
+ `s3:PutObject`
+ `s3:AbortMultipartUpload`
1. Incluye el nombre de recurso de Amazon (ARN) que identifica el bucket de Amazon S3 y los objetos del bucket. El formato del ARN para acceder a Amazon S3 es: `arn:aws:s3:::amzn-s3-demo-bucket/*`
Para obtener información adicional sobre cómo crear una política de IAM para Amazon RDS for PostgreSQL, consulte [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Consulte también el [Tutorial: Crear y asociar su primera política administrada por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) en la *Guía del usuario de IAM*.
El siguiente comando de la AWS CLI crea una política de IAM denominada `rds-s3-export-policy` con estas opciones. Otorga acceso a un bucket denominado *amzn-s3-demo-bucket*.
**aviso**
Le recomendamos que configure la base de datos en una VPC privada que tenga políticas de punto de enlace configuradas para acceder a buckets específicos. Para obtener más información, consulte [Uso de políticas de punto de enlace para Amazon S3](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html#vpc-endpoints-policies-s3) en la Guía del usuario de Amazon VPC.
Recomendamos encarecidamente que no cree una política con acceso a todos los recursos. Este acceso puede representar una amenaza para la seguridad de los datos. Si crea una política que da acceso `S3:PutObject` a todos los recursos mediante `"Resource":"*"`, un usuario con privilegios de exportación puede exportar datos a todos los buckets de su cuenta. Además, el usuario puede exportar datos a *cualquier bucket en el que se pueda escribir públicamente dentro de su región de AWS*.
Después de crear la política, anote el nombre de recurso de Amazon (ARN) de la política. Cuando asocia la política a un rol de IAM, necesita el ARN para realizar un paso posterior.
```
aws iam create-policy --policy-name rds-s3-export-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3export",
"Action": [
"s3:PutObject*",
"s3:ListBucket",
"s3:GetObject*",
"s3:DeleteObject*",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Cree un rol de IAM.
Realiza este paso para que Amazon RDS pueda asumir este rol de IAM en su nombre para obtener acceso a los buckets de Amazon S3. Para obtener más información, consulte [Creación de un rol para delegar permisos a un usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) en la *Guía del usuario de IAM*.
Le recomendamos que utilice las claves de contexto de condición globales de `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` y `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` en las políticas basadas en recursos para limitar los permisos del servicio a un recurso específico. Esta es la forma más eficaz de protegerse contra el [problema del suplente confuso](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
Si utiliza claves de contexto de condición globales y el valor `aws:SourceArn` contiene el ID de cuenta, el valor `aws:SourceAccount` y la cuenta en el valor `aws:SourceArn` deben utilizar el mismo ID de cuenta cuando se utiliza en la misma instrucción de política.
+ Use `aws:SourceArn` si quiere acceso entre servicios para un único recurso.
+ Use `aws:SourceAccount` si quiere permitir que cualquier recurso de esa cuenta se asocie al uso entre servicios.
En la política, asegúrese de utilizar la clave de contexto de condición global `aws:SourceArn` con el ARN completo del recurso. En el siguiente ejemplo se muestra cómo se usa el comando de la AWS CLI para crear un rol denominado `rds-s3-export-role`.
**Example**
Para Linux, macOS o Unix:
```
aws iam create-role \
--role-name rds-s3-export-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Para Windows:
```
aws iam create-role ^
--role-name rds-s3-export-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. Asocie la política de IAM que creó al rol de IAM creado.
El siguiente comando de la AWS CLI asocia la política creada anteriormente al rol denominado `rds-s3-export-role.`. Sustituya `your-policy-arn` por el ARN de la política que ha anotado en un paso anterior.
```
aws iam attach-role-policy --policy-arn your-policy-arn --role-name rds-s3-export-role
```
1. Añada el rol de IAM a la instancia de base de datos. Para ello, utilice la Consola de administración de AWS o la AWS CLI, tal y como se describe a continuación.
## Consola
**Para añadir un rol de IAM para una instancia de base de datos de PostgreSQL utilizando la consola**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Seleccione el nombre de instancia de base de datos de PostgreSQL para mostrar sus detalles.
1. En la pestaña **Connectivity & security (Conectividad y seguridad)**, en la sección **Manage IAM roles (Administrar roles de IAM)**, elija el rol que desee añadir en **Add IAM roles to this instance (Añadir roles de IAM a esta instancia)**.
1. En **Feature (Característica)**, elija **s3Export**.
1. Seleccione **Add role (Añadir rol)**.
## AWS CLI
**Para añadir un rol de IAM para una instancia de base de datos de PostgreSQL utilizando la CLI**
+ Utilice el siguiente comando para añadir el rol a la instancia de base de datos de PostgreSQL denominada `my-db-instance`. Sustituya *`your-role-arn`* por el ARN del rol que ha anotado en el paso anterior. Utilice `s3Export` para el valor de la opción `--feature-name`.
**Example**
Para Linux, macOS o Unix:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Export \
--role-arn your-role-arn \
--region your-region
```
Para Windows:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Export ^
--role-arn your-role-arn ^
--region your-region
```
# Exportación de datos de consulta mediante la función aws\$1s3.query\$1export\$1to\$1s3
Exporte sus datos de PostgreSQL a Amazon S3 llamando a la función [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3).
**Topics**
+ [Requisitos previos](#postgresql-s3-export-examples-prerequisites)
+ [Llamar a aws\$1s3.query\$1export\$1to\$1s3](#postgresql-s3-export-examples-basic)
+ [Exportación a un archivo CSV que utiliza un delimitador personalizado](#postgresql-s3-export-examples-custom-delimiter)
+ [Exportación a un archivo binario con codificación](#postgresql-s3-export-examples-encoded)
## Requisitos previos
Antes de utilizar la función `aws_s3.query_export_to_s3`, asegúrese de completar los siguientes requisitos previos:
+ Instale las extensiones de PostgreSQL necesarias como se describe en [Información general de la exportación de datos a Amazon S3](postgresql-s3-export.md#postgresql-s3-export-overview).
+ Determine a dónde exportar los datos en Amazon S3 como se describe en [Especificación de la ruta del archivo de Amazon S3 a exportar](postgresql-s3-export.md#postgresql-s3-export-file).
+ Tenga cuidado de que la del clúster de base de datos tenga acceso de exportación a Amazon S3 según se describe en [Configuración del acceso a un bucket de Amazon S3](postgresql-s3-export-access-bucket.md).
Los ejemplos siguientes utilizan una tabla de base de datos llamada `sample_table`. Estos ejemplos exportan los datos a un bucket llamado *amzn-s3-demo-bucket*. La tabla y los datos de ejemplo se crean con las siguientes instrucciones SQL en psql.
```
psql=> CREATE TABLE sample_table (bid bigint PRIMARY KEY, name varchar(80));
psql=> INSERT INTO sample_table (bid,name) VALUES (1, 'Monday'), (2,'Tuesday'), (3, 'Wednesday');
```
## Llamar a aws\$1s3.query\$1export\$1to\$1s3
A continuación, se muestran las formas básicas de llamar a la función [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3).
En estos ejemplos se utiliza la variable `s3_uri_1` para identificar una estructura que contiene la información que identifica el archivo de Amazon S3. Utilice la función [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) para crear la estructura.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Aunque los parámetros varían para las dos llamadas a funciones siguientes `aws_s3.query_export_to_s3`, los resultados son los mismos para estos ejemplos. Todas las filas de la tabla `sample_table` se exportan a un bucket llamado *amzn-s3-demo-bucket*.
```
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1');
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1', options :='format text');
```
Los parámetros se describen de la siguiente manera:
+ `'SELECT * FROM sample_table'`: el primer parámetro es una cadena de texto requerida que contiene una consulta SQL. El motor de PostgreSQL ejecuta esta consulta. Los resultados de la consulta se copian en el bucket de S3 identificado en otros parámetros.
+ `:'s3_uri_1'`: este parámetro es una estructura que identifica el archivo de Amazon S3. En este ejemplo se utiliza una variable para identificar la estructura creada anteriormente. En su lugar, puede crear la estructura incluyendo la llamada a la función `aws_commons.create_s3_uri` insertada dentro de la llamada a la función `aws_s3.query_export_to_s3` de la siguiente manera.
```
SELECT * from aws_s3.query_export_to_s3('select * from sample_table',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'sample-filepath', 'us-west-2')
);
```
+ `options :='format text'`: el parámetro `options` es una cadena de texto opcional que contiene argumentos `COPY` de PostgreSQL. El proceso de copia utiliza los argumentos y el formato del comando [COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
Si el archivo especificado no existe en el bucket de Amazon S3, se crea. Si el archivo ya existe, se sobrescribe. La sintaxis para acceder a los datos exportados en Amazon S3 es la siguiente.
```
s3-region://bucket-name[/path-prefix]/file-prefix
```
Las exportaciones más grandes se almacenan en varios archivos, cada uno con un tamaño máximo de aproximadamente 6 GB. Los nombres de archivo adicionales tienen el mismo prefijo de archivo, pero con `_partXX` anexado. `XX` representa 2, luego 3, y así sucesivamente. Por ejemplo, supongamos que especifica la ruta donde almacena los archivos de datos como sigue.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
```
Si la exportación tiene que crear tres archivos de datos, el bucket de Amazon S3 contiene los siguientes archivos de datos.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part2
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part3
```
Para obtener la referencia completa de esta función y formas adicionales de llamarla, consulte [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). Para obtener más información sobre el acceso a archivos en Amazon S3, consulte [Ver un objeto](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) en la *Guía del usuario de Amazon Simple Storage Service*.
## Exportación a un archivo CSV que utiliza un delimitador personalizado
En el ejemplo siguiente se muestra cómo llamar a la función [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) para exportar datos a un archivo que utiliza un delimitador personalizado. En el ejemplo se utilizan argumentos del comando [COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html) para especificar el formato de valor separado por comas (CSV) y un delimitador de dos puntos (:).
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format csv, delimiter $$:$$');
```
## Exportación a un archivo binario con codificación
En el ejemplo siguiente se muestra cómo llamar a la función [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) para exportar datos a un archivo binario que tiene codificación Windows-1253.
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format binary, encoding WIN1253');
```
# Referencia de funciones
**Topics**
+ [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3)
+ [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri)
## aws\$1s3.query\$1export\$1to\$1s3
Exporta un resultado de consulta PostgreSQL a un bucket de Amazon S3. La extensión `aws_s3` proporciona la función `aws_s3.query_export_to_s3`.
Los parámetros obligatorios son `query` y `s3_info`. Definen la consulta que se va a exportar e identifican el bucket de Amazon S3 al que se va a exportar. Un parámetro opcional llamado `options` proporciona la definición de varios parámetros de exportación. Para obtener ejemplos sobre el uso de la función `aws_s3.query_export_to_s3`, consulte [Exportación de datos de consulta mediante la función aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-examples.md).
**Sintaxis**
```
aws_s3.query_export_to_s3(
query text,
s3_info aws_commons._s3_uri_1,
options text,
kms_key text
)
```Parámetros de entrada
*query*
Cadena de texto necesaria que contiene una consulta SQL que ejecuta el motor de PostgreSQL. Los resultados de esta consulta se copian en un bucket de S3 identificado en el parámetro `s3_info`.
*s3\$1info*
Tipo compuesto `aws_commons._s3_uri_1` que contiene la siguiente información sobre el objeto de S3:
+ `bucket`: el nombre del bucket de Amazon S3 que contiene el archivo.
+ `file_path` –: la ruta de Amazon S3 del archivo.
+ `region`: la región de AWS en la que se encuentra el bucket. Para ver una lista de los nombres de regiones de AWS y los valores asociados, consulte [Regiones, zonas de disponibilidad y Local Zones](Concepts.RegionsAndAvailabilityZones.md).
Actualmente, este valor debe ser la misma región de AWS que la del e instancia de base de datos de exportación. El valor predeterminado es la región de AWS del e instancia de base de datos de exportación.
Para crear una estructura compuesta `aws_commons._s3_uri_1`, consulte la función [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri).
*options*
Cadena de texto opcional que contiene argumentos para el comando `COPY` de PostgreSQL. Estos argumentos especifican cómo se copian los datos cuando se exportan. Para obtener más detalles, consulte la [documentación de COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
Una cadena de texto opcional que contiene la clave KMS administrada por el cliente del bucket de S3 al que se exportan los datos.
### Parámetros de entrada alternativos
Como ayuda en las pruebas, puede utilizar un conjunto de parámetros expandido en lugar del parámetro `s3_info`. A continuación, se incluyen otras variaciones de la sintaxis de la función `aws_s3.query_export_to_s3`.
En lugar de utilizar el parámetro `s3_info` para identificar un archivo de Amazon S3, utilice la combinación de los parámetros `bucket`, `file_path` y `region`.
```
aws_s3.query_export_to_s3(
query text,
bucket text,
file_path text,
region text,
options text,
kms_key text
)
```
*query*
Cadena de texto necesaria que contiene una consulta SQL que ejecuta el motor de PostgreSQL. Los resultados de esta consulta se copian en un bucket de S3 identificado en el parámetro `s3_info`.
*bucket*
Cadena de texto obligatoria que incluye el nombre del bucket de Amazon S3 que contiene el archivo.
*file\$1path*
Cadena de texto requerida que contiene la ruta de Amazon S3 del archivo.
*region*
Cadena de texto opcional que contiene la región de AWS en la que se encuentra el bucket. Para ver una lista de los nombres de regiones de AWS y los valores asociados, consulte [Regiones, zonas de disponibilidad y Local Zones](Concepts.RegionsAndAvailabilityZones.md).
Actualmente, este valor debe ser la misma región de AWS que la del e instancia de base de datos de exportación. El valor predeterminado es la región de AWS del e instancia de base de datos de exportación.
*options*
Cadena de texto opcional que contiene argumentos para el comando `COPY` de PostgreSQL. Estos argumentos especifican cómo se copian los datos cuando se exportan. Para obtener más detalles, consulte la [documentación de COPY de PostgreSQL](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
Una cadena de texto opcional que contiene la clave KMS administrada por el cliente del bucket de S3 al que se exportan los datos.
### Parámetros de salida
```
aws_s3.query_export_to_s3(
OUT rows_uploaded bigint,
OUT files_uploaded bigint,
OUT bytes_uploaded bigint
)
```
*rows\$1uploaded*
Número de filas de tabla que se cargaron correctamente a Amazon S3 para la consulta dada.
*files\$1uploaded*
El número de archivos cargados en Amazon S3. Los archivos se crean en tamaños de aproximadamente 6 GB. Cada archivo adicional creado tiene `_partXX` anexado al nombre. `XX` representa 2, luego 3, y así sucesivamente según sea necesario.
*bytes\$1uploaded*
El número total de bytes cargados a Amazon S3.
### Ejemplos
```
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2','format text');
```
## aws\$1commons.create\$1s3\$1uri
Crea una estructura `aws_commons._s3_uri_1` para contener la información de archivos de Amazon S3. Debe utilizar los resultados de la función `aws_commons.create_s3_uri` en el parámetro `s3_info` de la función [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3). Para ver un ejemplo de uso de la función `aws_commons.create_s3_uri`, consulte [Especificación de la ruta del archivo de Amazon S3 a exportar](postgresql-s3-export.md#postgresql-s3-export-file).
**Sintaxis**
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```Parámetros de entrada
*Bucket de*
Cadena de texto obligatoria que contiene el nombre del bucket de Amazon S3 del archivo.
*file\$1path*
Cadena de texto requerida que contiene la ruta de Amazon S3 del archivo.
*region*
Cadena de texto obligatoria que contiene la región de AWS en la que se encuentra el archivo. Para ver una lista de los nombres de regiones de AWS y los valores asociados, consulte [Regiones, zonas de disponibilidad y Local Zones](Concepts.RegionsAndAvailabilityZones.md).
# Solución de errores de acceso a Amazon S3
Si se producen problemas de conexión al intentar exportar los datos a Amazon S3, confirme primero que las reglas de acceso saliente del grupo de seguridad de la VPC asociado a la instancia de base de datos permitan la conectividad de red. En concreto, el grupo de seguridad debe tener una regla que permita que la instancia de base de datos envíe tráfico TCP al puerto 443 y a cualquier dirección IPv4 (0.0.0.0/0). Para obtener más información, consulte [Proporcionar acceso a la instancia de base de datos en la VPC mediante la creación de un grupo de seguridad](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup).
También consulte las recomendaciones siguientes:
+ [Solución de problemas de identidades y accesos en Amazon RDS](security_iam_troubleshoot.md)
+ [Solución de problemas de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) en la *Guía del usuario de Amazon Simple Storage Service*
+ [Solución de problemas de Amazon S3 e IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) en la *Guía del usuario de IAM*
# Invocar una función de AWS Lambda desde una instancia de base de datos de RDS for PostgreSQL
AWS Lambda es un servicio de computación controlado por eventos que permite ejecutar código sin aprovisionar ni administrar servidores. Está disponible para su uso con muchos servicios de AWS, incluidos RDS for PostgreSQL. Por ejemplo, puede utilizar funciones de Lambda para procesar notificaciones de eventos desde una base de datos o para cargar datos desde archivos cada vez que se carga un nuevo archivo en Simple Storage Service (Amazon S3). Para obtener más información sobre Lambda, consulte [¿Qué es AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) en la *Guía para desarrolladores de AWS Lambda.*
**nota**
La invocación de una función de AWS Lambda se admite en estas versiones de RDS for PostgreSQL:
Todas las versiones 18 de PostgreSQL
Todas las versiones 17 de PostgreSQL
Todas las versiones 16 de PostgreSQL
Todas las versiones 15 de PostgreSQL
PostgreSQL 14.1 y versiones secundarias posteriores
PostgreSQL 13.2 y versiones secundarias posteriores
PostgreSQL 12.6 y versiones secundarias posteriores
La configuración de RDS for PostgreSQL para trabajar con las funciones de Lambda es un proceso de varios pasos que incluye AWS Lambda, IAM, su VPC y su instancia de base de datos de RDS for PostgreSQL. A continuación, se muestran resúmenes de los pasos necesarios.
Para obtener más información acerca de las funciones de Lambda, consulte [Introducción a Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) y [Conceptos básicos de AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-foundation.html) en la *Guía para desarrolladores de AWS Lambda*.
**Topics**
+ [Paso 1: configure la instancia de base de datos de RDS para PostgreSQL para conexiones salientes a AWS Lambda.](#PostgreSQL-Lambda-network)
+ [Paso 2: configure IAM para su instancia de base de datos de RDS para PostgreSQL y AWS Lambda.](#PostgreSQL-Lambda-access)
+ [Paso 3: instale la extensión de `aws_lambda` para una instancia de base de datos de RDS para PostgreSQL](#PostgreSQL-Lambda-install-extension)
+ [Paso 4: utilice las funciones auxiliares de Lambda con su instancia de base de datos de RDS for PostgreSQL (Opcional)](#PostgreSQL-Lambda-specify-function)
+ [Paso 5: invoque una función de Lambda desde su instancia de base de datos de RDS for PostgreSQL](#PostgreSQL-Lambda-invoke)
+ [Paso 6: Conceder permiso a otros usuarios para invocar las funciones de Lambda](#PostgreSQL-Lambda-grant-users-permissions)
+ [Ejemplos: invoque las funciones de Lambda desde su instancia de base de datos de RDS for PostgreSQL](PostgreSQL-Lambda-examples.md)
+ [Mensajes de error de la función de Lambda](PostgreSQL-Lambda-errors.md)
+ [Referencia de parámetros y funciones de AWS Lambda](PostgreSQL-Lambda-functions.md)
## Paso 1: configure la instancia de base de datos de RDS para PostgreSQL para conexiones salientes a AWS Lambda.
Las funciones de Lambda siempre se ejecutan dentro de una Amazon VPC propiedad del servicio de AWS Lambda. Lambda aplica acceso a la red y reglas de seguridad a esta VPC y mantiene y supervisa la VPC automáticamente. Su instancia de base de datos de RDS for PostgreSQL envía tráfico de red a la VPC del servicio de Lambda. La manera en que se configura esto depende de si la instancia de base de datos es pública o privada.
+ **Instancia de base de datos de RDS for PostgreSQL pública**: una instancia de base de datos es pública si se encuentra en una subred pública de la VPC y si la propiedad “PubliclyAccessible” de la instancia es `true`. Para encontrar el valor de esta propiedad, puede utilizar el comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) de AWS CLI. O, si lo desea, puede utilizar Consola de administración de AWS para abrir la pestaña **Connectivity & security** (Conectividad y seguridad) y verificar que **Publicly accessible** (Acceso público) sea **Yes** (Sí). Para comprobar que la instancia está en la subred pública de la VPC, puede utilizar la Consola de administración de AWS o la AWS CLI.
Para configurar el acceso a Lambda, utilice la Consola de administración de AWS o la AWS CLI para crear una regla de salida en el grupo de seguridad de la VPC. La regla de salida especifica que TCP puede utilizar el puerto 443 para enviar paquetes a cualquier dirección IPv4 (0.0.0.0/0).
+ **Clúster Instancia de base de datos de RDS PostgreSQL**: en este caso, la propiedad “PubliclyAccessible” de la instancia es `false` o está en una subred privada. Para permitir el funcionamiento de la instancia con Lambda, puede utilizar una puerta de enlace de traducción de direcciones de red (NAT). Para obtener más información, consulte [Puerta de enlace NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html). O bien, puede configurar su VPC con un punto de conexión de VPC para Lambda. Para obtener más información, consulte [Puntos de enlace de la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) en la *Guía del usuario de Amazon VPC*. El punto de conexión responde a las llamadas hechas por su instancia de base de datos de RDS para PostgreSQL a las funciones de Lambda. El punto de conexión de VPC utiliza su propia resolución DNS privada. RDS for PostgreSQL no puede utilizar el punto de conexión de VPC de Lambda hasta que cambie el valor de `rds.custom_dns_resolution` de su valor predeterminado 0 (no habilitado) a 1. Para ello:
+ Cree un grupo de parámetros de base de datos personalizado.
+ Cambie el valor del parámetro `rds.custom_dns_resolution` del valor predeterminado de `0` a `1`.
+ Modifique la instancia de base de datos para usar el grupo de parámetros de base de datos personalizado.
+ Reinicie la instancia para que el parámetro modificado tenga efecto.
La VPC ahora puede interactuar con la VPC de AWS Lambda en el ámbito de red. A continuación, debe configurar los permisos mediante IAM.
## Paso 2: configure IAM para su instancia de base de datos de RDS para PostgreSQL y AWS Lambda.
La invocación de funciones de Lambda desde su instancia de base de datos de RDS for PostgreSQL requiere ciertos privilegios. Para configurar los privilegios necesarios, recomendamos crear una política de IAM que permita invocar funciones de Lambda, asignarla a un rol y, a continuación, aplicar el rol a su instancia de base de datos. Este enfoque da a la instancia de base de datos privilegios para invocar la función de Lambda especificada en su nombre. En los pasos siguientes se muestra cómo hacer esto con AWS CLI.
**Para configurar los permisos de IAM para utilizar su instancia de Amazon RDS con Lambda, lleve a cabo el siguiente procedimiento.**
1. Utilice el comando [create-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-policy.html) de la AWS CLI para crear una política de IAM que permita a su instancia de base de datos de RDS para PostgreSQL invocar la función de Lambda especificada. (El ID de instrucción [Sid] es una descripción opcional de la instrucción de política y no afecta al uso). Esta política proporciona a su instancia de base de datos los permisos mínimos necesarios para invocar la función de Lambda especificada.
```
aws iam create-policy --policy-name rds-lambda-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:aws-region:444455556666:function:my-function"
}
]
}'
```
También puede utilizar la política predefinida de `AWSLambdaRole` que le permite invocar cualquiera de las funciones de Lambda. Para obtener más información, consulte [Políticas de IAM basadas en identidades para Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#access-policy-examples-aws-managed).
1. Utilice el comando de la AWS CLI [create-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html) para crear un rol de IAM que la política pueda asumir en tiempo de ejecución.
```
aws iam create-role --role-name rds-lambda-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
1. Aplique la política al rol mediante el comando [attach-role-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-role-policy.html) de AWS CLI.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::444455556666:policy/rds-lambda-policy \
--role-name rds-lambda-role --region aws-region
```
1. Aplique el rol a su instancia de base de datos de RDS para PostgreSQL mediante el comando [add-role-to-db-instance](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/add-role-to-db-instance.html) de la AWS CLI. En este último paso se permite a los usuarios de bases de datos de su instancia de base de datos invocar funciones de Lambda.
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-instance-name \
--feature-name Lambda \
--role-arn arn:aws:iam::444455556666:role/rds-lambda-role \
--region aws-region
```
Con la VPC y las configuraciones de IAM completadas, ahora puede instalar la extensión de `aws_lambda`. (Tenga en cuenta que puede instalar la extensión en cualquier momento, pero hasta que no configure la compatibilidad con VPC y los privilegios de IAM correctos, la extensión de `aws_lambda` no agrega nada a las capacidades de su instancia de base de datos de RDS for PostgreSQL.
## Paso 3: instale la extensión de `aws_lambda` para una instancia de base de datos de RDS para PostgreSQL
Para utilizar AWS Lambda con su instancia de base de datos de RDS para PostgreSQL, agregue la extensión de PostgreSQL de `aws_lambda` a su instancia de base de datos de RDS para PostgreSQL. Esta extensión proporciona a su instancia de base de datos de RDS for PostgreSQL la capacidad de llamar a funciones de Lambda desde PostgreSQL.
**Para instalar la extensión de `aws_lambda` en su instancia de base de datos de RDS para PostgreSQL**
Utilice la línea de comandos `psql` de PostgreSQL o la herramienta pgAdmin para conectarse a su instancia de base de datos de RDS for PostgreSQL.
1. Conéctese a su instancia de base de datos de RDS for PostgreSQL como usuario con privilegios de `rds_superuser`. El valor predeterminado de usuario de `postgres` se muestra en el ejemplo.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Instale la extensión de `aws_lambda`. La extensión de `aws_commons` también es necesaria. Proporciona funciones auxiliares para `aws_lambda` y muchas otras extensiones de Aurora para PostgreSQL. Si aún no está en su instancia de base de datos de RDS for PostgreSQL, se instala con `aws_lambda` como se muestra a continuación.
```
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
La extensión de `aws_lambda` se instala en su instancia de base de datos Ahora puede crear estructuras de conveniencia para invocar las funciones de Lambda.
## Paso 4: utilice las funciones auxiliares de Lambda con su instancia de base de datos de RDS for PostgreSQL (Opcional)
Puede utilizar las funciones auxiliares en la extensión de `aws_commons` para preparar entidades que puede invocar con más facilidad desde PostgreSQL. Para ello, debe tener la siguiente información sobre las funciones de Lambda:
+ **Nombre de la función**: el nombre, el nombre de recurso de Amazon (ARN), la versión o el alias de la función de Lambda. La política de IAM creada en [Paso 2: configure IAM para su instancia y Lambda](#PostgreSQL-Lambda-access) requiere el ARN, por lo que recomendamos utilizar el ARN de su función.
+ **Región de AWS**: (Opcional) la región de AWS en la que se encuentra la función de Lambda si no se encuentra en la misma región que su instancia de base de datos de RDS for PostgreSQL.
Para mantener la información del nombre de la función Lambda, utilice la función [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn). Esta función auxiliar crea una estructura compuesta de `aws_commons._lambda_function_arn_1` con los detalles necesarios para la función de invocación. A continuación, encontrará tres enfoques alternativos para configurar esta estructura compuesta.
```
SELECT aws_commons.create_lambda_function_arn(
'my-function',
'aws-region'
) AS aws_lambda_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'111122223333:function:my-function',
'aws-region'
) AS lambda_partial_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'arn:aws:lambda:aws-region:111122223333:function:my-function'
) AS lambda_arn_1 \gset
```
Cualquiera de estos valores se puede utilizar en las llamadas a la función [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). Para ver ejemplos, consulte [Paso 5: invoque una función de Lambda desde su instancia de base de datos de RDS for PostgreSQL](#PostgreSQL-Lambda-invoke).
## Paso 5: invoque una función de Lambda desde su instancia de base de datos de RDS for PostgreSQL
La función `aws_lambda.invoke` se comporta de forma sincrónica o asíncrona, según `invocation_type`. Las dos alternativas para este parámetro son `RequestResponse` (el valor predeterminado) y `Event`, como se muestra a continuación.
+ **`RequestResponse`**: este tipo de invocación es *sincrónico*. Es el comportamiento predeterminado cuando la llamada se hace sin especificar un tipo de invocación. La carga de respuesta incluye los resultados de la función `aws_lambda.invoke`. Utilice este tipo de invocación cuando el flujo de trabajo requiera recibir los resultados de la función de Lambda antes de continuar.
+ **`Event`**: este tipo de invocación es *asíncrono*. La respuesta no incluye una carga que contenga resultados. Utilice este tipo de invocación cuando el flujo de trabajo no necesite un resultado de la función de Lambda para continuar con el procesamiento.
Como simple prueba de la configuración, puede conectarse a la instancia de base de datos mediante `psql` e invocar una función de ejemplo desde la línea de comandos. Supongamos que tiene una de las funciones básicas configuradas en su servicio Lambda, como la sencilla función de Python que se muestra en la siguiente captura de pantalla.
![\[Ejemplo de función de Lambda de ejemplo que se muestra en AWS CLI para AWS Lambda.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/lambda_simple_function.png)
**Para invocar una función de ejemplo**
1. Conéctese a la instancia de base de datos con `psql` o pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Invoque la función mediante su ARN.
```
SELECT * from aws_lambda.invoke(aws_commons.create_lambda_function_arn('arn:aws:lambda:aws-region:444455556666:function:simple', 'us-west-1'), '{"body": "Hello from Postgres!"}'::json );
```
La respuesta tiene el siguiente aspecto.
```
status_code | payload | executed_version | log_result
-------------+-------------------------------------------------------+------------------+------------
200 | {"statusCode": 200, "body": "\"Hello from Lambda!\""} | $LATEST |
(1 row)
```
Si el intento de invocación no se lleva a cabo correctamente, consulte [Mensajes de error de la función de Lambda](PostgreSQL-Lambda-errors.md).
## Paso 6: Conceder permiso a otros usuarios para invocar las funciones de Lambda
En este punto de los procedimientos, solo usted como `rds_superuser` puede invocar las funciones de Lambda. Para permitir que otros usuarios puedan invocar cualquier función que haya creado usted, deberá otorgarles permiso.
**Para otorgar permiso para invocar una función de Lambda**
1. Conéctese a la instancia de base de datos con `psql` o pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Ejecute los siguientes comandos SQL:
```
postgres=> GRANT USAGE ON SCHEMA aws_lambda TO db_username;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA aws_lambda TO db_username;
```
# Ejemplos: invoque las funciones de Lambda desde su instancia de base de datos de RDS for PostgreSQL
A continuación, puede encontrar varios ejemplos de llamada a la función de [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). La mayoría de ejemplos utilizan la estructura compuesta `aws_lambda_arn_1` que se crea en [Paso 4: utilice las funciones auxiliares de Lambda con su instancia de base de datos de RDS for PostgreSQL (Opcional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) para simplificar la transferencia de los detalles de la función. Para obtener un ejemplo de invocación asincrónica, consulte [Ejemplo: invocación asincrónica (Event) de funciones de Lambda](#PostgreSQL-Lambda-Event). El resto de ejemplos enumerados utilizan la invocación sincrónica.
Para obtener más información acerca de los tipos de invocación de Lambda, consulte [Invocación de funciones de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html) en la *Guía para desarrolladores de AWS Lambda*. Para obtener más información acerca de `aws_lambda_arn_1`, consulte [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn).
**Topics**
+ [Ejemplo: invocación sincrónica (RequestResponse) de funciones de Lambda](#PostgreSQL-Lambda-RequestResponse)
+ [Ejemplo: invocación asincrónica (Event) de funciones de Lambda](#PostgreSQL-Lambda-Event)
+ [Ejemplo: captura del registro de ejecución de Lambda en una respuesta de función](#PostgreSQL-Lambda-log-response)
+ [Ejemplo: inclusión del contexto del cliente en una función Lambda](#PostgreSQL-Lambda-client-context)
+ [Ejemplo: invocación de una versión específica de una función de Lambda](#PostgreSQL-Lambda-function-version)
## Ejemplo: invocación sincrónica (RequestResponse) de funciones de Lambda
Lo que sigue son dos ejemplos de una invocación de función de Lambda sincrónica. Los resultados de estas llamadas de funciones de `aws_lambda.invoke` son iguales.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
```
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse');
```
Los parámetros se describen de la siguiente manera:
+ `:'aws_lambda_arn_1'`: este parámetro identifica la estructura compuesta creada en [Paso 4: utilice las funciones auxiliares de Lambda con su instancia de base de datos de RDS for PostgreSQL (Opcional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function), con la función auxiliar de `aws_commons.create_lambda_function_arn`. También puede crear esta estructura en línea dentro de su llamada de `aws_lambda.invoke` de la siguiente manera.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function', 'aws-region'),
'{"body": "Hello from Postgres!"}'::json
);
```
+ `'{"body": "Hello from PostgreSQL!"}'::json` – La carga útil JSON que se va a pasar a la función Lambda.
+ `'RequestResponse'` – El tipo de invocación Lambda.
## Ejemplo: invocación asincrónica (Event) de funciones de Lambda
Lo que sigue es un ejemplo de una invocación de función asincrónica Lambda. El tipo de invocación `Event` programa la invocación de la función Lambda con la carga útil de entrada especificada y regresa inmediatamente. Utilice el tipo de invocación `Event` en ciertos flujos de trabajo que no dependen de los resultados de la función Lambda.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'Event');
```
## Ejemplo: captura del registro de ejecución de Lambda en una respuesta de función
Puede incluir los últimos 4 KB del registro de ejecución en la respuesta de función mediante el parámetro `log_type` en su llamada a funciones de `aws_lambda.invoke`. De forma predeterminada, este parámetro se establece en `None`, pero puede especificar `Tail` para capturar los resultados del registro de ejecución de Lambda en la respuesta, como se muestra a continuación.
```
SELECT *, select convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Establezca el parámetro [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) de la función `log_type` en `Tail` para incluir el registro de ejecución en la respuesta. El valor predeterminado para el parámetro `log_type` es `None`.
El `log_result` que se devuelve es una cadena codificada `base64`. Puede decodificar el contenido utilizando una combinación de las funciones `decode` y `convert_from` PostgreSQL.
Para obtener más información acerca de `log_type`, consulte [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Ejemplo: inclusión del contexto del cliente en una función Lambda
La función `aws_lambda.invoke` tiene un parámetro `context` que puede utilizar para pasar la información por separado de la carga, como se muestra a continuación.
```
SELECT *, convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Para incluir el contexto del cliente, utilice un objeto JSON para el parámetro [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) de la función `context`.
Para obtener más información sobre los parámetros de `context`, consulte la referencia de [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Ejemplo: invocación de una versión específica de una función de Lambda
Se puede especificar una versión concreta de una función de Lambda mediante el parámetro `qualifier` con la llamada de `aws_lambda.invoke`. A continuación, encontrará información sobre el ejemplo que hace esto mediante `'custom_version'` como alias de la versión.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'None', NULL, 'custom_version');
```
Además, puede proporcionar un calificador de función de Lambda con los detalles del nombre de función en su lugar de la siguiente manera.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function:custom_version', 'us-west-2'),
'{"body": "Hello from Postgres!"}'::json);
```
Para obtener más información acerca de `qualifier` y otros parámetros, consulte la referencia de [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
# Mensajes de error de la función de Lambda
En la siguiente lista encontrará información sobre los mensajes de error, con posibles causas y soluciones.
+ **Problemas de configuración de la VPC**
Los problemas de configuración de la VPC pueden generar los siguientes mensajes de error al intentar conectarse:
```
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'Unable to connect to endpoint'.
CONTEXT: SQL function "invoke" statement 1
```
Una causa común de este error es configurar erróneamente el grupo de seguridad de la VPC. Asegúrese de tener abierta una regla de salida para TCP en el puerto 443 de su grupo de seguridad de la VPC para que la VPC pueda conectarse a la VPC de Lambda.
Si la instancia de base de datos es privada, verifique la configuración de DNS privada de la VPC. Asegúrese de establecer el parámetro de `rds.custom_dns_resolution` en 1 y configure AWS PrivateLink tal como se describe en [Paso 1: configure la instancia de base de datos de RDS para PostgreSQL para conexiones salientes a AWS Lambda.](PostgreSQL-Lambda.md#PostgreSQL-Lambda-network). Para obtener más información, consulte [Puntos de conexión de VPC de la interfaz (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns).
+ **Falta de permisos necesarios para invocar funciones de Lambda**
Si ve alguno de los siguientes mensajes de error, significa que el usuario (rol) que invoca la función no tiene los permisos adecuados.
```
ERROR: permission denied for schema aws_lambda
```
```
ERROR: permission denied for function invoke
```
Se deben otorgar permisos específicos a un usuario (rol) para que pueda invocar funciones de Lambda. Para obtener más información, consulte [Paso 6: Conceder permiso a otros usuarios para invocar las funciones de Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-grant-users-permissions).
+ **Gestión incorrecta de errores en las funciones de Lambda**
Si una función Lambda lanza una excepción durante el procesamiento de la solicitud, `aws_lambda.invoke` se produce un error de PostgreSQL como el siguiente.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
ERROR: lambda invocation failed
DETAIL: "arn:aws:lambda:us-west-2:555555555555:function:my-function" returned error "Unhandled", details: "".
```
Asegúrese de controlar los errores en las funciones de Lambda o en la aplicación de PostgreSQL.
# Referencia de parámetros y funciones de AWS Lambda
A continuación, se presenta la referencia de las funciones y parámetros que se pueden utilizar para invocar Lambda con RDS para PostgreSQL.
**Topics**
+ [aws\$1lambda.invoke](#aws_lambda.invoke)
+ [aws\$1commons.create\$1lambda\$1function\$1arn](#aws_commons.create_lambda_function_arn)
+ [Parámetros de aws\$1lambda](#aws_lambda.parameters)
## aws\$1lambda.invoke
Ejecuta una Lambda función destinada a un de datos RDS para la instancia de base de datos PostgreSQL.
Para obtener más detalles acerca de la invocación de funciones de Lambda, consulte también [Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) en la *guía para desarrolladores de AWS Lambda*.
**Sintaxis**
------
#### [ JSON ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSON,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSON,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
------
#### [ JSONB ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSONB,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSONB,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT
)
```
------Parámetros de entrada
**function\$1name**
El nombre de identificación de la función Lambda. El valor puede ser el nombre de la función, un ARN o un ARN parcial. Para obtener una lista de los formatos posibles, consulte los [formatos de nombres de función de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestParameters) en la *guía para desarrolladores de AWS Lambda*.
*payload*
La entrada de la función Lambda. El formato puede ser JSON o JSONB. Para obtener más información, consulte la documentación de PostgreSQL sobre [Tipos de JSON](https://www.postgresql.org/docs/current/datatype-json.html).
*region*
(Opcional) La región Lambda de la función. De forma predeterminada, RDS resuelve la región de AWS desde el ARN completo en `function_name` o utiliza la región de instancia de base de datos de RDS for PostgreSQL. Si este valor de región entra en conflicto con el proporcionado en el ARN `function_name`, se genera un error.
*invocation\$1type*
Tipo de invocación de la función Lambda. El valor distingue entre mayúsculas y minúsculas. Entre los valores posibles se incluyen:
+ `RequestResponse` – El valor de tiempo de espera predeterminado. Este tipo de invocación para una función Lambda es sincrónica y devuelve una carga útil de respuesta en el resultado. Utilice el tipo de invocación de `RequestResponse` cuando el flujo de trabajo dependa de recibir el resultado de la función Lambda inmediatamente.
+ `Event` – Este tipo de invocación para una función Lambda es asincrónica y regresa inmediatamente sin una carga útil devuelta. Utilice el tipo de invocación `Event` cuando no necesite resultados de la función Lambda antes de que el flujo de trabajo avance.
+ `DryRun` – Este tipo de invocación prueba el acceso sin ejecutar la función Lambda.
*log\$1type*
El tipo de registro Lambda que se va a devolver en el parámetro `log_result` de salida. El valor distingue entre mayúsculas y minúsculas. Entre los valores posibles se incluyen:
+ Final – El parámetro de salida `log_result` devuelto incluirá los últimos 4 KB del registro de ejecución.
+ Ninguno – No se devuelve ninguna información de registro Lambda.
*context*
Contexto del cliente en formato JSON o JSONB. Los campos que se van a utilizar incluyen `custom` y `env`.
*Calificador*
Un calificador que identifica la versión de una función Lambda que se va a invocar. Si este valor entra en conflicto con uno proporcionado en el ARN `function_name`, se genera un error.Parámetros de salida
*status\$1code*
Un código de respuesta de estado HTTP. Para obtener más información, consulte los [elementos de respuesta de invocación de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseElements) en la *guía para desarrolladores de AWS Lambda*.
*payload*
La información devuelta de la función Lambda que se ejecutó. El formato está en JSON o JSONB.
*executed\$1version*
La versión de la función Lambda que se ejecutó.
*log\$1result*
La información del registro de ejecución devuelta si el valor `log_type` es `Tail` cuando se invocó la función Lambda. El resultado contiene los últimos 4 KB del registro de ejecución codificado en Base64.
## aws\$1commons.create\$1lambda\$1function\$1arn
Crea una estructura `aws_commons._lambda_function_arn_1` para contener la información del nombre de función Lambda. Puede utilizar los resultados de la función `aws_commons.create_lambda_function_arn` en el parámetro `function_name` de la función [aws\$1lambda.invoke](#aws_lambda.invoke) aws\$1lambda.invoke.
**Sintaxis**
```
aws_commons.create_lambda_function_arn(
function_name TEXT,
region TEXT DEFAULT NULL
)
RETURNS aws_commons._lambda_function_arn_1
```Parámetros de entrada
*function\$1name*
Una cadena de texto obligatoria que contiene el nombre de la función Lambda. El valor puede ser un nombre de función, un ARN parcial o un ARN completo.
*region*
Una cadena de texto opcional que contiene la región de AWS en la que se encuentra la función de Lambda. Para ver una lista de los nombres de regiones de y los valores asociados, consulte [Regiones, zonas de disponibilidad y Local Zones](Concepts.RegionsAndAvailabilityZones.md).
## Parámetros de aws\$1lambda
En esta tabla verá los parámetros asociados a la función `aws_lambda`.
| Parámetro | Descripción |
| --- | --- |
| `aws_lambda.connect_timeout_ms` | Se trata de un parámetro dinámico y establece el tiempo máximo de espera durante la conexión a AWS Lambda. El valor predeterminado es `1000`. Los valores permitidos para este parámetro son de 1 a 900 000. |
| `aws_lambda.request_timeout_ms` | Se trata de un parámetro dinámico y establece el tiempo máximo de espera a la respuesta de AWS Lambda. El valor predeterminado es `3000`. Los valores permitidos para este parámetro son de 1 a 900 000. |
| `aws_lambda.endpoint_override` | Especifica el punto de conexión que se puede utilizar para conectarse a AWS Lambda. Una cadena vacía selecciona el punto de conexión de AWS Lambda predeterminado para la región. Debe reiniciar la base de datos para que se aplique el cambio en este parámetro estático. |
# Tareas comunes de los administradores de base de datos (DBA) para Amazon RDS para PostgreSQL
Los administradores de bases de datos (DBA) realizan una variedad de tareas cuando administran una instancia de base de datos de Amazon RDS para PostgreSQL. Si ya está familiarizado con PostgreSQL, debe conocer algunas de las diferencias importantes entre ejecutar PostgreSQL en su hardware y RDS para PostgreSQL. Por ejemplo, debido a que es un servicio administrado, Amazon RDS no permite el acceso mediante shell a las instancias de base de datos. Eso significa que no tiene acceso directo a `pg_hba.conf` y a otros archivos de configuración. En el caso de RDS para PostgreSQL, los cambios que normalmente se realizan en el archivo de configuración de PostgreSQL de una instancia local se realizan en un grupo de parámetros de base de datos personalizado asociado a la instancia de base de datos de RDS para PostgreSQL. Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Tampoco puede acceder a los archivos de registro de la misma manera que lo hace con una instancia de PostgreSQL en las instalaciones. Para obtener más información acerca de los registros, consulte [Archivos de registro de base de datos de RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
Otro ejemplo, no tiene acceso a la cuenta de `superuser` de PostgreSQL. En RDS para PostgreSQL, el rol `rds_superuser` es el más privilegiado, y se concede a `postgres` en el momento de la configuración. Ya sea que esté familiarizado con el uso de PostgreSQL en las instalaciones o completamente nuevo en RDS para PostgreSQL, le recomendamos que aprenda el rol `rds_superuser` y cómo trabajar con roles, usuarios, grupos y permisos. Para obtener más información, consulte [Descripción de los roles y permisos de PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Las siguientes son algunas tareas comunes de DBA para RDS for PostgreSQL.
**Topics**
+ [Intercalaciones admitidas en RDS para PostgreSQL](PostgreSQL-Collations.md)
+ [Descripción de los roles y permisos de PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Gestión de conexiones inactivas en PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [Uso de autovacuum de PostgreSQL en Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Administración de recuentos de objetos altos en Amazon RDS para PostgreSQL](PostgreSQL.HighObjectCount.md)
+ [Administración de la contención de TOAST OID en Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [Uso de mecanismos de registro admitidos por RDS for PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Administración de archivos temporales con PostgreSQL](PostgreSQL.ManagingTempFiles.md)
+ [Uso de pgBadger para el análisis de registros con PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [Uso de PGSnapper para supervisar PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [Gestión de conversiones personalizadas en RDS para PostgreSQL](PostgreSQL.CustomCasts.md)
+ [Prácticas recomendadas para consultas paralelas en RDS para PostgreSQL](PostgreSQL.ParallelQueries.md)
+ [Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Intercalaciones admitidas en RDS para PostgreSQL
Las intercalaciones son un conjunto de reglas que determinan cómo se ordenan y comparan las cadenas de caracteres almacenadas en la base de datos. Las intercalaciones desempeñan un papel fundamental en el sistema de computación y se incluyen como parte del sistema operativo. Las intercalaciones cambian con el tiempo cuando se añaden nuevos caracteres a los lenguajes o cuando cambian las reglas de ordenación.
Las bibliotecas de intercalaciones definen reglas y algoritmos específicos para una intercalación. Las bibliotecas de intercalaciones más populares utilizadas en PostgreSQL son GNU C (glibc) y los componentes de internacionalización de Unicode (ICU). De forma predeterminada, RDS para PostgreSQL utiliza la intercalación glibc, que incluye ordenaciones de caracteres Unicode para secuencias de caracteres de varios bytes.
Al crear una nueva instancia de base de datos en RDS para PostgreSQL, se comprueba en el sistema operativo la intercalación disponible. Los parámetros de PostgreSQL del comando `CREATE DATABASE` `LC_COLLATE` y `LC_CTYPE` se utilizan para especificar una intercalación, que es la intercalación predeterminada en esa base de datos. Como alternativa, también puede utilizar el parámetro `LOCALE` en `CREATE DATABASE` para establecer estos parámetros. Esto determina la intercalación predeterminada de las cadenas de caracteres de la base de datos y las reglas para clasificar los caracteres como letras, números o símbolos. También puede elegir una intercalación para utilizarla en una columna, un índice o una consulta.
RDS para PostgreSQL depende de la biblioteca glibc del sistema operativo para admitir las intercalaciones. La instancia de RDS para PostgreSQL se actualiza periódicamente con las versiones más recientes del sistema operativo. Estas actualizaciones a veces incluyen una versión más reciente de la biblioteca glibc. En raras ocasiones, las versiones más recientes de glibc cambian la ordenación o la intercalación de algunos caracteres, lo que puede provocar que los datos se ordenen de forma diferente o generar entradas de índice no válidas. Si durante una actualización detecta problemas de ordenación para la intercalación, es posible que tenga que volver a generar los índices.
Para reducir el posible impacto de las actualizaciones de glibc, RDS para PostgreSQL incluye ahora una biblioteca de intercalaciones predeterminada independiente. Esta biblioteca de intercalaciones está disponible en RDS para PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23 y versiones secundarias posteriores. Es compatible con glibc 2.26-59.amzn2 y proporciona estabilidad en la ordenación para evitar resultados de consultas incorrectos.
# Descripción de los roles y permisos de PostgreSQL
Al crear una instancia de base de datos de RDS for PostgreSQL utilizando la Consola de administración de AWS, se crea una cuenta de administrador al mismo tiempo. De forma predeterminada su nombre es `postgres`, tal y como se muestra en la siguiente captura de pantalla:
![\[La identidad de inicio de sesión predeterminada para las credenciales en la página Create database (Crear base de datos) es postgres.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Puede elegir otro nombre en lugar de aceptar el valor predeterminado (`postgres`). Si lo hace, el nombre que elija debe empezar por una letra y tener entre 1 y 16 caracteres alfanuméricos. Por simplicidad, nos referimos a esta cuenta de usuario principal por su valor predeterminado (`postgres`) en toda esta guía.
Si utiliza `create-db-instance` de la AWS CLI en lugar de la Consola de administración de AWS, crea el nombre pasándolo con el parámetro `master-username` en el comando. Para obtener más información, consulte [Creación de una instancia de base de datos de Amazon RDS](USER_CreateDBInstance.md).
Ya sea que utilice la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS y si usa el nombre predeterminado `postgres` o elige otro nombre, esta primera cuenta de usuario de la base de datos es miembro del grupo `rds_superuser` y tiene `rds_superuser` privilegios.
**Topics**
+ [Descripción del rol rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [Control del acceso de los usuarios a la base de datos de PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Delegación y control de la administración de contraseñas de usuario](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [Uso de SCRAM para el cifrado de contraseñas de PostgreSQL](PostgreSQL_Password_Encryption_configuration.md)
# Descripción del rol rds\$1superuser
En PostgreSQL, un *rol* puede definir un usuario, un grupo o un conjunto de permisos específicos concedidos a un grupo o usuario para varios objetos de la base de datos. Comandos de PostgreSQL para `CREATE USER` y `CREATE GROUP` se han sustituidos por los más generales, `CREATE ROLE` con propiedades específicas para distinguir a los usuarios de bases de datos. Un usuario de base de datos se puede concebir como un rol con el privilegio LOGIN.
**nota**
Los comandos `CREATE USER` y `CREATE GROUP` se pueden seguir utilizando. Para obtener más información, consulte [Roles de base de datos](https://www.postgresql.org/docs/current/user-manag.html) en la documentación de PostgreSQL.
El usuario `postgres` es el usuario de base de datos más privilegiado de la instancia de base de datos de RDS for PostgreSQL. Tiene las características definidas mediante la siguiente instrucción `CREATE ROLE`.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Las propiedades `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` y `VALID UNTIL 'infinity'` son las opciones predeterminadas de CREATE ROLE, a menos que se especifique lo contrario.
De forma predeterminada, `postgres` tiene privilegios otorgados al rol `rds_superuser` y permisos para crear roles y bases de datos. El rol `rds_superuser` permite al usuario `postgres` hacer lo siguiente:
+ Añadir extensiones que estén disponibles para el uso con Amazon RDS. Para obtener más información, consulte [Uso de las características de PostgreSQL admitidas por Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Cree roles para los usuarios y conceder privilegios a los usuarios. Para obtener más información, consulte [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) y [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) en la documentación de PostgreSQL.
+ Creación de bases de datos Para obtener más información, consulte [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) en la documentación de PostgreSQL.
+ Conceder privilegios de `rds_superuser` a los roles de usuario que no tengan estos privilegios y revocarlos según sea necesario. Le recomendamos que conceda este rol solo a los usuarios que realizan tareas de superusuario. En otras palabras, puede conceder este rol a los administradores de bases de datos (DBA) o a los administradores del sistema.
+ Conceda (y revoque) el rol `rds_replication` a usuarios de bases de datos que no tengan el rol `rds_superuser`.
+ Conceder (y revocar) el rol `rds_password` a usuarios de bases de datos que no tengan el rol `rds_superuser`.
+ Obtener información de estado sobre todas las conexiones de base de datos mediante la vista `pg_stat_activity`. Cuando sea necesario, `rds_superuser` puede detener cualquier conexión mediante `pg_terminate_backend` o `pg_cancel_backend`.
En la instrucción `CREATE ROLE postgres...`, se puede ver que el rol de usuario `postgres` no permite específicamente permisos `superuser` de PostgreSQL. RDS for PostgreSQL es un servicio administrado, por lo que no puede acceder al sistema operativo host y no puede conectarse con la cuenta `superuser` de PostgreSQL. Muchas de las tareas que requieren acceso `superuser` en un PostgreSQL independiente se administra automáticamente mediante Amazon RDS.
Para obtener más información sobre la concesión de privilegios, consulte [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) en la documentación de PostgreSQL.
El rol `rds_superuser` es uno de varios roles *predefinidos* en un Instancia de base de datos RDS for PostgreSQL.
**nota**
En PostgreSQL 13 y versiones anteriores, los roles *predefinidos* se denominan roles *predeterminados*.
En la siguiente lista encontrará algunos de los otros roles predefinidos que se crean automáticamente para un nuevo Instancia de base de datos RDS para PostgreSQL. Los roles predefinidos y sus privilegios no se pueden cambiar. No se pueden eliminar, cambiar de nombre ni modificar los privilegios de estos roles predefinidos. Intentar realizar una de estas operaciones producirá un error.
+ **rds\$1password**: rol que puede cambiar las contraseñas y configurar restricciones de contraseña para los usuarios de bases de datos. Al rol `rds_superuser` se le otorga este rol de forma predeterminada y puede otorgarlo a los usuarios de la base de datos. Para obtener más información, consulte [Control del acceso de los usuarios a la base de datos de PostgreSQLControl del acceso de los usuarios a PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ En las versiones de RDS para PostgreSQL anteriores a la 14, el rol `rds_password` puede cambiar las contraseñas y establecer restricciones de contraseña para los usuarios de la base de datos y los usuarios con el rol `rds_superuser`. A partir de la versión 14 de RDS para PostgreSQL, el rol `rds_password` puede cambiar las contraseñas y establecer restricciones de contraseña solo para los usuarios de la base de datos. Solo los usuarios con el rol `rds_superuser` pueden realizar estas acciones en otros usuarios con el rol `rds_superuser`.
+ **rdsadmin**: rol creado para administrar muchas de las tareas de administración que el administrador con privilegios de `superuser` realizaría en una base de datos PostgreSQL independiente. Este rol lo utiliza internamente RDS for PostgreSQLpara muchas tareas de administración.
+ **rdstopmgr**: rol que Amazon RDS utiliza internamente para admitir implementaciones multi-AZ.
+ **rds\$1reserved**: función que Amazon RDS utiliza internamente para reservar conexiones a bases de datos.
# Visualización los de roles y sus privilegios
Puede ver los roles predefinidos y sus privilegios en la instancia de base de datos de RDS para PostgreSQL mediante distintos comandos en función de la versión de PostgreSQL. Para ver todos los roles predefinidos, puede conectarse a la instancia de base de datos de RDS para PostgreSQL y ejecutar los siguientes comandos con `psql`.
**Para `psql` 15 y versiones anteriores**
Conéctese a la instancia de base de datos de RDS para PostgreSQL y use el comando `\du` en psql:
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Para `psql` 16 y versiones posteriores**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Para comprobar la pertenencia al rol sin dependencia de versiones, puede utilizar la siguiente consulta SQL:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
En la salida, puede ver que `rds_superuser` no es un rol de usuario de base de datos (no puede iniciar sesión), pero tiene los privilegios de muchos otros roles. También puede ver que el usuario de la base de datos `postgres` es miembro del rol `rds_superuser`. Como se ha mencionado anteriormente, `postgres` es el valor predeterminado de **Create database (Crear base de datos)** de la consola de Amazon RDS. Si ha elegido otro nombre, ese nombre se muestra en la lista de roles.
# Control del acceso de los usuarios a la base de datos de PostgreSQL
Las nuevas bases de datos de PostgreSQL siempre se crean con un conjunto predeterminado de privilegios en el esquema `public` de la base de datos que permite a todos los usuarios y roles de la base de datos crear objetos. Estos privilegios permiten a los usuarios de la base de datos conectarse a la base de datos, or ejemplo, y crear tablas temporales mientras están conectados.
Para controlar mejor el acceso de los usuarios a las instancias de bases de datos que cree en su instancia de base de datos de RDS for PostgreSQL, le recomendamos que revoque estos privilegios de `public` predeterminados. Después de ello, conceda a continuación los privilegios específicos a los usuarios de base de datos de forma más detallada, como se muestra en el siguiente procedimiento.
**Para configurar roles y privilegios para una nueva instancia de base de datos**
Supongamos que está configurando una base de datos en Instancia de base de datos de RDS for PostgreSQL de reciente creación para que lo utilicen varios investigadores, todos los cuales necesitan acceso de lectura y escritura a la base de datos.
1. Use `psql` (o pgAdmin) para conectarse a su instancia de base de datos de RDS for PostgreSQL:
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Escriba la contraseña cuando se le solicite. El cliente `psql` se conecta y muestra la base de datos de conexión administrativa predeterminada, `postgres=>`, como el símbolo del sistema.
1. Para evitar que los usuarios de la base de datos creen objetos en el esquema `public`, realice una de las siguientes opciones:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. A continuación, cree una nueva instancia de base de datos:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Revoque todos los privilegios del esquema `PUBLIC` de esta nueva base de datos.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Cree un rol para los usuarios de bases de datos.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Otorgue a los usuarios de bases de datos que tengan este rol la posibilidad de conectarse a la base de datos.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Conceda a todos los usuarios que tengan el rol `lab_tech` todos los privilegios de esta base de datos.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Cree usuarios de bases de datos de la siguiente manera:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Conceda a estos dos usuarios los privilegios asociados al rol lab\$1tech:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
En este punto,`lab_user1` y `lab_user2` se pueden conectar a la base de datos de `lab_db`. En este ejemplo no se siguen las prácticas recomendadas para el uso empresarial, que pueden incluir la creación de varias instancias de base de datos, distintos esquemas y la concesión de permisos limitados. Para obtener más información y escenarios adicionales, consulte [Administración de usuarios y roles de PostgreSQL](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Para obtener más información sobre los privilegios en las bases de datos de PostgreSQL, consulte el comando [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) en la documentación de PostgreSQL.
# Delegación y control de la administración de contraseñas de usuario
Como DBA, es posible que desee delegar la administración de contraseñas de usuario. O bien, puede que desee evitar que los usuarios de la base de datos cambien sus contraseñas o reconfiguren las restricciones de contraseña, como la duración de la contraseña. Para asegurarse de que solo los usuarios de la base de datos que elija puedan cambiar la configuración de contraseñas, puede activar la función de administración de contraseñas restringidas. Cuando activa esta función, solo pueden administrar contraseñas aquellos usuarios de base de datos a los que se les haya concedido el rol `rds_password`.
**nota**
Para utilizar la administración de contraseñas restringida, su instancia de base de datos RDS for PostgreSQL debe estar ejecutando para 10.6 o una versión posterior.
De forma predeterminada, esta función es `off`, tal y como se muestra en el ejemplo siguiente:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Para activar esta función, utilice un grupo de parámetros personalizado y cambie la configuración de `rds.restrict_password_commands` a 1. Asegúrese de reiniciar su Instancia de base de datos de RDS for PostgreSQL para que la configuración surta efecto.
Con esta función activa, se necesitan privilegios de `rds_password` para los siguientes comandos SQL:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Cambiar el nombre de un rol (`ALTER ROLE myrole RENAME TO newname`) también está restringido si la contraseña utiliza el algoritmo hash MD5.
Con esta función activa, intentar cualquiera de estos comandos SQL sin los permisos de rol `rds_password`, genera el siguiente error:
```
ERROR: must be a member of rds_password to alter passwords
```
Recomendamos que otorgar el `rds_password` solamente a unos cuantos roles que utilice únicamente para la administración de contraseñas. Si concede privilegios de `rds_password` a usuarios de bases de datos que no tengan privilegios de `rds_superuser`, también debe otorgarles el atributo `CREATEROLE`.
Asegúrese de que comprueba los requisitos de las contraseñas del lado del cliente, como el vencimiento y la complejidad necesaria. Si utiliza su propia utilidad del lado del cliente para cambios relacionados con la contraseña, la utilidad debe ser miembro de `rds_password` tener privilegios de `CREATE ROLE`.
# Uso de SCRAM para el cifrado de contraseñas de PostgreSQL
El mecanismo de autenticación mediante *desafío-respuesta discontinuo (SCRAM)* es una alternativa al algoritmo de resumen de mensajes (MD5) predeterminado de PostgreSQL para cifrar contraseñas. El mecanismo de autenticación SCRAM se considera más seguro que MD5. Para obtener más información sobre estos dos enfoques diferentes para proteger las contraseñas, consulte [Password Authentication](https://www.postgresql.org/docs/14/auth-password.html) (Autenticación de contraseñas) en la documentación de PostgreSQL.
Le recomendamos que utilice SCRAM en lugar de MD5 como esquema de cifrado de contraseñas para su . Instancia de base de datos RDS para PostgreSQL. Es un mecanismo criptográfico de desafío-respuesta que utiliza el algoritmo scram-sha-256 algorithm para la autenticación y el cifrado de contraseñas.
Es posible que deba actualizar las bibliotecas de las aplicaciones cliente para que sean compatibles con SCRAM. Por ejemplo, las versiones de JDBC anteriores a la 42.2.0 no admiten SCRAM. Para obtener más información, consulte [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) (Controlador JDBC de PostgreSQL) en la documentación del controlador JDBC de PostgreSQL. Para ver una lista de otros controladores de PostgreSQL y la compatibilidad con SCRAM, consulte [List of drivers](https://wiki.postgresql.org/wiki/List_of_drivers) (Lista de controladores) en la documentación de PostgreSQL.
RDS para PostgreSQL versión 13.1 y posteriores admite scram-sha-256. Estas versiones también le permiten configurar la instancia de la base de datos para que requiera SCRAM, como se explica en los siguientes procedimientos.
## Configuración de la instancia de base de datos de RDS para PostgreSQL para que requiera SCRAM
puede requerir que la instancia de RDS para PostgreSQL DB acepte únicamente contraseñas que utilicen el algoritmo scram-sha-256.
**importante**
En el caso de los proxies RDS existentes con bases de datos de PostgreSQL, si modifica la autenticación de la base de datos para utilizar únicamente `SCRAM`, el proxy dejará de estar disponible durante un máximo de 60 segundos. Para evitar este problema, lleve a cabo alguna de las siguientes operaciones:
Asegúrese de que la base de datos permita la autenticación `SCRAM` y `MD5`.
Para utilizar únicamente la autenticación `SCRAM`, cree un nuevo proxy, migre el tráfico de la aplicación al nuevo proxy y, a continuación, elimine el proxy previamente asociado a la base de datos.
Antes de realizar cambios en el sistema, asegúrese de entender el proceso completo, como se indica a continuación:
+ Obtenga información sobre todos los roles y el cifrado de las contraseñas de todos los usuarios de la base de datos.
+ Compruebe de nuevo la configuración de los parámetros de la instancia de base de datos de Aurora correspondiente a los parámetros que controlan el cifrado de las contraseñas.
+ Si la instancia de base de datos de RDS para PostgreSQL utiliza un grupo de parámetros predeterminado, deberá crear un grupo de parámetros de base de datos personalizado y aplicarlo a la instancia de base de datos de RDS para PostgreSQL para poder modificar los parámetros cuando sea necesario. Si la instancia de base de datos de RDS para PostgreSQL utiliza un grupo de parámetros personalizado, puede modificar los parámetros necesarios más adelante en el proceso, según sea necesario.
+ Cambie el parámetro `password_encryption` por `scram-sha-256`.
+ Notifique a todos los usuarios de la base de datos que deben actualizar las contraseñas. Haga lo mismo con su cuenta de `postgres`. Las nuevas contraseñas se cifran y almacenan mediante el algoritmo scram-sha-256.
+ Verifique que todas las contraseñas están cifradas con el tipo de cifrado.
+ Si todas las contraseñas utilizan scram-sha-256, puede cambiar el parámetro `rds.accepted_password_auth_method` de `md5+scram` a `scram-sha-256`.
**aviso**
Después de cambiar `rds.accepted_password_auth_method` a scram-sha-256 únicamente, no podrá conectarse ningún usuario (rol) con una contraseña cifrada con `md5`.
### Preparación para requerir SCRAM para su instancia de base de datos de RDS para PostgreSQL
Antes de realizar cambios en la instancia de RDS para PostgreSQL, compruebe todas las cuentas de usuario de base de datos existentes. Compruebe también el tipo de cifrado utilizado para las contraseñas. Puede hacer estas tareas con la extensión `rds_tools`. Para ver qué versiones de PostgreSQL son compatibles con `rds_tools`, consulte [Versiones de extensión para Amazon RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**Para obtener una lista de usuarios de base de datos (roles) y métodos de cifrado de contraseñas**
1. Use `psql` para conectarse a la instancia de base de datos de RDS para PostgreSQL, tal como se muestra a continuación.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Instale la extensión de `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Obtenga una lista de los roles y el cifrado.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Se muestra una salida similar a la siguiente.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Creación de un grupo de parámetros de base de datos personalizado
**nota**
Si la instancia de base de datos de RDS para PostgreSQL ya utiliza un grupo de parámetros personalizado, no necesita crear uno nuevo.
Para obtener información general sobre los grupos de parámetros para Amazon RDS, consulte [Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
El tipo de cifrado de contraseñas que se usa para las contraseñas se establece a un parámetro, `password_encryption`. El cifrado que permite la instancia de base de datos de RDS para PostgreSQL se establece a otro parámetro, `rds.accepted_password_auth_method`. Para cambiar cualquiera de los valores predeterminados, es necesario crear un grupo de parámetros de base de datos personalizado y aplicarlo a la instancia.
También puede utilizar la Consola de administración de AWS o la API de RDS para crear un grupo de parámetros de base de datos personalizado. Para obtener más información, consulte
Ahora puede asociar el grupo de parámetros personalizado con su instancia de base de datos.
**Para crear un grupo de parámetros de base de datos personalizado**
1. Utilice el comando `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` de la CLI para crear el grupo de parámetros de base de datos personalizado. En este ejemplo se utiliza `postgres13` como origen de este grupo de parámetros personalizado.
Para Linux, macOS o Unix:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Para Windows:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Utilice el comando `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` de la CLI para aplicar este grupo de parámetros personalizado al clúster de base de datos de RDS para PostgreSQL.
Para Linux, macOS o Unix:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Para Windows:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Para volver a sincronizar la instancia de base de datos de RDS para PostgreSQL con el grupo de parámetros de base de datos personalizado, debe reiniciar la instancia principal y todas las demás instancias del clúster. Para minimizar el impacto en sus usuarios, programe esto para que se produzca durante su periodo de mantenimiento regular.
### Configuración del cifrado de contraseñas para utilizar SCRAM
El mecanismo de cifrado de contraseñas que utiliza una instancia de base de datos de RDS para PostgreSQL se establece en el grupo de parámetros de base de datos en el parámetro `password_encryption`. Los valores permitidos son: no establecido, `md5` o `scram-sha-256`. El valor predeterminado depende de la versión de RDS para PostgreSQL del modo que se indica a continuación:
+ RDS para PostgreSQL 14 y versiones posteriores: el valor predeterminado es `scram-sha-256`
+ RDS para PostgreSQL 13: el valor predeterminado es `md5`
Con un grupo de parámetros de base de datos personalizado adjuntado a la instancia de base de datos de RDS para PostgreSQL, puede modificar los valores del parámetro de cifrado de contraseñas.
![\[A continuación, la consola de RDS muestra los valores predeterminados de los parámetros password_encryption de RDS para PostgreSQL.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**Para cambiar la configuración de cifrado de contraseñas a scram-sha-256**
+ Cambie el valor del cifrado de contraseñas a scram-sha-256, como se muestra a continuación. El cambio se puede aplicar inmediatamente porque el parámetro es dinámico, por lo que no se requiere un reinicio para que el cambio surta efecto.
Para Linux, macOS o Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Para Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migración de las contraseñas de los roles de usuario a SCRAM
Puede migrar las contraseñas de los roles de usuario a SCRAM, tal y como se describe a continuación.
**Para migrar las contraseñas de usuario (rol) de base de datos de MD5 a SCRAM**
1. Inicie sesión como usuario administrador (nombre de usuario predeterminado, `postgres`) como se muestra a continuación.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Compruebe la configuración del parámetro `password_encryption` en la instancia de base de datos de RDS para PostgreSQL con el siguiente comando.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Cambie el valor de este parámetro a scram-sha-256. Para obtener más información, consulte [Configuración del cifrado de contraseñas para utilizar SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Compruebe de nuevo el valor para asegurarse de que ahora está establecido en `scram-sha-256`, como se indica a continuación.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Notifique a todos los usuarios de base de datos que deben cambiar la contraseña. Asegúrese de cambiar también su propia contraseña para la cuenta `postgres` (el usuario de base de datos con privilegios `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Repita el proceso para todas las bases de datos del Instancia de base de datos RDS para PostgreSQL.
### Cambio del parámetro para requerir SCRAM
Este es el último paso del proceso. Después de realizar el cambio en el siguiente procedimiento, ninguna cuenta de usuario (rol) que aún utilice el cifrado `md5` para las contraseñas podrá iniciar sesión en el . Instancia de base de datos RDS para PostgreSQL.
Con `rds.accepted_password_auth_method` se especifica el método de cifrado que la instancia de base de datos de RDS para PostgreSQL acepta una contraseña de usuario durante el proceso de inicio de sesión. El valor predeterminado es `md5+scram`, lo que significa que se acepta cualquiera de los dos métodos. En la siguiente imagen, puede encontrar la configuración predeterminada de este parámetro.
![\[Consola de RDS con los valores predeterminados y permitidos para los parámetros rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Los valores permitidos para este parámetro son:`md5+scram` o `scram` solo. El cambio de este valor de parámetro a `scram` lo convierte en un requisito.
**Para cambiar el valor de parámetro para requerir la autenticación SCRAM para las contraseñas**
1. Verifique que todas las contraseñas de los usuarios de base de datos de la instancia de base de datos de RDS para PostgreSQL utilizan `scram-sha-256` para el cifrado de contraseña. Para ello, consulte `rds_tools` para el rol (usuario) y el tipo de cifrado, de la siguiente manera.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Repita la consulta en todas las instancias de base de datos del Instancia de base de datos RDS para PostgreSQL.
Si todas las contraseñas usan scram-sha-256, puede continuar.
1. Cambie el valor de la autenticación de contraseña aceptada a scram-sha-256, como se indica a continuación.
Para Linux, macOS o Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Para Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Gestión de conexiones inactivas en PostgreSQL
Las conexiones inactivas se producen cuando una sesión de base de datos permanece activa en el servidor a pesar de que la aplicación cliente se haya abandonado o terminado de forma anormal. Esta situación suele producirse cuando los procesos del cliente se bloquean o terminan de forma inesperada sin cerrar correctamente las conexiones de la base de datos ni cancelar las solicitudes en curso.
PostgreSQL identifica y limpia de manera eficiente las conexiones inactivas cuando los procesos del servidor están inactivos o intentan enviar datos a los clientes. Sin embargo, la detección es difícil en el caso de las sesiones que están inactivas, esperan la intervención del cliente o en las que se están ejecutando consultas de forma activa. Para gestionar estos escenarios, PostgreSQL proporciona los parámetros `tcp_keepalives_*`, `tcp_user_timeout`, y `client_connection_check_interval`.
**Topics**
+ [Descripción de keepalive de TCP](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [Parámetros clave keepalive de TCP en RDS para PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [Casos de uso de la configuración de keepalive de TCP](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [Prácticas recomendadas](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Descripción de keepalive de TCP
Keepalive de TCP es un mecanismo en el nivel de protocolo que ayuda a mantener y verificar la integridad de la conexión. Cada conexión TCP mantiene configuraciones en el nivel del kernel que rigen el comportamiento de keepalive. Cuando el temporizador de keepalive expira, el sistema realiza lo siguiente:
+ Envía un paquete de sondeo sin datos y con el indicador ACK activado.
+ Espera una respuesta del punto de conexión remoto de acuerdo con las especificaciones de TCP/IP.
+ Administra el estado de la conexión en función de la respuesta o la falta de respuesta.
## Parámetros clave keepalive de TCP en RDS para PostgreSQL
| Parámetro | Descripción | Valores predeterminados |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Specifies number of seconds of inactivity before sending keepalive message. | 300 |
| tcp\$1keepalives\$1interval | Specifies number of seconds between retransmissions of unacknowledged keepalive messages. | 30 |
| tcp\$1keepalives\$1count | Maximum lost keepalive messages before declaring connection dead | 2 |
| tcp\$1user\$1timeout | Specifies how long (in Milliseconds) unacknowledged data can remain before forcibly closing the connection. | 0 |
| client\$1connection\$1check\$1interval | Sets the interval (in Milliseconds) for checking client connection status during long-running queries. This ensures quicker detection of closed connections. | 0 |
## Casos de uso de la configuración de keepalive de TCP
### Mantenimiento de las sesiones inactivas como activas
Para evitar que los firewalls o enrutadores terminen las conexiones inactivas debido a la inactividad:
+ Configure `tcp_keepalives_idle` para enviar paquetes de keepalive a intervalos regulares.
### Detección de conexiones inactivas
Para detectar rápidamente las conexiones inactivas:
+ Ajuste `tcp_keepalives_idle`, `tcp_keepalives_interval` y `tcp_keepalives_count`. Por ejemplo, con los valores predeterminados de Aurora PostgreSQL, se tarda aproximadamente un minuto (2 sondas × 30 segundos) en detectar una conexión inactiva. Reducir estos valores puede acelerar la detección.
+ Utilice `tcp_user_timeout` para especificar el tiempo máximo de espera para una confirmación.
La configuración de keepalive de TCP ayuda al kernel a detectar conexiones inactivas, pero PostgreSQL puede no actuar hasta que se utilice el socket. Si una sesión está ejecutando una consulta larga, es posible que las conexiones inactivas solo se detecten una vez completada la consulta. En PostgreSQL 14 y versiones posteriores, `client_connection_check_interval` puede acelerar la detección de conexiones inactivas consultando periódicamente el socket durante la ejecución de la consulta.
## Prácticas recomendadas
+ **Establezca intervalos de keepalive razonables:** ajuste `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` y `tcp_keepalives_interval` para equilibrar la velocidad de detección y el uso de recursos.
+ **Optimice para su entorno:** alinee la configuración con el comportamiento de la red, las políticas de firewall y las necesidades de la sesión.
+ **Aproveche las características de PostgreSQL**: utilice `client_connection_check_interval` en PostgreSQL 14 y versiones posteriores para comprobar la conexión de forma eficaz.
# Uso de autovacuum de PostgreSQL en Amazon RDS para PostgreSQL
Le recomendamos que use la característica autovacuum para mantener en buen estado su instancia de base de datos de PostgreSQL. Autovacuum automatiza el comienzo de los comandos VACUUM y ANALYZE. Comprueba las tablas con una gran cantidad de tuplas insertadas, actualizadas o eliminadas. Después de esta verificación, recupera el almacenamiento mediante la eliminación de datos obsoletos o tuplas de la base de datos de PostgreSQL.
De forma predeterminada, autovacuum está activado para las instancias de base de datos de RDS para PostgreSQL que crea por medio de cualquiera de los grupos de parámetros de base de datos de PostgreSQL predeterminados. Otros parámetros de configuración asociados con la característica autovacuum también se establecen de forma predeterminada. Debido a que estos valores predeterminados son algo genéricos, puede beneficiarse de ajustar algunos de los parámetros asociados con la característica autovacuum para su carga de trabajo específica.
A continuación, puede encontrar más información sobre autovacuum y cómo ajustar algunos de sus parámetros en la instancia de base de datos de RDS para PostgreSQL. Para obtener información más específica, consulte [Prácticas recomendadas para trabajar con PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [Asignación de memoria para autovacuum](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [Reducción de la probabilidad de reinicio del identificador de transacción](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [Determinar si las tablas de una base de datos necesitan vacío](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [Determinar qué tablas cumplen actualmente los requisitos de autovacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [Determinar si autovacuum se está ejecutando actualmente y durante cuánto tiempo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [Realización de una inmovilización de vacío manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [Reindexar una tabla cuando autovacuum se está ejecutando](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [Administración de autovacuum con índices de gran tamaño](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [Otros parámetros que afectan a autovacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [Establecimiento de parámetros autovacuum de nivel de tabla](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [Registro de actividades de autovacuum y vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [Comportamiento de autovacuum con bases de datos no válidas](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [Identificación y resolución de los bloqueadores de vaciado intensivo en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Asignación de memoria para autovacuum
Uno de los parámetros más importantes que afectan al desempeño de autovacuum es el parámetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). En las versiones 14 y anteriores de RDS para PostgreSQL, el parámetro `autovacuum_work_mem` se establece en -1, lo que indica que en su lugar se utiliza la configuración de `maintenance_work_mem`. En todas las demás versiones, `autovacuum_work_mem` se determina mediante GREATEST(\$1DBInstanceClassMemory/32768\$1, 65536).
Las operaciones de limpieza manual siempre utilizan la configuración de `maintenance_work_mem`, con la configuración predeterminada de GREATEST (\$1DBInstanceClassMemory/63963136\$11024\$1, 65536), y también se puede ajustar en la sesión mediante el comando `SET` para operaciones manuales de `VACUUM` más específicas.
`autovacuum_work_mem` determina que la memoria de autovacuum conserve los identificadores de tuplas inactivas (`pg_stat_all_tables.n_dead_tup`) para los índices de limpieza.
Cuando realice los cálculos para determinar el valor del parámetro `autovacuum_work_mem`, tenga en cuenta lo siguiente:
+ Si define el parámetro en un valor demasiado bajo, el proceso de limpieza puede tener que examinar la tabla varias veces para completar su trabajo. Esta variedad de análisis puede tener un impacto negativo en el rendimiento. Para instancias mayores, configurar `maintenance_work_mem` o `autovacuum_work_mem` a 1 GB como mínimo puede mejorar el rendimiento de las tablas de limpieza con un número elevado de tuplas inactivas. Sin embargo, en las versiones 16 y anteriores de PostgreSQL, el uso de memoria de la operación de limpieza está limitado a 1 GB, que es suficiente para procesar aproximadamente 179 millones de tuplas inactivas de una sola pasada. Si una tabla tiene más tuplas inactivas que las indicadas, la operación de limpieza tendrá que realizar varias pasadas por los índices de la tabla, lo que aumentará considerablemente el tiempo necesario. A partir de la versión 17 de PostgreSQL, no hay un límite de 1 GB y autovacuum puede procesar más de 179 millones de tuplas mediante árboles radix.
Un identificador de tupla tiene un tamaño de 6 bytes. Con el fin de calcular la memoria necesaria para limpiar un índice de una tabla, realice una consulta a `pg_stat_all_tables.n_dead_tup` para buscar el número de tuplas inactivas y, a continuación, multiplique este número por 6 para determinar la memoria necesaria para limpiar el índice de una sola pasada. Puede utilizar la siguiente consulta:
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ El parámetro `autovacuum_work_mem` funciona en combinación con el parámetro `autovacuum_max_workers`. Cada empleado de `autovacuum_max_workers` puede utilizar la memoria que asigne. Si tiene demasiadas tablas pequeñas, asigne más `autovacuum_max_workers` y menos `autovacuum_work_mem`. Si tiene tablas grandes (de 100 GB o más), asigne más memoria y menos procesos de trabajo. Debe tener suficiente memoria asignada para que funcione en la tabla más grande. Por lo tanto, asegúrese de que la combinación de procesos de trabajo y memoria sea igual a la memoria total que desea asignar.
## Reducción de la probabilidad de reinicio del identificador de transacción
En algunos casos, la configuración de grupos de parámetros relacionada con autovacuum puede no ser lo suficientemente agresiva como para evitar el reinicio del identificador de transacción. Para solucionar esto, RDS para PostgreSQL proporciona un mecanismo que adapta los valores de los parámetros de autovacuum automáticamente. *Autovacuum adaptativo* es una característica para RDS para PostgreSQL. Puede encontrar una explicación detallada sobre el [reinicio del identificador de transacción](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) en la documentación de PostgreSQL.
Autovacuum adaptativo está activado de forma predeterminada para las instancias de RDS para PostgreSQL con el parámetro dinámico `rds.adaptive_autovacuum` establecido en Activado. Le recomendamos encarecidamente que mantenga esta opción activada. Sin embargo, para apagar el ajuste de parámetros autovacuum adaptativo, establezca el parámetro `rds.adaptive_autovacuum` en 0 u OFF.
El reinicio de ID de transacción sigue siendo posible incluso cuando Amazon RDS Amazon RDS ajusta los parámetros de autovacuum. Le animamos a implementar una alarma Amazon CloudWatch para el reinicio de identificador de transacción. Para obtener más información, consulte la publicación [Implement an early warning system for transaction ID wraparound in RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) (Implementar un sistema de alerta temprana para el ajuste de ID de transacción en RDS for PostgreSQL) en el Blog de Base de datos de AWS.
Con el ajuste de parámetros de autovacuum adaptable activado, Amazon RDS comienza a ajustar los parámetros de autovacuum cuando la métrica de CloudWatch `MaximumUsedTransactionIDs` alcanza el valor del parámetro `autovacuum_freeze_max_age` o 500 000 000, el que sea mayor.
Amazon RDS continúa ajustando los parámetros para el autovacuum si una tabla continúa tendiendo hacia el ajuste de ID de transacción. Cada uno de estos ajustes dedica más recursos a autovacuum para evitar el reinicio. Amazon RDS actualiza los siguientes parámetros relacionados con autovacuum:
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS modifica estos parámetros solo si el nuevo valor hace que autovacuum sea más agresivo. Estos parámetros se modifican en la memoria en la instancia de base de datos. Los valores en el grupo de parámetros no han cambiado. Para ver la configuración en memoria actual, utilice el comando de SQL PostgreSQL [SHOW](https://www.postgresql.org/docs/current/sql-show.html) de PostgreSQL.
Cuando Amazon RDS modifica alguno de estos parámetros de autovacuum, genera un evento para la instancia de base de datos afectada. Este evento se puede ver en la Consola de administración de AWS y a través de la API de Amazon RDS. Una vez que la métrica CloudWatch `MaximumUsedTransactionIDs` vuelve por debajo del límite, Amazon RDS restablece los parámetros relacionados con el autovacuum en la memoria a los valores especificados en el grupo de parámetros. Luego, genera otro evento correspondiente a este cambio.
# Determinar si las tablas de una base de datos necesitan vacío
Puede utilizar la siguiente consulta para mostrar el número de transacciones descongeladas en una base de datos. La columna `datfrozenxid` de una fila `pg_database` de una base de datos es un límite inferior en los identificadores de transacción normales que aparecen en esa base de datos. Esta columna es el mínimo de los valores `relfrozenxid` por tabla dentro de la base de datos.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Por ejemplo, los resultados de ejecutar la consulta anterior podrían ser los siguientes.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Cuando la antigüedad de una base de datos llega a los dos mil millones de identificadores de transacción, se produce el reinicio de los TransactionID (XID) y la base de datos cambia al modo de solo lectura. Puede usar esta consulta para generar una métrica y ejecutarla varias veces al día. De manera predeterminada, autovacuum está configurado para mantener la antigüedad de las transacciones en un máximo de 200,000,000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Una estrategia de monitorización de muestra podría ser la siguiente:
+ Establezca el valor `autovacuum_freeze_max_age` en 200 millones de transacciones.
+ Si una tabla llega a 500 millones de transacciones descongeladas, se dispara una alarma de gravedad baja. No es un valor disparatado, pero podría indicar que autovacuum no puede mantener el ritmo.
+ Si una tabla llega a mil millones, se debe interpretar como una alarma para adoptar medidas. En general, conviene mantener las antigüedades más cerca de `autovacuum_freeze_max_age` por motivos de rendimiento. Le recomendamos que investigue utilizando las recomendaciones que siguen.
+ Si una tabla llega a 1500 millones de transacciones sin vaciar, se dispara una alarma de gravedad alta. En función de la velocidad con la que la base de datos use los identificadores de transacción, esta alarma puede indicar que el sistema está agotando el tiempo para ejecutar autovacuum. En ese caso, le recomendamos una solución inmediata.
Si una tabla supera constantemente estos límites, modifique aún más sus parámetros de autovacuum. De manera predeterminada, usar VACUUM manualmente (que tiene deshabilitados los retardos basados en el costo) es un procedimiento más agresivo que usar el autovacuum predeterminado, pero es también más intrusivo para el sistema en su conjunto.
Le recomendamos lo siguiente:
+ Esté atento y active un mecanismo de supervisión para que esté al tanto de la antigüedad de sus transacciones.
A fin de obtener información acerca de la creación de un proceso que advierta sobre el reinicio del ID de transacción, consulte la publicación de blog de la base de datos de AWS sobre la [implementación de un sistema de advertencia temprana para el reinicio de un ID de transacción en Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/).
+ Para las tablas con más actividad, lleve a cabo una inmovilización manual de vacío con regularidad durante una ventana de mantenimiento además de confiar en autovacuum. Para obtener información acerca de la ejecución de una inmovilización de vacío manual, consulte [Realización de una inmovilización de vacío manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Determinar qué tablas cumplen actualmente los requisitos de autovacuum
A menudo, hay una o dos tablas que necesitan vacío. Autovacuum se dirige siempre a las tablas cuyo valor `relfrozenxid` sea superior al número de transacciones en `autovacuum_freeze_max_age`. De lo contrario, si el número de tuplas obsoletas desde el último VACUUM supera el límite de vacío, la tabla se vacía.
El [umbral de autovacuum](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) se define como:
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
donde el `vacuum base threshold` es `autovacuum_vacuum_threshold`, el `vacuum scale factor` es `autovacuum_vacuum_scale_factor` y el `number of tuples` es `pg_class.reltuples`.
Mientras está conectado a la base de datos, ejecute la siguiente consulta para ver una lista de tablas que autovacuum considera aptas para el vacío.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Determinar si autovacuum se está ejecutando actualmente y durante cuánto tiempo
Si necesita aspirar manualmente una tabla, asegúrese de determinar si el autovacuum se está ejecutando actualmente. Si es así, es posible que deba ajustar los parámetros para que funcione de manera más eficiente o desactivar el autovacuum temporalmente para que pueda ejecutar manualmente VACUUM.
Use la siguiente consulta para determinar si se está ejecutando autovacuum, cuánto tiempo lleva en ejecución y si se encuentra en espera en otra sesión.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Después de ejecutar la consulta, debería ver un resultado similar al siguiente.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Existen varios problemas que pueden provocar una sesión de autovaccum de larga duración (es decir, que tarde varios días). El problema más común es que el valor del parámetro [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) sea demasiado bajo para el tamaño de la tabla o la velocidad de las actualizaciones.
Le recomendamos que utilice la siguiente fórmula para establecer el valor del parámetro `maintenance_work_mem`.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
Las sesiones de autovacuum con una duración corta también pueden indicar problemas:
+ Pueden indicar que no hay un número de `autovacuum_max_workers` suficientemente alto para la carga de trabajo. En ese caso, tendrá que especificar el número de procesos de trabajo.
+ Puede indicar que hay una corrupción de índice (autovacuum falla y se reinicia en la misma relación pero no avanza). En este caso, ejecute un manual `vacuum freeze verbose table` para ver la causa exacta.
# Realización de una inmovilización de vacío manual
Puede ocurrir que desee realizar una operación de vacío manual en una tabla que ya tenga un proceso de vacío en ejecución. Esto resulta útil si se ha identificado una tabla con una antigüedad cercana a dos mil millones de transacciones (o por encima del umbral que esté monitorizando).
Los siguientes pasos son pautas, con varias variaciones en el proceso. Por ejemplo, durante las pruebas, suponga que descubre que el parámetro [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) se definió en un valor demasiado bajo y que tiene que adoptar medidas de forma inmediata en una tabla. Sin embargo, quizás no desea rebotar la instancia en ese momento. Con las consultas de las secciones anteriores, puede determinar qué tabla está causando el problema y comprobar que hay una sesión de autovacuum que lleva mucho tiempo en ejecución. Sabe que tiene que cambiar el ajuste del parámetro `maintenance_work_mem`, pero también tiene que adoptar medidas de inmediato y aplicar el vacío en la tabla afectada. El siguiente procedimiento muestra qué hacer en esa situación.
**Para realizar manualmente una inmovilización de vacío**
1. Abra dos sesiones en la base de datos que contiene la tabla en la que desea ejecutar el vacío. Para la segunda sesión, use "screen" u otra utilidad que mantenga la sesión activa si se interrumpe la conexión.
1. En la sesión uno, obtenga el ID de proceso (PID) de la sesión de autovacuum que se ejecuta en la tabla.
Ejecute la siguiente consulta para obtener el PID de la sesión de autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. En la sesión dos, calcule la cantidad de memoria que necesitará para esta operación. En este ejemplo, determinamos que podemos permitirnos usar un máximo de 2 GB de memoria para esta operación y, por tanto, definimos [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) en 2 GB para la sesión actual.
```
SET maintenance_work_mem='2 GB';
SET
```
1. En la sesión dos, ejecute el comando `vacuum freeze verbose` para la tabla. El ajuste de informe detallado resulta útil porque, aunque PostgreSQL no ofrece actualmente un informe de progreso para esto, se puede ver la actividad.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. En la sesión uno, si la limpieza automática bloqueaba la sesión de vacío, `pg_stat_activity` muestra que la espera es `T` para la sesión de vacío. En este caso, finalice el proceso de limpieza automática de la siguiente manera.
```
SELECT pg_terminate_backend('the_pid');
```
**nota**
Algunas versiones anteriores de Amazon RDS no pueden finalizar un proceso de limpieza automática mediante el comando anterior y producen el siguiente error: `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`.
En este punto, comienza la sesión. La limpieza automática se reinicia inmediatamente, ya que esta tabla es probablemente la que ocupa una posición más alta en la lista de trabajo.
1. Inicie el comando `vacuum freeze verbose` en la sesión dos y luego finalice el proceso de autovacuum en la sesión uno.
# Reindexar una tabla cuando autovacuum se está ejecutando
Si un índice se ha dañado, autovacuum seguirá procesando la tabla y generará errores. Si intenta realizar un vacío manual en esta situación, recibirá un mensaje de error como el siguiente.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Cuando el índice está dañado y autovacuum intenta ejecutarse en la tabla, se enfrenta a una sesión de autovacuum que ya se está ejecutando. Cuando ejecuta un comando [REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html), elimina un bloqueo exclusivo en la tabla. Las operaciones de escritura están bloqueadas y también las operaciones de lectura que usan ese índice específico.
**Para reindexar una tabla cuando autovacuum se está ejecutando en ella**
1. Abra dos sesiones en la base de datos que contiene la tabla que desea vaciar. Para la segunda sesión, use "screen" u otra utilidad que mantenga la sesión activa si se interrumpe la conexión.
1. En la sesión uno, obtenga el PID de la sesión de autovacuum que se ejecuta en la tabla.
Ejecute la siguiente consulta para obtener el PID de la sesión de autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. En la sesión dos, ejecute el comando reindex.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. En la sesión uno, si autovacuum estaba bloqueando, verá en `pg_stat_activity` que la espera es “T” para su sesión de vacío. En este caso, terminará el proceso de autovacuum.
```
SELECT pg_terminate_backend('the_pid');
```
En este punto, comienza la sesión. Es importante tener en cuenta que autovacuum se reiniciará inmediatamente, ya que esta tabla es probablemente la que ocupa una posición más alta en su lista de trabajo.
1. Inicie el comando en la sesión dos y termine a continuación el proceso de autovacuum de la sesión 1.
# Administración de autovacuum con índices de gran tamaño
Como parte de su funcionamiento, *autovacuum* realiza varias [fases de vaciado](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) mientras se ejecuta en una tabla. Antes de limpiar la tabla, primero se vacían todos sus índices. Al eliminar varios índices de gran tamaño, esta fase consume una cantidad importante de tiempo y recursos. Por lo tanto, como práctica recomendada, asegúrese de controlar el número de índices de una tabla y eliminar los no utilizados.
Para este proceso, compruebe primero el tamaño general del índice. A continuación, determine si hay índices que es posible que no se utilicen y que se puedan eliminar, tal y como se muestra en los siguientes ejemplos.
**Para comprobar el tamaño de la tabla y sus índices**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
En este ejemplo, el tamaño de los índices es mayor que el de la tabla. Esta diferencia puede provocar problemas de rendimiento, ya que los índices están sobrecargados o no se utilizan, lo que afecta a las operaciones de autovacuum y de inserción.
**Para comprobar si hay índices no utilizados**
En la vista [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW), puede comprobar la frecuencia con la que se utiliza un índice con la columna `idx_scan`. En el siguiente ejemplo, los índices no utilizados tienen el valor `0` en `idx_scan`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**nota**
Estas estadísticas son incrementales desde el momento en que se restablecen las estadísticas. Supongamos que tiene un índice que solo se usa al final de un trimestre empresarial o solo para un informe específico. Es posible que este índice no se haya utilizado desde que se restablecieron las estadísticas. Para obtener más información, consulte [Statistics Functions](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS) (Funciones de estadísticas). Los índices que se utilizan para garantizar la exclusividad no se analizan y no se deben identificar como índices no utilizados. Para identificar los índices no utilizados, debe tener un conocimiento profundo de la aplicación y sus consultas.
Para comprobar cuándo se restablecieron por última vez las estadísticas de una base de datos, utilice [ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW]( https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Vaciado de una tabla lo más rápido posible
**RDS para PostgreSQL 12 y versiones posteriores**
Si tiene demasiados índices en una tabla grande, la instancia de base de datos podría estar a punto de reiniciar el identificador de transacción (XID), que es cuando el contador de XID vuelve a ponerse en cero. Si esta casilla no se marca, esta situación podría provocar la pérdida de datos. Sin embargo, puede vaciar rápidamente la tabla sin limpiar los índices. En RDS para PostgreSQL 12 y versiones posteriores, puede usar VACUUM con la cláusula [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html).
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Si ya se está ejecutando una sesión de autovacuum, debe finalizarla para iniciar VACUUM manualmente. Para obtener información acerca de la ejecución de una inmovilización de vacío manual, consulte [Realización de una inmovilización de vacío manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**nota**
Omitir la limpieza de índices con regularidad causa una sobrecarga de los índices, lo que degrada el rendimiento del análisis. El índice retiene las filas inactivas y la tabla retiene los punteros de línea inactivos. Como resultado, `pg_stat_all_tables.n_dead_tup` aumenta hasta que se ejecuta el vaciado automático o una operación VACUUM manual con limpieza de índices. Como práctica recomendada, use este procedimiento solo para impedir que el identificador se reinicie.
**RDS para PostgreSQL 11 y versiones anteriores**
Sin embargo, en RDS para PostgreSQL 11 y versiones anteriores, la única forma de hacer que el vacío se realice más rápidamente es reducir el número de índices de una tabla. La eliminación de un índice puede afectar a los planes de consulta. Le recomendamos que primero borre los índices no utilizados y, a continuación, los índices cuando el reinicio de XID sea inminente. Una vez finalizado el proceso de vaciado, puede volver a crear estos índices.
# Otros parámetros que afectan a autovacuum
La siguiente consulta mostrará los valores de algunos de los parámetros que afectan directamente a autovacuum y a su comportamiento. Los [parámetros de autovacuum](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) se describen en detalle en la documentación de PostgreSQL.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
Aunque todos estos parámetros afectan a autovacuum, estos son algunos de los más importantes:
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Establecimiento de parámetros autovacuum de nivel de tabla
Los [parámetros de almacenamiento](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS) relacionados con autovacuum se pueden definir en el nivel de tabla, algo que puede resultar mejor que alterar el comportamiento de toda la base de datos. Para las tablas grandes, podría ser necesario definir unos ajustes agresivos, y es posible que no sea deseable que autovacuum se comporte de esa forma para todas las tablas.
La siguiente consulta mostrará qué tablas tienen habilitadas actualmente las opciones de nivel de tabla.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Un ejemplo en el que esto puede resultar útil es el de las tablas que son mucho más grandes que el resto de las tablas. Supongamos que dispone de una tabla de 300 GB y otras 30 tablas inferior a 1 GB. En ese caso, podría definir algunos parámetros concretos para la tabla grande con el fin de evitar alterar el comportamiento de todo el sistema.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Al hacer esto, desactiva el retraso de autovacuum basado en costos para esta tabla a expensas de un mayor uso de recursos en su sistema. Normalmente, autovacuum hace una pausa por `autovacuum_vacuum_cost_delay` cada vez que se alcanza `autovacuum_cost_limit`. En la documentación de PostgreSQL, puede obtener información detallada relativa al [vacío basado en el costo](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Registro de actividades de autovacuum y vacuum
La información sobre las actividades de autovacuum se envía a `postgresql.log` basado en el nivel especificado en el parámetro `rds.force_autovacuum_logging_level`. Los siguientes son los valores permitidos para este parámetro y las versiones de PostgreSQL para las que ese valor es la configuración predeterminada:
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 y versiones posteriores)
+ `error`, registro, `fatal`, `panic`
`rds.force_autovacuum_logging_level` funciona con el parámetro `log_autovacuum_min_duration`. El valor del parámetro `log_autovacuum_min_duration` es el límite (en milisegundos) por encima del cual se registran las acciones de autovacuum. Una configuración de `-1` no registra nada, mientras que una configuración de 0 registra todas las acciones. Al igual que con `rds.force_autovacuum_logging_level`, los valores predeterminados para `log_autovacuum_min_duration` dependen de la versión, como se indica a continuación:
+ `10000 ms`: PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 y PostgreSQL 11
+ `(empty)`: no hay valor predeterminado para PostgreSQL 10 y PostgreSQL 9.6
Es recomendable que defina `rds.force_autovacuum_logging_level` como `WARNING`. También recomendamos configurar `log_autovacuum_min_duration` a un valor de 1000 a 5000. Una configuración de 5000 registra la actividad que tarda más de 5000 milisegundos. Cualquier configuración que no sea -1 también registra mensajes si la acción de autovaccum se omite debido a un bloqueo en conflicto o relaciones eliminadas al mismo tiempo. Para más información, visite [Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) (Vacío automático) en la documentación de PostgreSQL.
Para solucionar problemas, puede cambiar el parámetro `rds.force_autovacuum_logging_level` a uno de los niveles de depuración, desde `debug1` hasta `debug5` para obtener la información más detallada. Le recomendamos que utilice la configuración de depuración durante periodos cortos y solo con el objetivo de solucionar problemas. Para más información, visite [When to log](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) (Cuándo registrarse) en la documentación de PostgreSQL.
**nota**
PostgreSQL permite a la cuenta `rds_superuser` consultar sesiones de autovacuum en `pg_stat_activity`. Por ejemplo, podrá identificar y finalizar una sesión de autovacuum que bloquea la ejecución de un comando o que hace que se ejecute más despacio que un comando de vacío emitido manualmente.
# Comportamiento de autovacuum con bases de datos no válidas
Se introduce un nuevo valor `-2` en la columna `datconnlimit` del catálogo `pg_database` para indicar que las bases de datos interrumpidas en mitad de la operación DROP DATABASE no son válidas.
Este nuevo valor está disponible en las siguientes versiones de RDS para PostgreSQL:
+ Versión 15.4 y todas las versiones posteriores
+ Versión 14.9 y posteriores
+ Versión 13.12 y posteriores
+ Versión 12.16 y posteriores
+ Versión 11.21 y posteriores
Las bases de datos no válidas no afectan a la capacidad de autovacuum de bloquear la funcionalidad de las bases de datos válidas. Autovacuum ignora las bases de datos no válidas. Por lo tanto, las operaciones vacuum habituales seguirán funcionando de forma adecuada y eficiente en todas las bases de datos válidas de su entorno de PostgreSQL.
**Topics**
+ [Supervisión del ID de transacción](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [Ajustes en la consulta de supervisión](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [Resolución de problemas relacionados con bases de datos no válidas](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Supervisión del ID de transacción
La función `age(datfrozenxid)` se suele utilizar para supervisar la antigüedad del ID de transacción (XID) de las bases de datos a fin de evitar que este se reinicie.
Como las bases de datos no válidas se excluyen del autovacuum, su contador de ID de transacción (XID) puede alcanzar el valor máximo de `2 billion`, reiniciarse en `- 2 billion` y continuar este ciclo indefinidamente. Una consulta típica para supervisar el reinicio del ID de transacción podría ser así:
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Sin embargo, al introducir el valor -2 para `datconnlimit`, las bases de datos no válidas pueden sesgar los resultados de esta consulta. Como estas bases de datos no son válidas y no deberían formar parte de las comprobaciones de mantenimiento periódicas, pueden provocar falsos positivos y dar la impresión de que `age(datfrozenxid)` es mayor de lo que realmente es.
## Ajustes en la consulta de supervisión
Para garantizar una supervisión precisa, debe ajustar la consulta de supervisión a fin de excluir las bases de datos no válidas. Siga esta consulta recomendada:
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Esta consulta garantiza que solo se tengan en cuenta las bases de datos válidas en el cálculo de `age(datfrozenxid)`, lo que aporta información fiable sobre la antigüedad del ID de transacción en todo el entorno de PostgreSQL.
## Resolución de problemas relacionados con bases de datos no válidas
Al intentar conectarse a una base de datos no válida, es posible que vea un mensaje de error similar al siguiente:
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
Además, si el parámetro `log_min_messages` tiene un valor igual o superior a `DEBUG2`, es posible que vea que las siguientes entradas de registro muestran que el proceso de autovacuum omite la base de datos no válida:
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Para resolver el problema, siga la `HINT` proporcionada durante el intento de conexión. Conéctese a cualquier base de datos válida mediante su cuenta maestra de RDS o una cuenta de base de datos con el rol `rds_superuser` y elimine las bases de datos no válidas.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# 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.
# Administración de recuentos de objetos altos en Amazon RDS para PostgreSQL
Aunque las limitaciones de PostgreSQL son teóricas, tener recuentos de objetos extremadamente altos en una base de datos provocará un impacto notable en el rendimiento de varias operaciones. Esta documentación cubre varios tipos de objetos comunes que, cuando tienen un recuento total alto, pueden tener varios posibles impactos.
En la tabla siguiente, se proporciona un resumen de los tipos de objetos y sus posibles impactos:
**Tipos de objetos e impactos potenciales**
| Tipo de objeto | Limpieza automática | Replicación lógica | Actualización de la versión principal | pg\$1dump/pg\$1restore | Rendimiento general | Reinicio de la instancia |
| --- | --- | --- | --- | --- | --- | --- |
| [Relaciones](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Tablas temporales](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Tablas sin registrar](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Particiones](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [Archivos temporales](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Secuencias](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Objetos grandes](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relaciones
No hay un límite estricto específico en cuanto al número de tablas en una base de datos de PostgreSQL. El límite teórico es extremadamente alto, pero hay otros límites prácticos que deben tenerse en cuenta al diseñar la base de datos.
**Impacto: la limpieza automática se queda atrás**
La limpieza automática puede tener dificultades para mantenerse al día con el crecimiento de ID de transacciones o la sobrecarga de la tabla debido a la falta de personal en comparación con la cantidad de trabajo.
**Acción recomendada:** existen varios factores para ajustar la limpieza automática a fin de que pueda funcionar correctamente con un número determinado de tablas y una carga de trabajo determinada. Consulte [Prácticas recomendadas para trabajar con la limpieza automática de PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) para obtener sugerencias sobre cómo determinar la configuración de limpieza automática adecuada. Utilice la [utilidad postgres\$1get\$1av\$1diag](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html) para supervisar los problemas relacionados con el crecimiento de ID de transacción.
**Impacto: actualización de la versión principal/pg\$1dump y restauración**
Amazon RDS utiliza la opción “--link” durante la ejecución de pg\$1upgrade para evitar tener que hacer copias de los archivos de datos. Aun así, es necesario restaurar los metadatos del esquema en la nueva versión de la base de datos. Incluso con pg\$1restore paralelo, si hay un número significativo de relaciones, esto aumentará la cantidad de tiempo de inactividad.
**Impacto: degradación general del rendimiento**
Degradación general del rendimiento debido al tamaño del catálogo. Cada tabla y sus columnas asociadas se agregarán a las tablas de `pg_attribute`, `pg_class` y `pg_depend` que se utilizan con frecuencia en las operaciones normales de la base de datos. No habrá ningún evento de espera específico visible, pero la eficiencia del búfer compartido se verá afectada.
**Acción recomendada:** compruebe con regularidad la sobrecarga de la tabla para estas tablas específicas y, de vez en cuando, realice una operación `VACUUM FULL` en estas tablas específicas. Tenga en cuenta que `VACUUM FULL` en las tablas del catálogo requiere un bloqueo `ACCESS EXCLUSIVE`, lo que significa que ninguna otra consulta podrá acceder a ellas hasta que se complete la operación.
**Impacto: agotamiento de los descriptores de archivos**
Error: “No hay suficientes descriptores de archivos: hay demasiados archivos abiertos en el sistema; libérelos y vuelva a intentarlo”. El parámetro `max_files_per_process` de PostgreSQL determina cuántos archivos puede abrir cada proceso. Si hay un número elevado de conexiones que se unen a un número elevado de tablas, es posible alcanzar este límite.
**Acción recomendada:**
+ La reducción del valor del parámetro `max_files_per_process` puede ayudar a solventar este error. Cada proceso y subproceso (por ejemplo, una consulta paralela) puede abrir este número de archivos y, si las consultas unen varias tablas, este límite puede agotarse.
+ Reduzca el número total de conexiones y utilice un agrupador de conexiones como [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) u otras soluciones como PgBouncer. Para obtener más información, consulte el sitio web de [PgBouncer](https://www.pgbouncer.org/).
**Impacto: agotamiento de inodos**
Error: “Falta de espacio en el dispositivo”. Si esto se observa cuando hay suficiente espacio libre de almacenamiento, se debe a que se están agotando los inodos. La [Supervisión mejorada de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) proporciona visibilidad de los inodos en uso y del número máximo disponible para el host.
**Umbral aproximado:** [millones](#PostgreSQL.HighObjectCount.Note)
## Tablas temporales
El uso de tablas temporales es útil para datos de prueba o resultados intermedios y es un patrón común que se observa en muchos motores de bases de datos. Hay que entender las implicaciones del uso intensivo de PostgreSQL para evitar algunas de las dificultades. Cada tabla temporal creada y eliminada agregará filas a las tablas del catálogo del sistema, lo que, cuando se sobrecargue, provocará problemas generales de rendimiento.
**Impacto: la limpieza automática se queda atrás**
Las tablas temporales no se aspiran con limpieza automática, sino que conservan los ID de las transacciones durante su existencia y, si no se retiran, pueden quedar ocultas.
**Acción recomendada:** las tablas temporales permanecerán activas mientras dure la sesión en la que se crearon o se pueden eliminar manualmente. Una práctica recomendada consiste en evitar las transacciones de larga duración con tablas temporales para evitar que estas tablas contribuyan al máximo crecimiento de los ID de transacción utilizados.
**Impacto: degradación general del rendimiento**
Degradación general del rendimiento debido al tamaño del catálogo. Cuando las sesiones crean y descartan tablas temporales de forma continua, se agregan a tablas de `pg_attribute`, `pg_class` y `pg_depend` que se utilizan con frecuencia en las operaciones normales de la base de datos. No habrá ningún evento de espera específico visible, pero la eficiencia del búfer compartido se verá afectada.
**Acción recomendada:**
+ compruebe con regularidad la sobrecarga de la tabla para estas tablas específicas y, de vez en cuando, realice una operación `VACUUM FULL` en estas tablas específicas. Tenga en cuenta que `VACUUM FULL` en las tablas del catálogo requiere un bloqueo `ACCESS EXCLUSIVE`, lo que significa que ninguna otra consulta podrá acceder a ellas hasta que se complete la operación.
+ Si se utilizan mucho las tablas temporales, antes de actualizar una versión principal, se recomienda encarecidamente utilizar una operación `VACUUM FULL` de estas tablas de catálogo específicas para reducir el tiempo de inactividad.
**Prácticas recomendadas generales:**
+ reduzca el uso de tablas temporales mediante el uso de expresiones de tablas comunes para obtener resultados intermedios. A veces, esto puede complicar las consultas necesarias, pero se eliminarán los impactos mostrados anteriormente.
+ Reutilice las tablas temporales mediante el comando `TRUNCATE` para borrar el contenido en lugar de realizar los pasos de eliminar o crear. Esto también eliminará el problema del crecimiento del ID de transacción provocado por las tablas temporales.
**Umbral aproximado:** [decenas de miles](#PostgreSQL.HighObjectCount.Note)
## Tablas sin registrar
Las tablas no registradas pueden ofrecer mejoras de rendimiento, ya que no generarán ninguna información de WAL. Se deben usar con cuidado, ya que no ofrecen durabilidad durante la recuperación de un error de la base de datos, ya que se truncarán. Esta es una operación costosa en PostgreSQL, ya que cada tabla no registrada se trunca en serie. Aunque esta operación es rápida para un número reducido de tablas sin registrar, cuando se cuentan por miles, puede empezar a provocar un retraso notable durante el inicio.
**Impacto: replicación lógica**
Por lo general, las tablas no registradas no se incluyen en la replicación lógica, como [implementaciones azul/verde](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), porque la replicación lógica se basa en WAL para capturar y transferir los cambios.
**Impacto: tiempo de inactividad prolongado durante la recuperación**
Durante cualquier estado de la base de datos que implique la recuperación de errores de la base de datos, como el reinicio multi-AZ con conmutación por error, la recuperación en un momento dado de Amazon RDS y la actualización de la versión principal de Amazon RDS, se producirá la operación serializada de truncar las tablas no registradas. Esto puede provocar un tiempo de inactividad mucho mayor de lo esperado.
**Acción recomendada:**
+ minimice el uso de tablas no registradas solo para los datos cuya pérdida es aceptable durante las operaciones de recuperación tras un error de la base de datos.
+ Minimice el uso de tablas no registradas, ya que el comportamiento actual del truncamiento en serie puede provocar que el inicio de una base de datos tarde mucho tiempo.
**Prácticas recomendadas generales:**
+ Las tablas no registradas no son a pruebas de errores. En PostgreSQL, iniciar una recuperación en un momento dado, que implica una recuperación por error, lleva mucho tiempo, ya que se trata de un proceso en serie que trunca cada tabla.
**Umbral aproximado:** [miles](#PostgreSQL.HighObjectCount.Note)
## Particiones
El particionamiento puede aumentar el rendimiento de las consultas y proporcionar una organización lógica de los datos. En situaciones ideales, el particionamiento se organiza de manera que se pueda utilizar la depuración de particiones durante la planificación y ejecución de las consultas. El uso de demasiadas particiones puede tener un impacto negativo en el rendimiento de las consultas y en el mantenimiento de la base de datos. La elección de cómo particionar una tabla debe hacerse con cuidado, ya que un diseño deficiente puede afectar negativamente al rendimiento de la planificación y ejecución de las consultas. Consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/ddl-partitioning.html) para obtener más información sobre las particiones.
**Impacto: degradación general del rendimiento**
A veces, la sobrecarga de tiempo de planificación aumentará y la explicación de los planes para las consultas se volverá más complicada, lo que dificultará la identificación de las oportunidades de ajuste. En el caso de las versiones de PostgreSQL anteriores a la 18, muchas particiones con una gran carga de trabajo pueden provocar esperas de `LWLock:LockManager`.
**Acción recomendada:** determine un número mínimo de particiones que permita completar la organización de los datos y, al mismo tiempo, ejecutar las consultas de forma eficaz.
**Impacto: complejidad del mantenimiento**
Un número muy elevado de particiones provocará dificultades de mantenimiento, como la creación previa y la eliminación. La limpieza automática tratará las particiones como si fueran relaciones normales y tendrá que realizar una limpieza periódica, por lo que necesitará un número suficiente de trabajadores para completar la tarea.
**Acción recomendada:**
+ asegúrese de crear previamente las particiones para que la carga de trabajo no se bloquee cuando se necesite una nueva partición (por ejemplo, particiones mensuales) y se eliminen las particiones antiguas.
+ Asegúrese de tener suficientes trabajadores de limpieza automática para llevar a cabo la limpieza y el mantenimiento normales de todas las particiones.
**Umbral aproximado:** [cientos](#PostgreSQL.HighObjectCount.Note)
## Archivos temporales
A diferencia de las tablas temporales mencionadas anteriormente, PostgreSQL crea los archivos temporales cuando una consulta compleja puede realizar varias operaciones de ordenación y hash al mismo tiempo, y cada una de ellas utiliza memoria de la instancia para almacenar los resultados hasta el valor especificado en el parámetro `work_mem`. Cuando la memoria de la instancia no es suficiente, se crean archivos temporales para almacenar los resultados. Consulte [Administración de archivos temporales](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) para obtener más información sobre los archivos temporales. Si la carga de trabajo genera un número alto de estos archivos, puede haber varios impactos.
**Impacto: agotamiento de los descriptores de archivos**
Error: “No hay suficientes descriptores de archivos: hay demasiados archivos abiertos en el sistema; libérelos y vuelva a intentarlo”. El parámetro `max_files_per_process` de PostgreSQL determina cuántos archivos puede abrir cada proceso. Si hay un número elevado de conexiones que se unen a un número elevado de tablas, es posible alcanzar este límite.
**Acción recomendada:**
+ La reducción del valor del parámetro `max_files_per_process` puede ayudar a solventar este error. Cada proceso y subproceso (por ejemplo, una consulta paralela) puede abrir este número de archivos y, si las consultas unen varias tablas, este límite puede agotarse.
+ Reduzca el número total de conexiones y utilice un agrupador de conexiones como [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) u otras soluciones como PgBouncer. Para obtener más información, consulte el sitio web de [PgBouncer](https://www.pgbouncer.org/).
**Impacto: agotamiento de inodos**
Error: “Falta de espacio en el dispositivo”. Si esto se observa cuando hay suficiente espacio libre de almacenamiento, se debe a que se están agotando los inodos. La [Supervisión mejorada de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) proporciona visibilidad de los inodos en uso y del número máximo disponible para el host.
**Prácticas recomendadas generales:**
+ Supervise el uso de los archivos temporales con [Información de rendimiento](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
+ Ajuste las consultas que generan archivos temporales importantes para ver si es posible reducir el número total de archivos temporales.
**Umbral aproximado:** [miles](#PostgreSQL.HighObjectCount.Note)
## Secuencias
Las secuencias son el objeto subyacente que se utiliza para incrementar automáticamente las columnas en PostgreSQL y proporcionan exclusividad y una clave para los datos. Se pueden usar en tablas individuales sin consecuencias durante las operaciones normales, con una excepción de la replicación lógica.
En PostgreSQL, la replicación lógica actualmente no replica el valor actual de una secuencia a ningún suscriptor. Para obtener más información, consulte [Página de restricciones en la documentación de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Impacto: se prolongó el tiempo de conmutación**
Si planea usar [Implementaciones azules/verdes de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) para cualquier tipo de cambio o actualización de configuración, es importante que comprenda el impacto de un gran número de secuencias en la conmutación. Una de las últimas fases de la conmutación sincronizará el valor actual de las secuencias y, si hay varios miles, aumentará el tiempo total de conmutación.
**Acción recomendada:** si la carga de trabajo de la base de datos permitiera el uso de un UUID compartido en lugar de un enfoque de secuencia por tabla, esto reduciría el paso de sincronización durante una conmutación.
**Umbral aproximado:** [miles](#PostgreSQL.HighObjectCount.Note)
## Objetos grandes
Los objetos grandes se almacenan en una sola tabla del sistema llamada pg\$1largeobject. Cada objeto grande también tiene una entrada en la tabla del sistema pg\$1largeobject\$1metadata. Estos objetos se crean, modifican y limpian de forma muy diferente a las relaciones estándar. Los objetos grandes no se manipulan con limpieza automática y deben limpiarse periódicamente mediante un proceso independiente llamado vacuumlo. Consulte la sección sobre administración de objetos grandes con el módulo lo para ver ejemplos sobre la administración de objetos grandes.
**Impacto: replicación lógica**
Los objetos grandes no se replican actualmente en PostgreSQL durante la replicación lógica. Para obtener más información, consulte [Página de restricciones en la documentación de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). En una configuración [azul/verde](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), esto significa que los objetos grandes del entorno azul no se replican en el entorno verde.
**Impacto: actualización a la versión principal**
Una actualización puede quedarse sin memoria y fallar si hay millones de objetos grandes y la instancia no puede gestionarlos durante una actualización. El proceso de actualización a la versión principal de PostgreSQL consta de dos amplias fases: el volcado del esquema a través de pg\$1dump y la restauración de este a través de pg\$1restore. Si su base de datos tiene millones de objetos de gran tamaño, debe asegurarse de que la instancia tenga memoria suficiente para gestionar pg\$1dump y pg\$1restore durante una actualización y escalarla a un tipo de instancia más grande.
**Prácticas recomendadas generales:**
+ Use regularmente la utilidad vacuumlo para eliminar cualquier objeto grande huérfano que pueda tener.
+ Considere la posibilidad de utilizar el tipo de datos BYTEA para almacenar los objetos grandes en la base de datos.
**Umbral aproximado:** [millones](#PostgreSQL.HighObjectCount.Note)
## Umbrales aproximados
Los umbrales aproximados que se mencionan en este tema solo se utilizan para proporcionar una estimación de hasta qué punto puede escalar un recurso en particular. Representan el rango general en el que los impactos descritos son más probables, pero el comportamiento real depende de la carga de trabajo, el tamaño de la instancia y la configuración específicos. Aunque es posible superar estas estimaciones, se deben respetar los cuidados y el mantenimiento para evitar los impactos mostrados.
# Administración de la contención de TOAST OID en Amazon RDS para PostgreSQL
TOAST (la técnica de almacenamiento de atributos sobredimensionados) es una característica de PostgreSQL diseñada para gestionar valores de datos de gran tamaño que superan el tamaño típico de un bloque de base de datos de 8 KB. PostgreSQL no permite que las filas físicas abarquen varios bloques. El tamaño del bloque actúa como límite superior del tamaño de las filas. TOAST supera esta restricción al dividir los valores de campo grandes en fragmentos más pequeños. Los almacena de forma independiente en una tabla TOAST específica vinculada a la tabla principal. Para obtener más información, consulte la [documentación de implementación y mecanismo de almacenamiento de PostgreSQL TOAST](https://www.postgresql.org/docs/current/storage-toast.html).
**Topics**
+ [Descripción de las operaciones de TOAST](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [Identificación de los desafíos de rendimiento](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [Recomendaciones](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [Supervisión](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## Descripción de las operaciones de TOAST
TOAST realiza la compresión y almacena valores de campo grandes fuera de línea. TOAST asigna un OID (identificador de objeto) único a cada fragmento de datos sobredimensionados almacenados en la tabla TOAST. La tabla principal almacena el ID del valor TOAST y el ID de relación en la página para hacer referencia a la fila correspondiente de la tabla TOAST. Esto permite a PostgreSQL localizar y administrar de forma eficiente estos fragmentos de TOAST. Sin embargo, a medida que crece la tabla de TOAST, el sistema corre el riesgo de agotar los OID disponibles, lo que provoca una degradación del rendimiento y un posible tiempo de inactividad debido al agotamiento de los OID.
### Identificadores de objetos en TOAST
Un identificador de objeto (OID) es un identificador único de todo el sistema que PostgreSQL utiliza para hacer referencia a objetos de bases de datos, como tablas, índices y funciones. Estos identificadores desempeñan un papel fundamental en las operaciones internas de PostgreSQL, ya que permiten a la base de datos localizar y administrar los objetos de forma eficiente.
Para las tablas con conjuntos de datos elegibles para acciones de toast, PostgreSQL asigna los OID para identificar de forma única cada fragmento de datos sobredimensionados almacenado en la tabla TOAST asociada. El sistema asocia cada fragmento con un `chunk_id`, lo que ayuda a PostgreSQL a organizar y ubicar estos fragmentos de manera eficiente dentro de la tabla TOAST.
## Identificación de los desafíos de rendimiento
La administración del OID de PostgreSQL se basa en un contador global de 32 bits para poder agrupar después de generar 4 mil millones de valores únicos. Aunque el clúster de bases de datos comparte este contador, la asignación del OID implica dos pasos durante las operaciones TOAST:
+ **Contador global de asignación**: el contador global asigna un nuevo OID a todo el clúster.
+ **Búsqueda local de conflictos**: la tabla TOAST garantiza que el nuevo OID no entre en conflicto con los OID existentes que ya se utilizan en esa tabla específica.
La degradación del rendimiento puede producirse cuando:
+ La tabla TOAST tiene una alta fragmentación o un uso denso del OID, lo que provoca retrasos en la asignación del OID.
+ Con frecuencia, el sistema asigna y reutiliza los OID en entornos con fragmentos de datos altos o tablas amplias que utilizan TOAST de forma extensiva.
Para obtener más información, consulte los [límites de tamaño de las tablas TOAST de PostgreSQL y la documentación de asignación de OID](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit):
Un contador global genera los OID y los agrupa cada 4000 millones de valores, de modo que, de vez en cuando, el sistema vuelve a generar un valor ya utilizado. PostgreSQL lo detecta y lo vuelve a intentar con el siguiente OID. Se puede producir INSERT lento si hay una serie muy larga de valores OID usados sin espacios en blanco en la tabla TOAST. Estos desafíos se hacen más pronunciados a medida que se va llenando el espacio del OID, lo que hace que las inserciones y actualizaciones sean más lentas.
### Identificación del problema
+ Las instrucciones `INSERT` simples tardan mucho más de lo habitual de forma incoherente y aleatoria.
+ Solo se producen retrasos en las instrucciones `INSERT` y `UPDATE` que implican operaciones de TOAST.
+ Las siguientes entradas de registro aparecen en los registros de PostgreSQL cuando el sistema tiene dificultades para encontrar los OID disponibles en las tablas TOAST:
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ La información de rendimiento indica un número elevado de sesiones activas de media (AAS) asociadas a eventos de espera `LWLock:buffer_io` y `LWLock:OidGenLock`.
Puede ejecutar la siguiente consulta SQL para identificar las transacciones INSERT de larga duración con eventos de espera:
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Ejemplos de resultados de consulta que muestran operaciones INSERT con tiempos de espera prolongados:
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Aislamiento del problema
+ **Pruebe una inserción pequeña**: inserte un registro más pequeño que el umbral `toast_tuple_target`. Recuerde que la compresión se aplica antes del almacenamiento de TOAST. Si esto funciona sin problemas de rendimiento, el problema está relacionado con las operaciones de TOAST.
+ **Pruebe la tabla nueva**: cree una tabla nueva con la misma estructura e ingrese un registro más grande que `toast_tuple_target`. Si esto funciona sin problemas, el problema se localiza en la asignación OID de la tabla original.
## Recomendaciones
Los siguientes enfoques pueden ayudar a resolver los problemas de contención de TOAST OID.
+ **Limpieza y archivado de datos**: revise y elimine cualquier dato obsoleto o innecesario para liberar los OID para su uso futuro o archive los datos. Tenga en cuenta las siguientes restricciones:
+ Escalabilidad limitada, ya que es posible que no siempre sea posible realizar limpiezas en el futuro.
+ Posible operación VACUUM de larga duración para eliminar las tuplas inactivas resultantes.
+ **Escriba en una tabla nueva**: cree una tabla nueva para futuras inserciones y utilice una vista `UNION ALL` para combinar datos antiguos y nuevos para las consultas. Esta vista presenta los datos combinados de las tablas antiguas y nuevas, lo que permite a las consultas acceder a ellos como una sola tabla. Tenga en cuenta las siguientes restricciones:
+ Es posible que las actualizaciones de la tabla antigua sigan agotando los OID.
+ **Partición o fragmento**: particione los datos de la tabla o del fragmento para mejorar la escalabilidad y el rendimiento. Tenga en cuenta las siguientes restricciones:
+ El aumento de la complejidad de la lógica y el mantenimiento de las consultas, y la posible necesidad de realizar cambios en las aplicaciones para gestionar correctamente los datos particionados.
## Supervisión
### Uso de tablas de sistemas
Puede utilizar las tablas del sistema de PostgreSQL para supervisar el aumento del uso de los OID.
**aviso**
En función del número de OID de la tabla de TOAST, puede tardar un tiempo en completarse. Le recomendamos que programe la supervisión fuera del horario laboral para minimizar el impacto.
El siguiente bloque anónimo cuenta el número de OID distintos que se utilizan en cada tabla de TOAST y muestra la información de la tabla principal:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Ejemplo de salida que muestra las estadísticas de uso de los OID por tabla de TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
El siguiente bloque anónimo recupera el OID máximo asignado para cada tabla de TOAST que no esté vacía:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Ejemplo de salida que muestra el número máximo de ID de fragmentos para las tablas de TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Uso de información sobre rendimiento
Los eventos de espera `LWLock:buffer_io` y `LWLock:OidGenLock` aparecen en la información de rendimiento durante las operaciones que requieren la asignación de nuevos identificadores de objeto (OID). El promedio alto de sesiones activas (AAS) de estos eventos suele indicar que hay problemas durante la asignación de los OID y la administración de los recursos. Esto es particularmente común en entornos con una alta cantidad de datos, un uso extensivo de datos de gran tamaño o una creación frecuente de objetos.
#### LWLock:buffer\$1io
`LWLock:buffer_io` es un evento de espera que se produce cuando una sesión de PostgreSQL espera a que se completen las operaciones de E/S en un búfer compartido. Esto suele ocurrir cuando la base de datos lee datos del disco a la memoria o escribe páginas modificadas de la memoria al disco. El evento de espera de `BufferIO` garantiza la coherencia al impedir que varios procesos accedan o modifiquen el mismo búfer mientras las operaciones de E/S están en curso. La alta incidencia de este evento de espera puede indicar cuellos de botella en el disco o una actividad de E/S excesiva en la carga de trabajo de la base de datos.
Durante las operaciones de TOAST:
+ PostgreSQL asigna los OID a los objetos grandes y garantiza su exclusividad escaneando el índice de la tabla de TOAST.
+ Los índices de TOAST de gran tamaño pueden requerir el acceso a varias páginas para verificar la exclusividad de los OID. Esto se traduce en un aumento de la E/S del disco, especialmente cuando el grupo de búferes no puede almacenar en caché todas las páginas requeridas.
El tamaño del índice afecta directamente a la cantidad de páginas del búfer a las que se debe acceder durante estas operaciones. Incluso si el índice no está sobrecargado, su gran tamaño puede aumentar la E/S del búfer, especialmente en entornos de alta concurrencia o alta rotación. Para obtener más información, consulte la [LWLock:BufferIO wait event troubleshooting guide](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html).
#### LWLock:OidGenLock
`OidGenLock` es un evento de espera que se produce cuando una sesión de PostgreSQL está esperando para asignar un nuevo identificador de objetos (OID). Este bloqueo garantiza que los OID se generen de forma secuencial y segura, lo que permite que solo un proceso genere los OID a la vez.
Durante las operaciones de TOAST:
+ **Asignación de OID para los fragmentos de la tabla de TOAST**: PostgreSQL asigna los OID a los fragmentos de las tablas de TOAST al administrar registros de datos de gran tamaño. Cada OID debe ser único para evitar conflictos en el catálogo del sistema.
+ **Alta simultaneidad**: dado que el acceso al generador de OID es secuencial, cuando varias sesiones crean simultáneamente objetos que requieren OID, se puede producir contención para `OidGenLock`. Esto aumenta la probabilidad de que las sesiones esperen a que se complete la asignación de los OID.
+ **Dependencia del acceso al catálogo del sistema**: la asignación de los OID requiere actualizaciones en las tablas del catálogo del sistema compartido, como `pg_class` y `pg_type`. Si estas tablas tienen mucha actividad (debido a las frecuentes operaciones de DDL), puede aumentar la contención de bloqueos para `OidGenLock`.
+ **Alta demanda de asignación del OID**: las cargas de trabajo pesadas de TOAST con registros de datos de gran tamaño requieren una asignación coherente del OID, lo que aumenta la contención.
Factores adicionales que aumentan la contención del OID:
+ **Creación frecuente de objetos**: las cargas de trabajo que crean y descartan objetos con frecuencia, como tablas temporales, aumentan la contención en el contador de OID global.
+ **Bloqueo del contador global**: se accede en serie al contador de OID global para garantizar su exclusividad, lo que crea un único punto de contención en entornos de alta concurrencia.
## Uso de mecanismos de registro admitidos por RDS for PostgreSQL
Hay varios parámetros, extensiones y otros elementos configurables que puede establecer para registrar actividades que ocurren en su instancia de base de datos de PostgreSQL. Estos incluyen los siguientes:
+ El parámetro `log_statement` se puede usar para registrar la actividad del usuario en su base de datos de PostgreSQL. Para obtener más información sobre el registro de RDS for PostgreSQL y cómo monitorear los registros, consulte [Archivos de registro de base de datos de RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
+ El parámetro `rds.force_admin_logging_level` registra las acciones del usuario interno de Amazon RDS (rdsadmin) en las bases de datos de la instancia de base de datos. Escribe la salida en el registro de errores de PostgreSQL. Los valores permitidos son `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, registro, `fatal`, y `panic`. El valor predeterminado es `disabled`.
+ El parámetro `rds.force_autovacuum_logging_level` se puede configurar para capturar varias operaciones autovacuum en el registro de errores de PostgreSQL. Para obtener más información, consulte [Registro de actividades de autovacuum y vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ La extensión PostgreSQL Audit (pgAudit) se puede instalar y configurar para capturar actividades a nivel de sesión o a nivel de objeto. Para obtener más información, consulte [Uso de pgAudit para registrar la actividad de la base de datos](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ La extensión `log_fdw` le permite acceder al registro del motor de la base de datos mediante SQL. Para obtener más información, consulte [Uso de la extensión log\$1fdw para acceder al registro de base de datos mediante SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ La biblioteca `pg_stat_statements` se especifica como predeterminada para el parámetro `shared_preload_libraries` en la versión 10 y superiores de RDS for PostgreSQL. Es esta biblioteca la que puede usar para analizar consultas en ejecución. Asegúrese de que `pg_stat_statements` se establezca en el grupo de parámetros de base de datos. Para obtener más información sobre cómo supervisar su instancia de base de datos de RDS for PostgreSQL por medio de la información que proporciona esta biblioteca, consulte [Estadísticas de SQL de RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ El parámetro `log_hostname` captura en el registro el nombre de host de cada conexión de cliente. Para RDS para PostgreSQL versión 12 y posteriores, este parámetro se establece como `off` de forma predeterminada. Si lo activa, asegúrese de supervisar los tiempos de conexión de las sesiones. Cuando está activado, el servicio utiliza la solicitud de búsqueda inversa del sistema de nombres de dominio (DNS) para obtener el nombre de host del cliente que realiza la conexión y agregarlo al registro de PostgreSQL. Esto tiene un impacto notable durante la conexión a la sesión. Le recomendamos que active este parámetro solo para resolver problemas.
En términos generales, el objetivo del registro es que el DBA pueda supervisar, ajustar el rendimiento y solucionar problemas. Muchos de los registros se cargan automáticamente en Amazon CloudWatch o en Información sobre rendimiento. Aquí, se ordenan y agrupan para proporcionar métricas completas para su instancia de base de datos. Para obtener más información sobre la supervisión y las métricas de Amazon RDS, visite [Supervisión de métricas en una instancia de Amazon RDS](CHAP_Monitoring.md).
# Administración de archivos temporales con PostgreSQL
En PostgreSQL, una consulta compleja puede realizar varias operaciones de ordenación y hash al mismo tiempo, y cada una de ellas utiliza memoria de la instancia para almacenar los resultados hasta el valor especificado en el parámetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Cuando la memoria de la instancia no es suficiente, se crean archivos temporales para almacenar los resultados. Se escriben en el disco para completar la ejecución de la consulta. Posteriormente, una vez finalizada la consulta, estos archivos se eliminan automáticamente. En RDS para PostgreSQL, estos archivos se almacenan en Amazon EBS en el volumen de datos. Para obtener más información, consulte [Almacenamiento de instancias de base de datos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Puede monitorizar la métrica de `FreeStorageSpace` publicada en CloudWatch para asegurarse de que la instancia de base de datos tenga suficiente espacio de almacenamiento libre. Para obtener más información, consulte [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm)..
Recomendamos utilizar instancias de lecturas optimizadas para Amazon RDS para las cargas de trabajo que implican múltiples consultas simultáneas que aumentan el uso de archivos temporales. Estas instancias utilizan almacenamiento por bloques local basado en unidades de estado sólido (SSD) de memoria rápida no volátil (NVMe) para colocar los archivos temporales. Para obtener más información, consulte [Mejora del rendimiento de las consultas de RDS para PostgreSQL con lecturas optimizadas para Amazon RDS](USER_PostgreSQL.optimizedreads.md).
Puede utilizar los siguientes parámetros y funciones para administrar los archivos temporales de la instancia.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – este parámetro cancela cualquier consulta que supere el tamaño de temp\$1files en KB. Este límite evita que cualquier consulta se ejecute de forma indefinida y consuma espacio en disco con archivos temporales. Puede calcular el valor utilizando los resultados del parámetro `log_temp_files`. Como práctica recomendada, examine el comportamiento de la carga de trabajo y establezca el límite de acuerdo con la estimación. En el siguiente ejemplo, se cancela una consulta cuando se supera el límite.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – este parámetro envía mensajes a postgresql.log cuando se eliminan los archivos temporales de una sesión. Este parámetro produce registros después de que la consulta se complete correctamente. Por lo tanto, puede que no ayude a solucionar problemas de consultas activas y de larga ejecución.
El ejemplo siguiente muestra que, cuando la consulta se completa correctamente, las entradas se registran en el archivo postgresql.log y se limpian los archivos temporales.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – esta función que está disponible desde RDS para PostgreSQL 13 y versiones posteriores proporciona visibilidad sobre el uso actual de los archivos temporales. La consulta completada no aparece en los resultados de la función. En el siguiente ejemplo, puede ver los resultados de esta función.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
El nombre del archivo incluye el ID de procesamiento (PID) de la sesión que generó el archivo temporal. Una consulta más avanzada, como en el ejemplo siguiente, realiza una suma de los archivos temporales de cada PID.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – si activa el parámetro pg\$1stat\$1statements, puede ver el uso medio de archivos temporales por llamada. Puede identificar el query\$1id de la consulta y usarlo para examinar el uso de archivos temporales, como se muestra en el siguiente ejemplo.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`**: en el panel de Información sobre el rendimiento, puede ver el uso temporal de los archivos activando las métricas **temp\$1bytes** y **temp\$1files**. A continuación, puede ver la media de estas dos métricas y cómo se corresponden con la carga de trabajo de la consulta. La vista de Información sobre el rendimiento no muestra específicamente las consultas que generan los archivos temporales. Sin embargo, al combinar Información sobre el rendimiento con la consulta que se muestra para `pg_ls_tmpdir`, puede solucionar problemas, realizar análisis y determinar los cambios en la carga de trabajo de la consulta.
Para obtener más información sobre cómo analizar métricas y consultas con Información de rendimiento, consulte [Análisis de métricas mediante el panel de Información sobre rendimiento](USER_PerfInsights.UsingDashboard.md).
Para ver un ejemplo sobre la visualización del uso de archivos temporales con Información de rendimiento, consulte [Visualización del uso de archivos temporales con Información de rendimiento](PostgreSQL.ManagingTempFiles.Example.md)
# Visualización del uso de archivos temporales con Información de rendimiento
Puede usar Información de rendimiento para consultar el uso de archivos temporales activando las métricas **temp\$1bytes** y **temp\$1files**. En Información de rendimiento, la vista no muestra las consultas específicas que generan archivos temporales; sin embargo, si combina Información de rendimiento con la consulta mostrada para `pg_ls_tmpdir`, puede solucionar problemas, realizar análisis y determinar cuáles son los cambios necesarios en la carga de trabajo de consultas.
1. En el panel de Información sobre el rendimiento, elija **Administrar métricas**.
1. Elija las **Métricas de la base de datos** y seleccione las métricas **temp\$1bytes** y **temp\$1files** como se muestra en la siguiente captura de pantalla.
![\[Las métricas se muestran en el gráfico.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. En la pestaña **Principales SQL**, seleccione el icono **Preferencias**.
1. En la ventana **Preferencias**, active las siguientes estadísticas para que aparezcan en la pestaña **Principales SQL** y seleccione **Continuar**.
+ Escrituras temporales por segundo
+ Lecturas temporales por segundo
+ Escritura temporal en bloque por llamada
+ Lectura temporal en bloque por llamada
1. El archivo temporal se divide cuando se combina con la consulta mostrada para `pg_ls_tmpdir`, como se observa en el siguiente ejemplo.
![\[Consulta que muestra el uso de archivos temporales.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Los eventos `IO:BufFileRead` y `IO:BufFileWrite` se producen cuando las consultas principales de la carga de trabajo crean archivos temporales a menudo. Puede utilizar la Información de rendimiento para identificar las principales consultas pendientes en `IO:BufFileRead` e `IO:BufFileWrite` mediante la revisión del promedio de sesiones activas (AAS) en las secciones de carga de base de datos y SQL principales.
![\[IO:BufFileRead e IO:BufFileWrite en el gráfico.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Para obtener más información sobre cómo analizar las consultas principales y cargar mediante eventos de espera con Información de Rendimiento, consulte [Información general sobre la pestaña Top SQL (SQL principal)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Debe identificar y ajustar las consultas que provocan el aumento del uso de archivos temporales y los eventos de espera relacionados. Para obtener más información sobre estos eventos de espera y su corrección, consulte [IO:BufFileRead e IO:BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html).
**nota**
El parámetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) controla cuándo se agota la memoria de la operación de ordenación y los resultados se escriben en archivos temporales. Se recomienda no cambiar la configuración de este parámetro por encima del valor predeterminado, ya que haría que cada sesión de base de datos consumiera más memoria. Además, una sola sesión que realiza combinaciones y ordenaciones complejas puede realizar operaciones paralelas en las que cada operación consume memoria.
Como práctica recomendada, cuando tenga un informe de gran tamaño con múltiples combinaciones y ordenaciones, defina este parámetro en el nivel de sesión mediante el comando `SET work_mem`. Por tanto, el cambio solo se aplica a la sesión actual y no cambia el valor globalmente.
## Uso de pgBadger para el análisis de registros con PostgreSQL
Puede usar un analizador de registros como [pgbadger](http://dalibo.github.io/pgbadger/) para analizar los registros de PostgreSQL. La documentación de pgBadger establece que el patrón %l (la línea de registro para la sesión o el proceso) debe ser parte del prefijo. Sin embargo, si proporciona el RDS actual `log_line_prefix` como parámetro a pgBadger, aún debería generar un informe.
Por ejemplo, el siguiente comando asigna el formato correcto a un archivo de registro de Amazon RDS para PostgreSQL con fecha 04-02-2014 con pgbadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## Uso de PGSnapper para supervisar PostgreSQL
Puede utilizar PGSnapper para facilitar la recopilación periódica de estadísticas y métricas relacionadas con el rendimiento de Amazon RDS para PostgreSQL. Para obtener más información, consulte[ Monitor Amazon RDS for PostgreSQL performance using PGSnapper](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/) (Supervise el rendimiento de Amazon RDS para PostgreSQL con PGSnapper).
# Gestión de conversiones personalizadas en RDS para PostgreSQL
La **conversión de tipos** en PostgreSQL es el proceso de convertir un valor de un tipo de dato a otro. PostgreSQL proporciona conversiones integradas para muchas transformaciones comunes, pero también puede crear conversiones personalizadas para definir cómo deben comportarse determinadas conversiones entre tipos.
Una conversión especifica cómo se lleva a cabo la transformación de un tipo de dato a otro. Por ejemplo, convertir texto `'123'` en entero `123` o numérico `45.67` en texto `'45.67'`.
Para obtener información completa sobre los conceptos y la sintaxis de la conversión de PostgreSQL, consulte la documentación CREATE CAST de [PostgreSQL](https://www.postgresql.org/docs/current/sql-createcast.html).
A partir de las versiones 13.23, 14.20, 15.15, 16.11, 17.7 y 18.1 de RDS para PostgreSQL, puede utilizar la extensión rds\$1casts para instalar conversiones adicionales para tipos integrados, sin dejar de poder crear sus propias conversiones para tipos personalizados.
**Topics**
+ [Instalación y uso de la extensión rds\$1casts](#PostgreSQL.CustomCasts.Installing)
+ [Conversiones compatibles](#PostgreSQL.CustomCasts.Supported)
+ [Creación o eliminación de conversiones](#PostgreSQL.CustomCasts.Creating)
+ [Creación de conversiones personalizadas con la estrategia de contexto adecuada](#PostgreSQL.CustomCasts.BestPractices)
## Instalación y uso de la extensión rds\$1casts
Para crear la extensión `rds_casts`, conéctese a la instancia de DB de RDS para PostgreSQL como un `rds_superuser` y ejecute el siguiente comando:
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Conversiones compatibles
Cree la extensión en cada base de datos en la que desee utilizar conversiones personalizadas. Tras crear la extensión, utilice el siguiente comando para ver todas las conversiones disponibles:
```
SELECT * FROM rds_casts.list_supported_casts();
```
Esta función muestra las combinaciones de conversión disponibles (tipo de fuente, tipo de objetivo, contexto de coerción y función de conversión). Por ejemplo, si desea crear `text` a `numeric` como una conversión de `implicit`. Puede utilizar la siguiente consulta para buscar si la conversión está disponible para crearse:
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
La extensión rds\$1casts proporciona dos tipos de funciones de conversión para cada conversión:
+ *\$1inout functions*: utilizar el mecanismo de conversión de E/S estándar de PostgreSQL, que se comporta de forma idéntica a las conversiones creadas con el método INOUT.
+ *\$1custom functions*: proporcionar una lógica de conversión mejorada que gestione casos de periferia, como convertir cadenas vacías en valores NULL para evitar errores de conversión.
Las funciones `inout` reproducen el comportamiento de conversión nativo de PostgreSQL, mientras que las funciones `custom` amplían esta funcionalidad al gestionar situaciones que las conversiones de INOUT estándar no pueden admitir, como la conversión de cadenas vacías en números enteros.
## Creación o eliminación de conversiones
Puede crear y soltar conversiones compatibles mediante dos métodos:
### Creación de conversión
**Método 1: usar el comando nativo CREATE CAST**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Método 2: usar la función rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
La función `create_cast` toma el ID del resultado `list_supported_casts()`. Este método es más sencillo y garantiza que se utilice la combinación correcta de función y contexto. Se garantiza que este identificador seguirá siendo el mismo en las diferentes versiones de Postgres.
Para comprobar que la conversión se creó correctamente, consulte el catálogo del sistema pg\$1cast:
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
La columna `castcontext` muestra: `e` para EXPLICIT, `a` para ASSIGNMENT o `i` para IMPLICIT.
### Cómo soltar las conversiones
**Método 1: usar el comando DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Método 2: usar la función rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
La función `drop_cast` utiliza el mismo identificador que se utilizó al crear la conversión. Este método garantiza que suelte la conversión exacta que se creó con el ID correspondiente.
## Creación de conversiones personalizadas con la estrategia de contexto adecuada
Al crear varias conversiones para tipos enteros, se pueden producir errores de ambigüedad de operadores si todas las conversiones se crean como IMPLICIT. El siguiente ejemplo muestra este problema mediante la creación de dos conversiones implícitas de texto a anchuras de enteros diferentes:
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
El error se produce porque PostgreSQL no puede determinar qué conversión implícita utilizar al comparar una columna de enteros con un valor de texto. Tanto la conversión implícita int4 como la int8 son candidatas válidas, lo que crea ambigüedad.
Para evitar esta ambigüedad de operadores, utilice el contexto ASSIGNMENT para anchuras de enteros más pequeñas y el contexto IMPLICIT para anchuras de enteros más grandes:
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Con esta estrategia, solo la conversión int8 es implícita, por lo que PostgreSQL puede determinar sin ambigüedades qué conversión utilizar.
# Prácticas recomendadas para consultas paralelas en RDS para PostgreSQL
La ejecución de consultas paralelas es una característica de PostgreSQL que permite dividir una sola consulta SQL en tareas más pequeñas que se procesan simultáneamente mediante varios procesos de trabajo en segundo plano. En lugar de ejecutar una consulta por completo en un único proceso de backend, PostgreSQL puede distribuir partes de la consulta, como análisis, uniones, agregaciones o clasificación, en varios núcleos de CPU. El *proceso líder* coordina esta ejecución y recopila los resultados de los *trabajadores paralelos*.
Sin embargo, para la mayoría de las cargas de trabajo de producción, especialmente para los sistemas OLTP de alta concurrencia, recomendamos desactivar la ejecución automática de consultas en paralelo. Aunque el paralelismo puede acelerar las consultas en grandes conjuntos de datos en las cargas de trabajo de análisis o elaboración de informes, presenta riesgos importantes que, a menudo, superan los beneficios en entornos de producción muy ajetreados.
La ejecución paralela también supone una sobrecarga significativa. Cada servidor paralelo es un proceso completo de backend de PostgreSQL, que requiere la bifurcación del proceso (copiar las estructuras de la memoria e inicializar el estado del proceso) y la autenticación (consumir los espacios de conexión hasta el límite `max_connections`). Cada trabajador también consume su propia memoria, incluso `work_mem` para las operaciones de clasificación y cifrado, con varios trabajadores por consulta, el uso de la memoria se multiplica rápidamente (por ejemplo, 4 trabajadores × 64 MB `work_mem` = 256 MB por consulta). Como resultado, las consultas paralelas pueden consumir considerablemente más recursos del sistema que las consultas de un solo proceso. Si no se ajustan correctamente, pueden provocar una saturación de la CPU (varios trabajadores abruman la capacidad de procesamiento disponible), un aumento del cambio de contexto (el sistema operativo cambia con frecuencia entre varios procesos de trabajo, lo que aumenta la sobrecarga y reduce el rendimiento) o el agotamiento de la conexión (dado que cada trabajador paralelo consume una ranura de conexión, una sola consulta con 4 trabajadores utiliza 5 conexiones en total, 1 líder \$1 4 trabajadores, lo que puede agotar rápidamente el grupo de conexiones con una alta concurrencia, lo que impide nuevas conexiones de clientes y provoca errores en las aplicaciones). Estos problemas son particularmente graves en cargas de trabajo de alta concurrencia en las que varias consultas pueden intentar ejecutarse en paralelo simultáneamente.
PostgreSQL decide si utilizar el paralelismo en función de las estimaciones de costos. En algunos casos, el planificador puede cambiar automáticamente a un plan paralelo si parece más económico, incluso cuando no es lo ideal en la práctica. Esto puede suceder si las estadísticas de los índices están desactualizadas o si la sobrecarga hace que los análisis secuenciales parezcan más atractivos que las búsquedas de índices. Debido a este comportamiento, los planes paralelos automáticos a veces pueden presentar regresiones en el rendimiento de las consultas o en la estabilidad del sistema.
Para aprovechar al máximo las consultas paralelas en RDS para PostgreSQL, es importante probarlas y ajustarlas en función de la carga de trabajo, supervisar el impacto en el sistema y desactivar la selección automática de planes paralelos en favor del control por consulta.
## Parámetros de configuración
PostgreSQL utiliza varios parámetros para controlar el comportamiento y la disponibilidad de las consultas paralelas. Comprenderlos y ajustarlos es fundamental para lograr un rendimiento predecible:
| Parámetro | Descripción | Valor predeterminado |
| --- | --- | --- |
| max\$1parallel\$1workers | Número máximo de procesos de trabajo en segundo plano que se pueden ejecutar en total | GREATEST(\$1DBInstanceVCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Número máximo de trabajadores por nodo del plan de consultas (por ejemplo, por Gather) | 2 |
| parallel\$1setup\$1cost | Se ha agregado el costo del planificador para iniciar la infraestructura de consultas paralelas | 1 000 |
| parallel\$1tuple\$1cost | Costo por tupla procesada en modo paralelo (afecta a la decisión del planificador) | 0.1 |
| force\$1parallel\$1mode | Obliga al planificador a probar planes paralelos (off, on, regress) | off |
### Consideraciones clave
+ `max_parallel_workers` controla el grupo total de trabajadores paralelos. Si se establece un valor demasiado bajo, algunas consultas pueden volver a ejecutarse en serie.
+ `max_parallel_workers_per_gather` afecta al número de trabajadores que puede utilizar una sola consulta. Un valor más alto aumenta la simultaneidad, pero también el uso de los recursos.
+ `parallel_setup_cost` y `parallel_tuple_cost` afectan al modelo de costos del planificador. Reducirlos puede hacer que sea más probable que se elijan planes paralelos.
+ `force_parallel_mode` es útil para realizar pruebas, pero no se debe utilizar en producción a menos que sea necesario.
**nota**
El valor predeterminado del parámetro `max_parallel_workers` se calcula dinámicamente en función del tamaño de la instancia mediante la fórmula `GREATEST($DBInstanceVCPU/2, 8)`. Esto significa que al escalar la instancia de base de datos a un tamaño de procesamiento mayor con más vCPU, el número máximo de trabajadores paralelos disponibles aumentará automáticamente. Como resultado, las consultas que antes se ejecutaban en serie o con un paralelismo limitado pueden utilizar repentinamente más trabajadores paralelos después de una operación de escalar verticalmente, lo que podría provocar aumentos inesperados en el uso de la conexión, la utilización de la CPU y el consumo de memoria. Es importante supervisar el comportamiento de las consultas en paralelo después de cualquier evento de escalado de computación y ajustar `max_parallel_workers_per_gather` si es necesario para mantener un uso predecible de los recursos.
## Identificación del uso de consultas paralelas
Las consultas pueden pasar a planes paralelos en función de la distribución de datos o las estadísticas. Por ejemplo:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Esta consulta puede usar un índice para datos recientes, pero cambiar a un análisis secuencial paralelo para datos históricos.
Puede registrar los planes de ejecución de consultas cargando el módulo `auto_explain`. Para obtener más información, consulte [Logging execution plans of queries](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) (Registro de los planes de ejecución de las consultas) en el centro de conocimiento de AWS.
Puede supervisar la [Información sobre las bases de datos de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) para detectar eventos de espera relacionados con consultas paralelas. Obtención de más información sobre los eventos de espera relacionados con consultas paralelas, mediante [Eventos de espera de IPC:parallel](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html)
A partir de la versión 18 de PostgreSQL, puede supervisar la actividad de los trabajadores en paralelo mediante columnas nuevas en [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW) y [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html):
+ `parallel_workers_to_launch`: número de trabajadores paralelos que se prevé lanzar
+ `parallel_workers_launched`: número de trabajadores paralelos realmente lanzados
Estas métricas ayudan a identificar las discrepancias entre el paralelismo planificado y el real, lo que puede indicar limitaciones de recursos o problemas de configuración. Utilice las siguientes consultas para supervisar la ejecución paralela:
Para las métricas de trabajadores paralelos por base de datos:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Para las métricas de trabajadores paralelos por consulta
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Cómo controlar el paralelismo
Existen varias formas de controlar el paralelismo de consultas, cada una diseñada para diferentes escenarios y requisitos.
Para desactivar el paralelismo automático de forma global, [modifique el grupo de parámetros](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html) para establecer:
```
max_parallel_workers_per_gather = 0;
```
Para configuraciones persistentes y específicas del usuario, el comando ALTER ROLE proporciona una forma de establecer los parámetros que se aplicarán a todas las sesiones futuras de un usuario en particular.
Por ejemplo:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;` garantiza que cada vez que este usuario se conecte a la base de datos, sus sesiones utilizarán esta configuración de trabajo paralelo cuando sea necesario.
El control por sesión se puede lograr mediante el comando SET, que modifica los parámetros durante la sesión de la base de datos actual. Esto resulta especialmente útil cuando se deben ajustar temporalmente los ajustes sin que ello afecte a otros usuarios o sesiones futuras. Una vez configurados, estos parámetros permanecen en vigor hasta que se restablezcan explícitamente o hasta que finalice la sesión. Los comandos son sencillos:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Para un control aún más detallado, SET LOCAL permite modificar los parámetros de una sola transacción. Esto resulta ideal cuando se necesita ajustar la configuración para un conjunto específico de consultas dentro de una transacción, tras lo cual la configuración vuelve automáticamente a sus valores anteriores. Este enfoque ayuda a evitar efectos no deseados en otras operaciones de la misma sesión.
## Diagnóstico del comportamiento de consultas paralelas
Se usa `EXPLAIN (ANALYZE, VERBOSE)` para confirmar si una consulta utilizó la ejecución paralela:
+ Busque nodos como `Gather`, `Gather Merge` o `Parallel Seq Scan`.
+ Compare planes con y sin paralelismo.
Para desactivar temporalmente el paralelismo para la comparación:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL
En algunos casos, puede crear una instancia de base de datos de RDS for PostgreSQL sin especificar un grupo de parámetros personalizado. De ser el caso, la instancia de base de datos se crea por medio del grupo de parámetros predeterminado para la versión de PostgreSQL que elija. Por ejemplo, suponga que crea una instancia de base de datos de RDS for PostgreSQL por medio de la versión 13.3 de PostgreSQL. En este caso, la instancia de base de datos se crea por medio de los valores del grupo de parámetros para las versiones 13 de PostgreSQL, `default.postgres13`.
También puede crear su propio grupo de parámetros de base de datos personalizado. Debe hacer esto si desea modificar cualquier configuración para la instancia de base de datos de RDS for PostgreSQL a partir de sus valores predeterminados. Para aprender a hacerlo, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Puede realizar un seguimiento de la configuración en su instancia de base de datos de RDS for PostgreSQL de varias maneras diferentes. Puede utilizar la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS. También puede consultar los valores de la tabla `pg_settings` de PostgreSQL de la instancia, como se muestra a continuación.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Para obtener más información sobre los valores que se muestran en esta consulta, consulte [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) en la documentación de PostgreSQL.
Tenga especial cuidado cuando cambie la configuración de `max_connections` y `shared_buffers` en la instancia de base de datos de RDS for PostgreSQL. Por ejemplo, suponga que modifica la configuración para `max_connections` o `shared_buffers` y utiliza valores que son demasiado altos para la carga de trabajo real. En este caso, su instancia de base de datos de RDS for PostgreSQL no se iniciará. Si esto ocurre, verá un error como el siguiente en el `postgres.log`.
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Sin embargo, no puede cambiar ningún valor de la configuración contenida en los grupos de parámetros de base de datos de RDS for PostgreSQL predeterminados. Para cambiar la configuración de cualquier parámetro, primero cree un grupo de parámetros de base de datos personalizado. Luego, cambie la configuración en ese grupo personalizado y, luego, aplique el grupo de parámetros personalizado a su instancia de base de datos de RDS for PostgreSQL. Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Hay dos tipos de parámetros en RDS para PostgreSQL.
+ **Parámetros estáticos**: los parámetros estáticos requieren que la instancia de la base de datos RDS for PostgreSQL se reinicie después de un cambio para que el nuevo valor tenga efecto.
+ **Parámetros dinámicos**: los parámetros dinámicos no requieren un reinicio después de cambiar su configuración.
**nota**
Si su instancia de base de datos de RDS for PostgreSQL utiliza su propio grupo de parámetros de base de datos personalizado, puede cambiar los valores de los parámetros dinámicos en la instancia de base de datos en ejecución. Puede hacerlo mediante la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS.
Si tiene privilegios para hacerlo, también puede cambiar los valores de los parámetros con los comandos `ALTER DATABASE`, `ALTER ROLE` y `SET`.
## Lista de parámetros de la instancia de base de datos de RDS for PostgreSQL
La siguiente tabla enumera algunos de (pero no todos) los parámetros disponibles en una instancia de base de datos RDS for PostgreSQL. Para ver todos los parámetros disponibles, utilice el comando [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) de AWS CLI. Por ejemplo, para obtener la lista de todos los parámetros disponibles en el grupo de parámetros predeterminado de RDS para PostgreSQL versión 13, ejecute lo siguiente.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
También puede usar la consola. Elija **grupos de parámetros** en el menú de Amazon RDS y, a continuación, elija el grupo de parámetros entre los disponibles en suRegión de AWS.
| Nombre del parámetro | Apply\$1Type | Descripción |
| --- | --- | --- |
| `application_name` | Dinámico | Define el nombre de la aplicación sobre la que informarán las estadísticas y los registros. |
| `archive_command` | Dinámico | Establece el comando del shell que se llamará para archivar un archivo WAL. |
| `array_nulls` | Dinámico | Permite la entrada de elementos NULL en matrices. |
| `authentication_timeout` | Dinámico | Establece el tiempo máximo permitido para completar una autenticación del cliente. |
| `autovacuum` | Dinámico | Inicia el subproceso de autovacuum. |
| `autovacuum_analyze_scale_factor` | Dinámico | Número de inserciones, actualizaciones o eliminaciones de tuplas previas al análisis como una fracción de reltuples. |
| `autovacuum_analyze_threshold` | Dinámico | Número mínimo de inserciones, actualizaciones o eliminaciones de tuplas previas al análisis. |
| `autovacuum_freeze_max_age` | Estático | Antigüedad con la que se debe aplicar autovacuum a una tabla para impedir el reinicio de los ID. |
| `autovacuum_naptime` | Dinámico | Tiempo de reposo entre ejecuciones de autovacuum. |
| `autovacuum_max_workers` | Estático | Define el número máximo de procesos de empleados de autovacuum que se ejecutan simultáneamente. |
| `autovacuum_vacuum_cost_delay` | Dinámico | Retardo del costo del vacío, en milisegundos, para autovacuum. |
| `autovacuum_vacuum_cost_limit` | Dinámico | Importe del costo del vacío disponible antes del periodo de reposo para autovacuum. |
| `autovacuum_vacuum_scale_factor` | Dinámico | Número de actualizaciones o eliminaciones de tuplas previas al vacío como una fracción de reltuples. |
| `autovacuum_vacuum_threshold` | Dinámico | Número mínimo de actualizaciones o eliminaciones de tuplas previas al vacío. |
| `backslash_quote` | Dinámico | Define si se admite una barra diagonal invertida (\$1) en el texto de las cadenas. |
| `bgwriter_delay` | Dinámico | Tiempo de reposo del escritor de segundo plano entre una ronda y la siguiente. |
| `bgwriter_lru_maxpages` | Dinámico | Número máximo de páginas de LRU del escritor de segundo plano que se deben vaciar en cada ronda. |
| `bgwriter_lru_multiplier` | Dinámico | Múltiplo del uso medio del búfer que se debe liberar en cada ronda. |
| `bytea_output` | Dinámico | Establece el formato de salida para bytes. |
| `check_function_bodies` | Dinámico | Comprueba los cuerpos de las funciones durante la ejecución de CREATE FUNCTION. |
| `checkpoint_completion_target` | Dinámico | Tiempo requerido para vaciar los búferes sucios durante el punto de comprobación expresado como una fracción del intervalo del punto de comprobación. |
| `checkpoint_segments` | Dinámico | Define la distancia máxima en los segmentos de registro entre los puntos de comprobación de registro previo a la lectura (WAL) automáticos. |
| `checkpoint_timeout` | Dinámico | Define el tiempo máximo entre los puntos de comprobación de WAL automáticos. |
| `checkpoint_warning` | Dinámico | Habilita las advertencias si los segmentos del punto de comprobación se rellenan con una frecuencia superior a esta. |
| `client_connection_check_interval` | Dinámico | Establece el intervalo de tiempo entre las comprobaciones de desconexión mientras se ejecutan las consultas. |
| `client_encoding` | Dinámico | Define la codificación del conjunto de caracteres del cliente. |
| `client_min_messages` | Dinámico | Define los niveles de los mensajes que se envían al cliente. |
| `commit_delay` | Dinámico | Define el retardo en microsegundos entre la confirmación de la transacción y el vaciado de WAL al disco. |
| `commit_siblings` | Dinámico | Define el número mínimo de transacciones abiertas concurrentes antes de ejecutar commit\$1delay. |
| `constraint_exclusion` | Dinámico | Habilita el planificador para que use restricciones con el fin de optimizar las consultas. |
| `cpu_index_tuple_cost` | Dinámico | Define la estimación del planificador del costo de procesar cada entrada de índice durante un examen del índice. |
| `cpu_operator_cost` | Dinámico | Define la estimación del planificador del costo de procesar cada llamada a operador o a función. |
| `cpu_tuple_cost` | Dinámico | Define la estimación del planificador del costo de procesar cada tupla (fila). |
| `cursor_tuple_fraction` | Dinámico | Define la estimación del planificador de la fracción de las filas de un cursor que se recuperarán. |
| `datestyle` | Dinámico | Define el formato de visualización para los valores de fecha y hora. |
| `deadlock_timeout` | Dinámico | Define el tiempo de espera de una interrupción antes de comprobar si se ha producido un bloqueo. |
| `debug_pretty_print` | Dinámico | Aplica una sangría a las visualizaciones del árbol de análisis y de planificación. |
| `debug_print_parse` | Dinámico | Registra el árbol de análisis de cada consulta. |
| `debug_print_plan` | Dinámico | Registra el plan de ejecución de cada consulta. |
| `debug_print_rewritten` | Dinámico | Registra el árbol de análisis reescrito de cada consulta. |
| `default_statistics_target` | Dinámico | Define el objetivo de estadística predeterminado. |
| `default_tablespace` | Dinámico | Define el espacio de tabla predeterminado en el que se deben crear las tablas y los índices. |
| `default_transaction_deferrable` | Dinámico | Define el estado diferible predeterminado de las nuevas transacciones. |
| `default_transaction_isolation` | Dinámico | Define el nivel de aislamiento de cada nueva transacción. |
| `default_transaction_read_only` | Dinámico | Define el estado de solo lectura predeterminado de las nuevas transacciones. |
| `default_with_oids` | Dinámico | Crea nuevas tablas con ID de objeto (OID) de forma predeterminada. |
| `effective_cache_size` | Dinámico | Define la suposición del planificador sobre el tamaño de la caché de disco. |
| `effective_io_concurrency` | Dinámico | Número de solicitudes simultáneas que el subsistema del disco puede gestionar de un modo eficiente. |
| `enable_bitmapscan` | Dinámico | Habilita el uso de planes de examen de mapas de bits por parte del planificador. |
| `enable_hashagg` | Dinámico | Habilita el uso de planes de agregación con hash por parte del planificador. |
| `enable_hashjoin` | Dinámico | Habilita el uso de planes de unión con hash por parte del planificador. |
| `enable_indexscan` | Dinámico | Habilita el uso de planes de examen de índice por parte del planificador. |
| `enable_material` | Dinámico | Habilita el uso de la materialización por parte del planificador. |
| `enable_mergejoin` | Dinámico | Habilita el uso de planes de unión de fusión por parte del planificador. |
| `enable_nestloop` | Dinámico | Habilita el uso de planes de unión de bucle anidado por parte del planificador. |
| `enable_seqscan` | Dinámico | Habilita el uso de planes de examen secuencial por parte del planificador. |
| `enable_sort` | Dinámico | Habilita el uso de pasos de ordenación explícitos por parte del planificador. |
| `enable_tidscan` | Dinámico | Habilita el uso de planes de examen de TID por parte del planificador. |
| `escape_string_warning` | Dinámico | Advierte sobre los caracteres de escape de barra diagonal invertida (\$1) en el texto de las cadenas ordinarias. |
| `extra_float_digits` | Dinámico | Define el número de dígitos que se muestran para los valores de punto flotante. |
| `from_collapse_limit` | Dinámico | Define el tamaño FROM-list por encima del cual las subconsultas no se contraen. |
| `fsync` | Dinámico | Fuerza la sincronización de las actualizaciones del disco. |
| `full_page_writes` | Dinámico | Escribe páginas completas en WAL la primera vez que se modifican después de un punto de comprobación. |
| `geqo` | Dinámico | Habilita la optimización genética de consultas. |
| `geqo_effort` | Dinámico | GEQO: effort se usa para definir el ajuste predeterminado de otros parámetros de GEQO. |
| `geqo_generations` | Dinámico | GEQO: número de iteraciones del algoritmo. |
| `geqo_pool_size` | Dinámico | GEQO: número de individuos de la población. |
| `geqo_seed` | Dinámico | GEQO: valor de inicialización para la selección de ruta aleatoria. |
| `geqo_selection_bias` | Dinámico | GEQO: presión selectiva dentro de la población. |
| `geqo_threshold` | Dinámico | Define el umbral de los elementos FROM por encima de los cuales se usa GEQO. |
| `gin_fuzzy_search_limit` | Dinámico | Define el resultado máximo permitido para la búsqueda exacta por GIN. |
| `hot_standby_feedback` | Dinámico | Determina si un servidor de espera en caliente envía mensajes de retroalimentación al servidor primario o de subida en espera. |
| `intervalstyle` | Dinámico | Define el formato de visualización para los valores de intervalo. |
| `join_collapse_limit` | Dinámico | Define el tamaño FROM-list por encima del cual las construcciones JOIN no se aplanan. |
| `lc_messages` | Dinámico | Define el idioma en el que se muestran los mensajes. |
| `lc_monetary` | Dinámico | Define la configuración regional para el formato de las cantidades monetarias. |
| `lc_numeric` | Dinámico | Define la configuración regional para el formato de los números. |
| `lc_time` | Dinámico | Define la configuración regional para el formato de los valores de fecha y hora. |
| `log_autovacuum_min_duration` | Dinámico | Define el tiempo de ejecución mínimo por encima del cual se registrarán las acciones de autovacuum. |
| `log_checkpoints` | Dinámico | Registra cada punto de comprobación. |
| `log_connections` | Dinámico | Registra cada conexión realizada correctamente. |
| `log_disconnections` | Dinámico | Registra el final de una sesión, incluida su duración. |
| `log_duration` | Dinámico | Registra la duración de cada declaración de SQL completada. |
| `log_error_verbosity` | Dinámico | Define el detalle de los mensajes registrados. |
| `log_executor_stats` | Dinámico | Escribe las estadísticas de rendimiento del ejecutor en el registro del servidor. |
| `log_filename` | Dinámico | Define el patrón del nombre de archivo para los archivos de registro. |
| `log_file_mode` | Dinámico | Establece los permisos de los archivos de registro. El valor predeterminado es 0644. |
| `log_hostname` | Dinámico | Registra el nombre del host en los registros de conexión. A partir de PostgreSQL 12 y versiones posteriores, este parámetro está desactivado de forma predeterminada. Cuando se activa, la conexión utiliza la búsqueda inversa de DNS para obtener el nombre de host que se captura en los registros de conexión. Si activa este parámetro, debe supervisar el impacto que tiene en el tiempo que se tarda en establecer las conexiones. |
| `log_line_prefix ` | Dinámico | Controla la información prefijada en cada línea de registro. |
| `log_lock_waits` | Dinámico | Registra las esperas de bloqueo largas. |
| `log_min_duration_statement` | Dinámico | Define el tiempo de ejecución mínimo por encima del cual se registrarán las instrucciones. |
| `log_min_error_statement` | Dinámico | Hace que todas las declaraciones que generen un error en este nivel o por encima de él se registren. |
| `log_min_messages` | Dinámico | Define los niveles de los mensajes que se registran. |
| `log_parser_stats` | Dinámico | Escribe las estadísticas de desempeño del analizador en el registro del servidor. |
| `log_planner_stats` | Dinámico | Escribe las estadísticas de desempeño del planificador en el registro del servidor. |
| `log_rotation_age` | Dinámico | Se producirá una rotación automática del archivo de registro después de N minutos. |
| `log_rotation_size` | Dinámico | Se producirá una rotación automática del archivo de registro después de N kilobytes. |
| `log_statement` | Dinámico | Define el tipo de declaraciones que se deben registrar. |
| `log_statement_stats` | Dinámico | Escribe las estadísticas de desempeño acumulativas en el registro del servidor. |
| `log_temp_files` | Dinámico | Registra el uso de archivos temporales con un tamaño superior a este número de kilobytes. |
| `log_timezone` | Dinámico | Establece la zona horaria que se usará en los mensajes de registro. |
| `log_truncate_on_rotation` | Dinámico | Permite truncar los archivos de registro existentes con el mismo nombre durante la rotación del registro. |
| `logging_collector` | Estático | Inicia un subproceso para capturar el resultado de stderr o csvlogs en archivos de registro. |
| `maintenance_work_mem` | Dinámico | Define la memoria máxima que se debe usar para las operaciones de mantenimiento. |
| `max_connections` | Estático | Define el número máximo de conexiones simultáneas. |
| `max_files_per_process` | Estático | Define el número máximo de archivos abiertos simultáneamente para cada proceso del servidor. |
| `max_locks_per_transaction` | Estático | Define el número máximo de bloqueos por transacción. |
| `max_pred_locks_per_transaction` | Estático | Define el número máximo de bloqueos de predicado por transacción. |
| `max_prepared_transactions` | Estático | Define el número máximo de transacciones preparadas simultáneamente. |
| `max_stack_depth` | Dinámico | Define la profundidad máxima de la pila en kilobytes. |
| `max_standby_archive_delay` | Dinámico | Define el retardo máximo antes de la cancelación de consultas cuando un servidor de espera en caliente está procesando los datos de WAL archivados. |
| `max_standby_streaming_delay` | Dinámico | Define el retardo máximo antes de la cancelación de consultas cuando un servidor de espera en caliente está procesando los datos de WAL transmitidos. |
| max\$1wal\$1size | Dinámico | Establece el tamaño de WAL (MB) que lanza un punto de comprobación. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Use el comando siguiente en la instancia de base de datos de Amazon RDS para PostgreSQL para ver su valor actual:
SHOW max_wal_size;
|
| min\$1wal\$1size | Dinámico | Establece el tamaño mínimo al que reducir el WAL. Para la versión 9.6 de PostgreSQL y anteriores, min\$1wal\$1size está en unidades de 16 MB. Para la versión 10 de PostgreSQL y posteriores, min\$1wal\$1size está en unidades de 1 MB. |
| `quote_all_identifiers` | Dinámico | Añade comillas (") a todos los identificadores cuando se generan fragmentos SQL. |
| `random_page_cost` | Dinámico | Define la estimación del planificador del coste de una página de disco que no se recupera secuencialmente. Este parámetro no tiene valor a menos que la administración del plan de consultas (QPM) esté activada. Cuando QPM está activado, el valor predeterminado para este parámetro es 4. |
| rds.adaptive\$1autovacuum | Dinámico | Ajusta automáticamente los parámetros autovacuum cuando se superan los umbrales del identificador de transacción. |
| rds.force\$1ssl | Dinámico | Requiere el uso de conexiones SSL. El valor predeterminado se establece en 1 (activado) para RDS para la versión 15 de PostgreSQL. Todas las demás versiones de RDS para PostgreSQL 14 principal y anteriores tienen el valor predeterminado establecido en 0 (desactivado). |
| `rds.local_volume_spill_enabled` | Estático | Permite escribir archivos de vertidos lógicos en el volumen local. |
| `rds.log_retention_period` | Dinámico | Establece la retención de registros de manera que Amazon RDS elimina los registros de PostgreSQL que sobrepasan n minutos. |
| rds.rds\$1superuser\$1reserved\$1connections | Estático | Establece el número de ranuras de conexión reservadas para rds\$1superusers. Este parámetro solo está disponible en la versión 15 y anteriores. Para obtener más información, consulte la documentación de PostgreSQL sobre [reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). |
| `rds.replica_identity_full` | Dinámico | Al establecer este parámetro en `on`, invalida la configuración de identidad de réplica a `FULL` para todas las tablas de la base de datos. Esto significa que todos los valores de las columnas se escriben en el registro de escritura anticipada (WAL), independientemente de la configuración de `REPLICA IDENTITY FULL`. La activación de este parámetro puede aumentar las IOPS de la instancia de base de datos debido al registro WAL adicional. |
| rds.restrict\$1password\$1commands | Estático | Restringe quién puede administrar contraseñas de los usuarios con el rol rds\$1password. Establezca este parámetro en 1 para habilitar la restricción de contraseñas. El valor predeterminado es 0. |
| `search_path` | Dinámico | Define el orden de búsqueda del esquema para los nombres que no cumplen los requisitos del esquema. |
| `seq_page_cost` | Dinámico | Define la estimación del planificador del costo de una página de disco que se recupera secuencialmente. |
| `session_replication_role` | Dinámico | Define el comportamiento de las sesiones para los desencadenadores y las reglas de reescritura. |
| `shared_buffers` | Estático | Define el número de búferes de memoria compartida utilizados por el servidor. |
| `shared_preload_libraries ` | Estático | Enumera las bibliotecas compartidas para precargar en la instancia de base de datos de RDS para PostgreSQL. Los valores admitidos son: auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler y plrust. |
| `ssl` | Dinámico | Habilita las conexiones SSL. |
| `sql_inheritance` | Dinámico | Hace que las subtablas se incluyan de manera predeterminada en varios comandos. |
| `ssl_renegotiation_limit` | Dinámico | Define la cantidad de tráfico que se debe enviar y recibir antes de renegociar las claves de cifrado. |
| `standard_conforming_strings` | Dinámico | Hace que las cadenas ... traten las barras diagonales invertidas literalmente. |
| `statement_timeout` | Dinámico | Establece la duración máxima permitida de cualquier declaración. |
| `synchronize_seqscans` | Dinámico | Habilita los exámenes secuenciales sincronizados. |
| `synchronous_commit` | Dinámico | Define el nivel de sincronización de las transacciones actuales. |
| `tcp_keepalives_count` | Dinámico | Número máximo de retransmisiones de keepalive de TCP. |
| `tcp_keepalives_idle` | Dinámico | Tiempo entre emisiones de keepalive de TCP. |
| `tcp_keepalives_interval` | Dinámico | Tiempo entre retransmisiones de keepalive de TCP. |
| `temp_buffers` | Dinámico | Define el número máximo de búferes temporales utilizados por cada sesión. |
| temp\$1file\$1limit | Dinámico | Establece el tamaño máximo en KB que pueden alcanzar los archivos temporales. |
| `temp_tablespaces` | Dinámico | Define los espacios de tabla que se deben usar para las tablas temporales y los archivos de ordenación. |
| `timezone` | Dinámico | Define la zona horaria para visualizar e interpretar las marcas temporales. Internet Assigned Numbers Authority (Autoridad de Números Asignados en Internet, IANA por sus siglas en inglés) publica nuevas zonas horarias en [https://www.iana.org/time-zones](https://www.iana.org/time-zones) varias veces al año. Cada vez que RDS publica una nueva versión secundaria de mantenimiento de PostgreSQL, incluye los datos de zona horaria más recientes en el momento de la publicación. Cuando utiliza las versiones más recientes de RDS para PostgreSQL, dispone de datos de zona horaria recientes de RDS. Para garantizar que la instancia de base de datos tenga datos de zona horaria recientes, se recomienda actualizar a una versión posterior del motor de base de datos. No puede modificar las tablas de zona horaria de las instancias de base de datos de PostgreSQL de forma manual. RDS no modifica ni restablece los datos de zona horaria de las instancias de base de datos en ejecución. Los nuevos datos de zona horaria solo se instalan cuando se actualiza la versión del motor de base de datos. |
| `track_activities` | Dinámico | Recopila información sobre la ejecución de comandos. |
| `track_activity_query_size` | Estático | Define el tamaño reservado para pg\$1stat\$1activity.current\$1query en bytes. |
| `track_counts` | Dinámico | Recopila estadísticas sobre la actividad de la base de datos. |
| `track_functions` | Dinámico | Recopila estadísticas de nivel de función sobre la actividad de la base de datos. |
| `track_io_timing` | Dinámico | Recopila estadísticas temporales sobre la actividad de E/S de la base de datos. |
| `transaction_deferrable` | Dinámico | Indica si se debe retrasar una transacción serializable de solo lectura hasta que se pueda comenzar sin posibles errores de serialización. |
| `transaction_isolation` | Dinámico | Define el nivel de aislamiento de las transacciones actuales. |
| `transaction_read_only` | Dinámico | Define el estado de solo lectura de las transacciones actuales. |
| `transform_null_equals` | Dinámico | Trata expr=NULL como expr IS NULL. |
| `update_process_title` | Dinámico | Actualiza el título del proceso para mostrar el comando SQL activo. |
| `vacuum_cost_delay` | Dinámico | Retardo del costo del vacío en milisegundos. |
| `vacuum_cost_limit` | Dinámico | Importe del costo del vacío disponible antes del periodo de reposo. |
| `vacuum_cost_page_dirty` | Dinámico | Costo del vacío para una página ensuciada por el vacío. |
| `vacuum_cost_page_hit` | Dinámico | Costo del vacío para una página encontrada en la caché del búfer. |
| `vacuum_cost_page_miss` | Dinámico | Costo del vacío para una página no encontrada en la caché del búfer. |
| `vacuum_defer_cleanup_age` | Dinámico | Número de transacciones para las que se deben retrasar el vacío y la limpieza en caliente, si los hay. |
| `vacuum_freeze_min_age` | Dinámico | Antigüedad mínima a la que el vacío debe inmovilizar una fila de una tabla. |
| `vacuum_freeze_table_age` | Dinámico | Antigüedad a la que el vacío debe examinar una tabla completa para inmovilizar tuplas. |
| `wal_buffers` | Estático | Define el número de búferes de página de disco de memoria compartida para WAL. |
| `wal_writer_delay` | Dinámico | Tiempo de reposo del escritor de WAL entre vaciados de WAL. |
| `work_mem` | Dinámico | Define la memoria máxima que se debe usar para los espacios de trabajo de consulta. |
| `xmlbinary` | Dinámico | Define cómo se deben codificar los valores binarios en XML. |
| `xmloption` | Dinámico | Define si los datos XML de las operaciones implícitas de análisis y serialización se deben considerar documentos o fragmentos de contenido. |
Amazon RDS usa las unidades predeterminadas de PostgreSQL para todos los parámetros. En la tabla siguiente se muestra la unidad predeterminada de PostgreSQL para cada parámetro.
| Nombre del parámetro | Unidad |
| --- | --- |
| `archive_timeout` | s |
| `authentication_timeout` | s |
| `autovacuum_naptime` | s |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | s |
| `checkpoint_warning` | s |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | minutos |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | s |
| `pre_auth_delay` | s |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | s |
| `tcp_keepalives_interval` | s |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | s |
# Ajuste con eventos de espera de RDS para PostgreSQL
Los eventos de espera son una importante herramienta de ajuste para RDS para PostgreSQL. Si puede averiguar por qué las sesiones esperan recursos y qué están haciendo, podrá reducir mejor los cuellos de botella. Puede utilizar la información de esta sección para encontrar las posibles causas y acciones correctivas. En esta sección también se describen los conceptos básicos de ajuste de PostgreSQL.
Los eventos de espera en esta sección son específicos de RDS para PostgreSQL.
**Topics**
+ [Conceptos esenciales para el ajuste de RDS para PostgreSQL](PostgreSQL.Tuning.concepts.md)
+ [Eventos de espera de RDS para PostgreSQL](PostgreSQL.Tuning.concepts.summary.md)
+ [Client:ClientRead](wait-event.clientread.md)
+ [Client:ClientWrite](wait-event.clientwrite.md)
+ [CPU](wait-event.cpu.md)
+ [IO:BufFileRead y IO:BufFileWrite](wait-event.iobuffile.md)
+ [IO:DataFileRead](wait-event.iodatafileread.md)
+ [IO:WALWrite](wait-event.iowalwrite.md)
+ [Eventos de espera de IPC:parallel](rpg-ipc-parallel.md)
+ [IPC:ProcArrayGroupUpdate](apg-rpg-ipcprocarraygroup.md)
+ [Lock:advisory](wait-event.lockadvisory.md)
+ [Lock:extend](wait-event.lockextend.md)
+ [Lock:Relation](wait-event.lockrelation.md)
+ [Lock:transactionid](wait-event.locktransactionid.md)
+ [Lock:tuple](wait-event.locktuple.md)
+ [LWLock:BufferMapping (LWLock:buffer\$1mapping)](wait-event.lwl-buffer-mapping.md)
+ [LWLock:BufferIO (IPC:BufferIO)](wait-event.lwlockbufferio.md)
+ [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md)
+ [LWLock:lock\$1manager (LWLock:lockmanager)](wait-event.lw-lock-manager.md)
+ [LWLock:pg\$1stat\$1statements](apg-rpg-lwlockpgstat.md)
+ [LWLock:SubtransSLRU (LWLock:SubtransControlLock)](wait-event.lwlocksubtransslru.md)
+ [Timeout:PgSleep](wait-event.timeoutpgsleep.md)
+ [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md)
# Conceptos esenciales para el ajuste de RDS para PostgreSQL
Antes de ajustar la base de datos de RDS para PostgreSQL, asegúrese de saber qué son los eventos de espera y por qué se producen. Revise también la arquitectura básica de memoria y disco de RDS para PostgreSQL. Para ver un diagrama de arquitectura útil, consulte el wikibook de [PostgreSQL](https://en.wikibooks.org/wiki/PostgreSQL/Architecture).
**Topics**
+ [Eventos de espera de RDS para PostgreSQL](PostgreSQL.Tuning.concepts.waits.md)
+ [Memoria de RDS para PostgreSQL](PostgreSQL.Tuning.concepts.memory.md)
+ [Procesos de RDS para PostgreSQL](PostgreSQL.Tuning.concepts.processes.md)
# Eventos de espera de RDS para PostgreSQL
Un *evento de espera* es una indicación de que la sesión espera un recurso. Por ejemplo, el evento de espera `Client:ClientRead` ocurre cuando RDS para PostgreSQL espera recibir datos del cliente. Por lo general, las sesiones esperan recursos como los siguientes.
+ Acceso de subproceso único a un búfer, por ejemplo, cuando una sesión intenta modificar un búfer
+ Una fila bloqueada actualmente por otra sesión
+ Lectura de un archivo de datos
+ Escritura de un archivo de registro
Por ejemplo, para satisfacer una consulta, la sesión podría hacer un escaneo de tabla completo. Si los datos ya no están en la memoria, la sesión espera a que se complete la E/S del disco. Cuando los búferes se leen en la memoria, es posible que la sesión tenga que esperar porque otras sesiones tienen acceso a los mismos búferes. La base de datos registra las esperas mediante un evento de espera predefinido. Estos eventos se agrupan en categorías.
Un evento de espera no significa por sí solo un problema de rendimiento. Por ejemplo, si los datos solicitados no están en memoria, es necesario leer los datos del disco. Si una sesión bloquea una fila para una actualización, otra sesión espera a que se desbloquee la fila para poder actualizarla. Una confirmación requiere un tiempo de espera para que se complete la escritura en un archivo de registro. Las esperas forman parte del funcionamiento normal de una base de datos.
Por otro lado, un gran número de eventos de espera suele ser indicativo de un problema de rendimiento. En estos casos, se pueden utilizar los datos de los eventos de espera para determinar en qué se gastan las sesiones. Por ejemplo, si un informe que normalmente se ejecuta en minutos ahora se ejecuta durante horas, puede identificar los eventos de espera que más contribuyen al tiempo total de espera. Si puede determinar las causas de los principales eventos de espera, a veces puede hacer cambios que mejoren el rendimiento. Por ejemplo, si la sesión se encuentra a la espera de una fila que ha sido bloqueada por otra sesión, puede terminar la sesión de bloqueo.
# Memoria de RDS para PostgreSQL
La memoria de RDS para PostgreSQL se divide en compartida y local.
**Topics**
+ [Memoria compartida en RDS para PostgreSQL](#PostgreSQL.Tuning.concepts.shared)
+ [Memoria local en RDS para PostgreSQL](#PostgreSQL.Tuning.concepts.local)
## Memoria compartida en RDS para PostgreSQL
RDS para PostgreSQL asigna memoria compartida cuando se inicia la instancia. La memoria compartida se divide en múltiples subáreas. En las siguientes secciones se proporcionan descripciones de las más importantes.
**Topics**
+ [Búferes compartidos](#PostgreSQL.Tuning.concepts.buffer-pool)
+ [Búferes de registro de escritura anticipada (WAL)](#PostgreSQL.Tuning.concepts.WAL)
### Búferes compartidos
El *grupo de búferes compartidos* es un área de memoria de RDS para PostgreSQL que contiene todas las páginas que utilizan o han utilizado las conexiones de la aplicación. Una *página* es la versión de memoria de un bloque de disco. El grupo de búferes compartidos almacena en caché los bloques de datos leídos desde el disco. El grupo reduce la necesidad de volver a leer los datos del disco, lo que hace que la base de datos funcione de forma más eficiente.
Cada tabla e índice se almacena como una matriz de páginas de tamaño fijo. Cada bloque contiene varias tuplas, que corresponden a filas. Una tupla se puede almacenar en cualquier página.
El grupo de búferes compartidos tiene memoria finita. Si una nueva solicitud requiere una página que no está en la memoria, y no hay más memoria, RDS para PostgreSQL desaloja una página que se utiliza con menos frecuencia para satisfacer la solicitud. La política de expulsión se implementa mediante un algoritmo de barrido de reloj.
El parámetro `shared_buffers` determina la cantidad de memoria que el servidor dedica al almacenamiento en caché de los datos. El valor predeterminado se establece en `{DBInstanceClassMemory/32768}` bytes, en función de la memoria disponible para la instancia de base de datos.
### Búferes de registro de escritura anticipada (WAL)
Un *búfer del registro de escritura anticipada (WAL)* contiene datos de transacciones que RDS para PostgreSQL escribe posteriormente en el almacenamiento persistente. Con el mecanismo WAL, RDS para PostgreSQL puede hacer lo siguiente:
+ Recuperar datos después de un error
+ Reducir la E/S del disco al evitar las escrituras frecuentes en el disco
Cuando un cliente cambia los datos, RDS para PostgreSQL escribe los cambios en el búfer de WAL. Cuando el cliente emite un `COMMIT`, el proceso de escritura WAL escribe los datos de la transacción en el archivo WAL.
El parámetro `wal_level` determina la cantidad de información que se escribe en el WAL, con posibles valores como `minimal`, `replica` y `logical`.
## Memoria local en RDS para PostgreSQL
Cada proceso de backend asigna memoria local para el procesamiento de consultas.
**Topics**
+ [Área de memoria de trabajo](#PostgreSQL.Tuning.concepts.local.work_mem)
+ [Área de memoria de trabajo de mantenimiento](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem)
+ [Área de búfer temporal](#PostgreSQL.Tuning.concepts.temp)
### Área de memoria de trabajo
El *área de memoria de trabajo* contiene datos temporales para las consultas que ejecutan ordenaciones y hashes. Por ejemplo, una consulta con una cláusula `ORDER BY` ejecuta una ordenación. Las consultas utilizan tablas hash en uniones hash y agregaciones.
El parámetro `work_mem` indica la cantidad de memoria que se utilizará en las operaciones internas de ordenación y en las tablas hash antes de escribir en los archivos temporales del disco, medido en megabytes. El valor predeterminado es 4 MB. Se pueden ejecutar varias sesiones simultáneamente, y cada sesión puede ejecutar operaciones de mantenimiento en paralelo. Por esta razón, la memoria de trabajo total utilizada puede ser múltiplo del parámetro `work_mem`.
### Área de memoria de trabajo de mantenimiento
El *área de memoria de trabajo de mantenimiento* almacena en caché los datos de las operaciones de mantenimiento. Estas operaciones incluyen el vaciado, creación de un índice y adición de claves externas.
El parámetro `maintenance_work_mem` especifica la cantidad máxima de memoria que utilizarán las operaciones de mantenimiento, medido en megabytes. El valor predeterminado es 64 MB. Una sesión de base de datos solo puede ejecutar una operación de mantenimiento a la vez.
### Área de búfer temporal
El *área de búfer temporal* almacena en caché las tablas temporales de cada sesión de la base de datos.
Cada sesión asigna búferes temporales según sea necesario hasta el límite que se especifique. Cuando finaliza la sesión, el servidor borra los búferes.
El parámetro `temp_buffers` establece el número máximo de búferes temporales utilizados por cada sesión, medido en megabytes. El valor predeterminado es 8 MB. Antes del primer uso de las tablas temporales dentro de una sesión, puede cambiar el valor de `temp_buffers`.
# Procesos de RDS para PostgreSQL
RDS para PostgreSQL utiliza varios procesos.
**Topics**
+ [Proceso de administrador de correos](#PostgreSQL.Tuning.concepts.postmaster)
+ [Procesos de backend](#PostgreSQL.Tuning.concepts.backend)
+ [Procesos en segundo plano](#PostgreSQL.Tuning.concepts.vacuum)
## Proceso de administrador de correos
El *proceso de administrador de correos* es el primer proceso que se ejecuta cuando se inicia RDS para PostgreSQL. El proceso de administrador de correos tiene las siguientes funciones principales:
+ Bifurcar y monitorear los procesos en segundo plano
+ Recibir solicitudes de autenticación de los procesos cliente, y autenticarlos antes de permitir que la base de datos atienda las solicitudes
## Procesos de backend
Si el administrador de correos autentica una solicitud de cliente, el administrador de correos bifurca un nuevo proceso de backend, también llamado proceso postgres. Un proceso cliente se conecta exactamente a un proceso backend. El proceso cliente y el proceso backend se comunican directamente sin la intervención del proceso de administrador de correos.
## Procesos en segundo plano
El proceso de administrador de correos bifurca varios procesos que ejecutan distintas tareas de backend. Algunas de las más importantes son las siguientes:
+ Escritor de WAL
RDS para PostgreSQL escribe datos en el búfer WAL (registro de escritura anticipada) en los archivos de registro. El principio del registro por adelantado es que la base de datos no puede escribir los cambios en los archivos de datos hasta que la base de datos escriba los registros que describen esos cambios en el disco. El mecanismo de WAL reduce la E/S del disco y permite a RDS para PostgreSQL utilizar los registros para recuperar la base de datos en caso de error.
+ Escritor en segundo plano
Este proceso escribe de forma periódica las páginas sucias (modificadas) desde los búferes de memoria a los archivos de datos. Una página se vuelve sucia cuando un proceso de backend la modifica en la memoria.
+ Daemon de autovacuum
El daemon consta de lo siguiente:
+ El iniciador de autovacuum
+ Los procesos de trabajo de autovacuum
Cuando autovacuum está activado busca las tablas en las que se ha insertado, actualizado o eliminado un número elevado de tuplas. El daemon tiene las siguientes responsabilidades:
+ Recuperar o reutilizar el espacio de disco ocupado por las filas actualizadas o eliminadas
+ Actualizar las estadísticas utilizadas por el planificador
+ Proteger contra la pérdida de datos antiguos debido al reinicio del ID de transacción
La característica de autovacuum automatiza la ejecución de los comandos `VACUUM` y `ANALYZE`. `VACUUM` tiene las siguientes variantes: estándar y completo. El vacío estándar se ejecuta en paralelo con otras operaciones de la base de datos. `VACUUM FULL` requiere un bloqueo exclusivo sobre la tabla en la que se trabaja. Por lo tanto, no puede ejecutarse en paralelo con operaciones que acceden a la misma tabla. `VACUUM` crea una cantidad considerable de tráfico de E/S, lo que puede causar un bajo rendimiento para otras sesiones activas.
# Eventos de espera de RDS para PostgreSQL
La siguiente tabla enumera los eventos de espera de RDS para PostgreSQL que suelen indicar problemas de rendimiento, y resume las causas más comunes y las acciones correctivas.
| Evento de espera | Definición |
| --- | --- |
| [Client:ClientRead](wait-event.clientread.md) | Este evento ocurre cuando RDS para PostgreSQL espera recibir datos del cliente. |
| [Client:ClientWrite](wait-event.clientwrite.md) | Este evento ocurre cuando RDS para PostgreSQL espera escribir datos en el cliente. |
| [CPU](wait-event.cpu.md) | Este evento ocurre cuando un subproceso está activo en la CPU o espera por la CPU. |
| [IO:BufFileRead y IO:BufFileWrite](wait-event.iobuffile.md) | Los eventos ocurren cuando RDS para PostgreSQL crean archivos temporales. |
| [IO:DataFileRead](wait-event.iodatafileread.md) | Este evento ocurre cuando una conexión espera en un proceso backend para leer una página requerida desde el almacenamiento porque la página no está disponible en la memoria compartida. |
| [IO:WALWrite](wait-event.iowalwrite.md) | Este evento ocurre cuando RDS para PostgreSQL está esperando a que se escriban los búferes del registro de escritura anticipada (WAL) en un archivo WAL. |
| [Lock:advisory](wait-event.lockadvisory.md) | Este evento ocurre cuando una aplicación PostgreSQL utiliza un bloqueo para coordinar la actividad en varias sesiones. |
| [Lock:extend](wait-event.lockextend.md) | Este evento ocurre cuando un proceso backend espera bloquear una relación para ampliarla mientras otro proceso tiene un bloqueo en esa relación para el mismo propósito. |
| [Lock:Relation](wait-event.lockrelation.md) | Este evento ocurre cuando una consulta espera adquirir un bloqueo en una tabla o vista que está actualmente bloqueada por otra transacción. |
| [Lock:transactionid](wait-event.locktransactionid.md) | Este evento ocurre cuando una transacción espera un bloqueo a nivel de fila. |
| [Lock:tuple](wait-event.locktuple.md) | Este evento ocurre cuando un proceso de backend espera adquirir un bloqueo en una tupla. |
| [LWLock:BufferMapping (LWLock:buffer\$1mapping)](wait-event.lwl-buffer-mapping.md) | Este evento se produce cuando una sesión espera asociar un bloque de datos con un búfer en el grupo de búferes compartidos. |
| [LWLock:BufferIO (IPC:BufferIO)](wait-event.lwlockbufferio.md) | El evento ocurre cuando RDS para PostgreSQL espera que otros procesos terminen sus operaciones de entrada/salida (E/S) cuando intentan acceder a una página de forma simultánea. |
| [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md) | Este evento ocurre cuando una sesión espera leer o escribir una página de datos en la memoria mientras otra sesión bloquea esa página para la escritura. |
| [LWLock:lock\$1manager (LWLock:lockmanager)](wait-event.lw-lock-manager.md) | Este evento ocurre cuando el motor de RDS para PostgreSQL mantiene el área de memoria del bloqueo compartido para asignar, verificar y desasignar un bloqueo cuando no es posible un bloqueo de ruta rápida. |
| [LWLock:SubtransSLRU (LWLock:SubtransControlLock)](wait-event.lwlocksubtransslru.md) | Este evento se produce cuando un proceso está esperando para acceder a la caché simple de uso menos reciente (SLRU) para una subtransacción. |
| [Timeout:PgSleep](wait-event.timeoutpgsleep.md) | Este evento ocurre cuando un proceso del servidor llamó a la función `pg_sleep` y espera que el tiempo de espera expire. |
| [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md) | Este evento indica que el proceso de vacío está en reposo porque se ha alcanzado el límite de costo estimado. |
# Client:ClientRead
El evento `Client:ClientRead` ocurre cuando RDS para PostgreSQL espera recibir datos del cliente.
**Topics**
+ [Versiones del motor admitidas](#wait-event.clientread.context.supported)
+ [Contexto](#wait-event.clientread.context)
+ [Causas probables del aumento de las esperas](#wait-event.clientread.causes)
+ [Acciones](#wait-event.clientread.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con RDS para PostgreSQL versión 10 y posteriores.
## Contexto
Una instancia de base de datos de RDS para PostgreSQL espera recibir datos del cliente. La instancia de la base de datos de RDS para PostgreSQL tiene que recibir los datos del cliente antes de poder enviar más datos al cliente. El tiempo que la instancia espera antes de recibir los datos del cliente es un evento `Client:ClientRead`.
## Causas probables del aumento de las esperas
Las causas más comunes para que el evento `Client:ClientRead` aparezca en el máximo de esperas son las siguientes:
**Aumento de la latencia de la red**
Puede haber un aumento de la latencia de la red entre la instancia de la base de datos de RDS para PostgreSQL y el cliente. Una mayor latencia de la red aumenta el tiempo necesario para que la instancia de base de datos reciba los datos del cliente.
**Aumento de la carga en el cliente**
Puede haber presión de la CPU o saturación de la red en el cliente. Un aumento de la carga en el cliente puede retrasar la transmisión de datos desde el cliente a la instancia de la base de datos de RDS para PostgreSQL.
**Excesivos viajes de ida y vuelta de la red**
Un gran número de viajes de ida y vuelta de la red entre la instancia de la base de datos de RDS para PostgreSQL y el cliente puede retrasar la transmisión de datos del cliente a la instancia de la base de datos de RDS para PostgreSQL.
**Operación de copia grande**
Durante una operación de copia, los datos se transfieren desde el sistema de archivos del cliente a la instancia de la base de datos de RDS para PostgreSQL. El envío de una gran cantidad de datos a la instancia de la base de datos puede retrasar la transmisión de datos del cliente a la instancia de la base de datos.
**Conexión de cliente inactivo**
Cuando un cliente se conecta a la instancia de la base de datos de RDS para PostgreSQL en un estado `idle in transaction`, la instancia de la base de datos puede esperar a que el cliente envíe más datos o emita un comando. Una conexión en este estado puede conducir a un aumento de eventos `Client:ClientRead`.
**PgBouncer se utiliza para la agrupación de conexiones**
PgBouncer tiene un ajuste de configuración de red de bajo nivel llamado `pkt_buf`, que se establece en 4.096 de forma predeterminada. Si la carga de trabajo envía paquetes de consulta de más de 4096 bytes a través de PgBouncer, recomendamos aumentar la configuración de `pkt_buf` a 8192. Si la nueva configuración no disminuye el número de eventos `Client:ClientRead`, recomendamos aumentar la configuración de `pkt_buf` a valores mayores, como 16 384 o 32 768. Si el texto de la consulta es grande, el ajuste más grande puede ser particularmente útil.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Colocar los clientes en la misma zona de disponibilidad y subred VPC que el evento de espera](#wait-event.clientread.actions.az-vpc-subnet)
+ [Escalar el cliente](#wait-event.clientread.actions.scale-client)
+ [Utilizar las instancias de generación actual](#wait-event.clientread.actions.db-instance-class)
+ [Aumentar el ancho de banda de la red](#wait-event.clientread.actions.increase-network-bandwidth)
+ [Monitorear los máximos de rendimiento de la red](#wait-event.clientread.actions.monitor-network-performance)
+ [Monitorear las transacciones en el estado “inactivo en la transacción”](#wait-event.clientread.actions.check-idle-in-transaction)
### Colocar los clientes en la misma zona de disponibilidad y subred VPC que el evento de espera
Para reducir la latencia de la red y aumentar su rendimiento, coloque los clientes en la misma zona de disponibilidad y subred de nube privada virtual (VPC) que la instancia de la base de datos de RDS para PostgreSQL. Asegúrese de que los clientes estén lo más cerca posible desde el punto de vista geográfico de la instancia de la base de datos.
### Escalar el cliente
Con Amazon CloudWatch u otras métricas del anfitrión, determine si su cliente está actualmente limitado por la CPU o el ancho de banda de la red, o ambos. Si el cliente está restringido, escale su cliente en forma adecuada.
### Utilizar las instancias de generación actual
En algunos casos, es posible que no utilice una clase de instancia de base de datos que admita tramas gigantes. Si ejecuta la aplicación en Amazon EC2, considere la posibilidad de utilizar una instancia de generación actual para el cliente. Además, configure la unidad de transmisión máxima (MTU) en el sistema operativo del cliente. Esta técnica podría reducir el número de viajes de ida y vuelta de la red y aumentar el rendimiento de la red. Para obtener más información, consulte [Tramas gigantes (MTU 9001)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) en la *Guía del usuario de Amazon EC2*.
Para obtener información acerca de las clases de instancia de base de datos, consulte [Clases de instancia de base de datos de ](Concepts.DBInstanceClass.md). Para determinar la clase de instancia de base de datos que equivale a un tipo de instancia de Amazon EC2, coloque `db.` antes del nombre del tipo de instancia de Amazon EC2. Por ejemplo, la instancia de Amazon EC2 `r5.8xlarge` equivale a la clase de instancia de base de datos `db.r5.8xlarge`.
### Aumentar el ancho de banda de la red
Utilice las métricas de Amazon CloudWatch de `NetworkReceiveThroughput` y `NetworkTransmitThroughput` para monitorear el tráfico de red entrante y saliente en la instancia de la base de datos. Estas métricas pueden ayudarle a determinar si el ancho de banda de la red es suficiente para su carga de trabajo.
Si el ancho de banda de su red no es suficiente, auméntelo. Si el cliente de AWS o la instancia de base de datos alcanza los límites del ancho de banda de la red, la única forma de aumentar el ancho de banda es aumentar el tamaño de la instancia de base de datos. Para obtener más información, consulte [Tipos de clase de instancia de base de datos](Concepts.DBInstanceClass.Types.md).
Para obtener más información acerca de las métricas de CloudWatch, consulte [Métricas de Amazon CloudWatch para Amazon RDS](rds-metrics.md).
### Monitorear los máximos de rendimiento de la red
Si utiliza clientes de Amazon EC2, Amazon EC2 proporciona límites máximos para las métricas de rendimiento de la red, incluido el ancho de banda de red entrante y saliente agregado. También proporciona un seguimiento de la conexión para garantizar que los paquetes se devuelven como se espera y el acceso a los servicios de enlace local para servicios como el sistema de nombres de dominio (DNS). Para monitorear estos máximos, utilice un controlador de red mejorado actual y monitoree el rendimiento de la red para su cliente.
Para obtener más información, consulte [Monitorear el rendimiento de la red de la instancia de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) en la *Guía del usuario de Amazon EC2* y [Monitorear el rendimiento de la red de la instancia de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitoring-network-performance-ena.html) en la *Guía del usuario de Amazon EC2*.
### Monitorear las transacciones en el estado “inactivo en la transacción”
Verifique si tiene un número creciente de conexiones `idle in transaction`. Para ello, monitoree la columna `state` en la tabla `pg_stat_activity`. Es posible que pueda identificar el origen de la conexión si ejecuta una consulta similar a la siguiente.
```
select client_addr, state, count(1) from pg_stat_activity
where state like 'idle in transaction%'
group by 1,2
order by 3 desc
```
# Client:ClientWrite
El evento `Client:ClientWrite` ocurre cuando RDS para PostgreSQL espera escribir datos en el cliente.
**Topics**
+ [Versiones del motor admitidas](#wait-event.clientwrite.context.supported)
+ [Contexto](#wait-event.clientwrite.context)
+ [Causas probables del aumento de las esperas](#wait-event.clientwrite.causes)
+ [Acciones](#wait-event.clientwrite.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con RDS para PostgreSQL versión 10 y posteriores.
## Contexto
Un proceso cliente debe leer todos los datos recibidos de un clúster de la base de datos de RDS para PostgreSQL antes de que el clúster pueda enviar más datos. El tiempo que el clúster espera antes de enviar más datos al cliente es un evento `Client:ClientWrite`.
La reducción del rendimiento de la red entre la instancia de base de datos de RDS para PostgreSQL y el cliente puede causar este evento. La presión de la CPU y la saturación de la red en el cliente también pueden causar este evento. La *presión de la CPU* es cuando la CPU se utiliza por completo y hay tareas esperando por el tiempo de la CPU. La *saturación de la red* es cuando la red entre la base de datos y el cliente transporta más datos de los que puede manejar.
## Causas probables del aumento de las esperas
Las causas más comunes para que el evento `Client:ClientWrite` aparezca en el máximo de esperas son las siguientes:
**Aumento de la latencia de la red**
Puede haber un aumento de la latencia de la red entre la instancia de la base de datos de RDS para PostgreSQL y el cliente. Una mayor latencia de la red aumenta el tiempo necesario para que el cliente reciba los datos.
**Aumento de la carga en el cliente**
Puede haber presión de la CPU o saturación de la red en el cliente. Un aumento de la carga en el cliente retrasa la recepción de los datos de la instancia de la base de datos de RDS para PostgreSQL.
**Gran volumen de datos enviados al cliente**
La instancia de la base de datos de RDS para PostgreSQL puede estar enviando una gran cantidad de datos al cliente. Es posible que el cliente no pueda recibir los datos tan rápido como el clúster los envía. Actividades como una copia de una tabla grande pueden resultar en un aumento de eventos `Client:ClientWrite`.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Coloque los clientes en la misma zona de disponibilidad y subred VPC que el clúster](#wait-event.clientwrite.actions.az-vpc-subnet)
+ [Utilizar las instancias de generación actual](#wait-event.clientwrite.actions.db-instance-class)
+ [Reducir la cantidad de datos enviados al cliente](#wait-event.clientwrite.actions.reduce-data)
+ [Escale el cliente](#wait-event.clientwrite.actions.scale-client)
### Coloque los clientes en la misma zona de disponibilidad y subred VPC que el clúster
Para reducir la latencia de la red y aumentar su rendimiento, coloque los clientes en la misma zona de disponibilidad y subred de nube privada virtual (VPC) que la instancia de la base de datos de RDS para PostgreSQL.
### Utilizar las instancias de generación actual
En algunos casos, es posible que no utilice una clase de instancia de base de datos que admita tramas gigantes. Si ejecuta la aplicación en Amazon EC2, considere la posibilidad de utilizar una instancia de generación actual para el cliente. Además, configure la unidad de transmisión máxima (MTU) en el sistema operativo del cliente. Esta técnica podría reducir el número de viajes de ida y vuelta de la red y aumentar el rendimiento de la red. Para obtener más información, consulte [Tramas gigantes (MTU 9001)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances) en la *Guía del usuario de Amazon EC2*.
Para obtener información acerca de las clases de instancia de base de datos, consulte [Clases de instancia de base de datos de ](Concepts.DBInstanceClass.md). Para determinar la clase de instancia de base de datos que equivale a un tipo de instancia de Amazon EC2, coloque `db.` antes del nombre del tipo de instancia de Amazon EC2. Por ejemplo, la instancia de Amazon EC2 `r5.8xlarge` equivale a la clase de instancia de base de datos `db.r5.8xlarge`.
### Reducir la cantidad de datos enviados al cliente
Cuando sea posible, ajuste la aplicación para reducir la cantidad de datos que la instancia de la base de datos de RDS para PostgreSQL envía al cliente. Hacer estos ajustes reduce la contención de la CPU y de la red en el cliente.
### Escale el cliente
Con Amazon CloudWatch u otras métricas del anfitrión, determine si su cliente está actualmente limitado por la CPU o el ancho de banda de la red, o ambos. Si el cliente está restringido, escale su cliente en forma adecuada.
# CPU
Este evento ocurre cuando un subproceso está activo en la CPU o espera por la CPU.
**Topics**
+ [Versiones del motor admitidas](#wait-event.cpu.context.supported)
+ [Contexto](#wait-event.cpu.context)
+ [Causas probables del aumento de las esperas](#wait-event.cpu.causes)
+ [Acciones](#wait-event.cpu.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es relevante para todas las versiones de RDS para PostgreSQL.
## Contexto
La *unidad de procesamiento central (CPU)* es el componente de un ordenador que ejecuta instrucciones. Por ejemplo, las instrucciones de la CPU hacen operaciones aritméticas e intercambian datos en la memoria. Si una consulta aumenta el número de instrucciones que ejecuta a través del motor de base de datos, aumenta el tiempo de ejecución de la consulta. La *programación de la CPU* consiste en dar tiempo de CPU a un proceso. La programación es orquestada por el núcleo del sistema operativo.
**Topics**
+ [Cómo saber cuándo se produce esta espera](#wait-event.cpu.when-it-occurs)
+ [Métrica de DBloadCPU](#wait-event.cpu.context.dbloadcpu)
+ [Métrica os.cpuUtilization](#wait-event.cpu.context.osmetrics)
+ [Causa probable de la programación de la CPU](#wait-event.cpu.context.scheduling)
### Cómo saber cuándo se produce esta espera
Este evento de espera de `CPU` indica que un proceso del backend se encuentra activo en la CPU o en espera de la misma. Se sabrá que sucede cuando una consulta muestre la siguiente información:
+ La columna `pg_stat_activity.state` tiene el valor `active`.
+ Las columnas `wait_event_type` y `wait_event` en `pg_stat_activity` son `null`.
Para ver los procesos del backend que se encuentran en uso o en espera de CPU, ejecute la siguiente consulta.
```
SELECT *
FROM pg_stat_activity
WHERE state = 'active'
AND wait_event_type IS NULL
AND wait_event IS NULL;
```
### Métrica de DBloadCPU
La métrica de Información sobre rendimiento para la CPU es `DBLoadCPU`. El valor de `DBLoadCPU` puede diferir del valor de la métrica `CPUUtilization` de Amazon CloudWatch. Esta última métrica se recopila del hipervisor para una instancia de base de datos.
### Métrica os.cpuUtilization
Las métricas del sistema operativo de Información sobre rendimiento proporcionan información detallada sobre la utilización de la CPU. Por ejemplo, puede mostrar las siguientes métricas:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Información sobre rendimiento informa del uso de la CPU por parte del motor de base de datos como `os.cpuUtilization.nice.avg`.
### Causa probable de la programación de la CPU
El núcleo del sistema operativo (SO) ejecuta la programación de la CPU. Cuando la CPU está *activa*, es posible que un proceso tenga que esperar para programarse. La CPU está activa mientras realiza los cálculos. También está activa mientras ejecuta un subproceso inactivo, es decir, un subproceso inactivo que espera la E/S de la memoria. Este tipo de E/S domina la carga de trabajo típica de una base de datos.
Es probable que los procesos esperen a que se programe una CPU cuando se cumplen las siguientes condiciones:
+ La métrica CloudWatch `CPUUtilization` está cerca del 100 por ciento.
+ La carga media es mayor que el número de vCPU, lo que indica una carga pesada. Puede encontrar la métrica `loadAverageMinute` en la sección de métricas del sistema operativo en Información sobre rendimiento.
## Causas probables del aumento de las esperas
Cuando el evento de espera de la CPU ocurre más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas pueden ser las siguientes.
**Topics**
+ [Causas probables de picos repentinos](#wait-event.cpu.causes.spikes)
+ [Causas probables de alta frecuencia prolongada](#wait-event.cpu.causes.long-term)
+ [Casos aislados](#wait-event.cpu.causes.corner-cases)
### Causas probables de picos repentinos
Las causas más probables de picos repentinos son las siguientes:
+ La aplicación abrió demasiadas conexiones simultáneas a la base de datos. Este escenario se conoce como “tormenta de conexiones”
+ La carga de trabajo de la aplicación ha cambiado de alguna de las siguientes maneras:
+ Nuevas consultas
+ Un aumento del tamaño del conjunto de datos
+ Mantenimiento o creación de índices
+ Nuevas funciones
+ Nuevos operadores
+ Aumento de la ejecución de consultas en paralelo
+ Los planes de ejecución de sus consultas han cambiado. En algunos casos, un cambio puede provocar un aumento de los búferes. Por ejemplo, la consulta utiliza ahora un escaneo secuencial cuando antes utilizaba un índice. En este caso, las consultas necesitan más CPU para lograr el mismo objetivo.
### Causas probables de alta frecuencia prolongada
Las causas más probables de eventos que se repiten durante un periodo prolongado:
+ Demasiados procesos de backend se ejecutan de forma simultánea en la CPU. Estos procesos pueden llegar a ser procesos de trabajo paralelos.
+ Las consultas tienen un rendimiento subóptimo porque necesitan un gran número de búferes.
### Casos aislados
Si ninguna de las causas probables resulta ser la causa real, es posible que se produzcan las siguientes situaciones:
+ La CPU está intercambiando procesos de entrada y salida.
+ La CPU podría gestionar las entradas de la tabla de páginas si se ha desactivado la función de *páginas enormes*. Esta característica de administración de la memoria está habilitada de forma predeterminada para todas las clases de instancias de base de datos que no sean de la clase de instancia de base de datos micro, pequeña y mediana. Para obtener más información, consulte [Páginas enormes para RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md).
## Acciones
Si el evento de espera de `CPU` domina la actividad de la base de datos, no indica necesariamente un problema de rendimiento. Responda a este evento solo cuando el rendimiento se deteriore.
**Topics**
+ [Investigue si la base de datos es la causa del aumento de la CPU](#wait-event.cpu.actions.db-CPU)
+ [Determine si el número de conexiones aumentó](#wait-event.cpu.actions.connections)
+ [Responder a los cambios en la carga de trabajo](#wait-event.cpu.actions.workload)
### Investigue si la base de datos es la causa del aumento de la CPU
Examine la métrica `os.cpuUtilization.nice.avg` en Información sobre rendimiento. Si este valor es mucho menor que el uso de la CPU, los procesos ajenos a la base de datos son los que más contribuyen a la CPU.
### Determine si el número de conexiones aumentó
Examine la métrica `DatabaseConnections` en Amazon CloudWatch. La acción a tomar depende de si el número aumentó o disminuyó durante el periodo de aumento de los eventos de espera de la CPU.
#### Las conexiones aumentaron
Si el número de conexiones aumentó, compare el número de procesos de backend que consumen CPU con el número de vCPU. Los siguientes escenarios son posibles:
+ El número de procesos de backend que consumen CPU es menor que el número de vCPU.
En este caso, el número de conexiones no es un problema. Sin embargo, puede intentar reducir la utilización de la CPU.
+ El número de procesos de backend que consumen CPU es mayor que el número de vCPU.
En este caso, considere las siguientes opciones:
+ Disminuya el número de procesos backend conectados a la base de datos. Por ejemplo, implemente una solución de agrupación de conexiones, como el proxy RDS. Para obtener más información, consulte [Amazon RDS Proxy ](rds-proxy.md).
+ Actualice el tamaño de su instancia para obtener un mayor número de vCPU.
+ Redirija algunas cargas de trabajo de solo lectura a nodos lectores, si procede.
#### Las conexiones no aumentaron
Examine las métricas de `blks_hit` en Información sobre rendimiento. Busque una correlación entre el aumento de `blks_hit` y el uso de la CPU. Los siguientes escenarios son posibles:
+ El uso de la CPU y `blks_hit` están correlacionados.
En este caso, encuentre las principales instrucciones SQL que están relacionadas con el uso de la CPU y busque los cambios de plan. Puede utilizar cualquiera de las siguientes técnicas:
+ Explicar los planes manualmente y compararlos con el plan de ejecución esperado.
+ Buscar un aumento en los aciertos de bloque por segundo y en los aciertos de bloque local por segundo. En la sección **Top SQL** (SQL principal) del panel de Información sobre rendimiento, elija **Preferences** (Preferencias).
+ El uso de la CPU y `blks_hit` no están correlacionados.
En este caso, determine si se produce alguna de las siguientes situaciones:
+ La aplicación se conecta y desconecta con rapidez de la base de datos.
Diagnostique este comportamiento mediante la activación de `log_connections` y `log_disconnections`, y luego analice los registros de PostgreSQL. Considere utilizar el analizador de registros `pgbadger`. Para obtener más información, consulte [https://github.com/darold/pgbadger](https://github.com/darold/pgbadger).
+ El sistema operativo está sobrecargado.
En este caso, Información sobre rendimiento muestra que los procesos del backend consumen la CPU durante más tiempo del habitual. Busque pruebas en las métricas de Información sobre rendimiento `os.cpuUtilization` o en la métrica CloudWatch `CPUUtilization`. Si el sistema operativo está sobrecargado, consulte las métricas de Monitoreo mejorado para hacer un diagnóstico más profundo. Específicamente, observe la lista de procesos y el porcentaje de CPU que consume cada proceso.
+ Las instrucciones SQL más importantes son las que consumen demasiada CPU.
Examine las instrucciones que se relacionan con el uso de la CPU para ver si pueden utilizar menos CPU. Ejecute un comando `EXPLAIN`, y céntrese en los nodos del plan que tienen el mayor impacto. Considere utilizar un visualizador de planes de ejecución de PostgreSQL. Para probar esta herramienta, consulte [http://explain.dalibo.com/](http://explain.dalibo.com/).
### Responder a los cambios en la carga de trabajo
Si la carga de trabajo cambió, busque los siguientes tipos de cambios:
Nuevas consultas
Verifique si las nuevas consultas son las esperadas. Si es así, asegúrese de que los planes de ejecución y el número de ejecuciones por segundo son los esperados.
Aumento del tamaño del conjunto de datos
Determine si la partición, si no se ha implementado todavía, podría ayudar. Esta estrategia podrá reducir el número de páginas que debe recuperar una consulta.
Mantenimiento o creación de índices
Verifique si el programa de mantenimiento es el previsto. Una práctica recomendada es programar las actividades de mantenimiento fuera de los picos de actividad.
Nuevas funciones
Verifique si estas funciones se comportan como se espera durante las pruebas. En concreto, verifique si el número de ejecuciones por segundo es el esperado.
Nuevos operadores
Verifique si su rendimiento es el esperado durante las pruebas.
Aumento de la ejecución de consultas paralelas
Determine si se ha producido alguna de las siguientes situaciones:
+ Las relaciones o los índices implicados han crecido repentinamente en tamaño de modo que difieren significativamente de `min_parallel_table_scan_size` o `min_parallel_index_scan_size`.
+ Se hicieron cambios recientes en `parallel_setup_cost` o `parallel_tuple_cost`.
+ Se hicieron cambios recientes en `max_parallel_workers` o `max_parallel_workers_per_gather`.
# IO:BufFileRead y IO:BufFileWrite
Los eventos `IO:BufFileRead` e `IO:BufFileWrite` ocurren cuando RDS para PostgreSQL crea archivos temporales. Cuando las operaciones requieren más memoria de la que los parámetros de la memoria de trabajo definen actualmente, escriben datos temporales en el almacenamiento persistente. Esta operación se llama a veces *derramamiento en el disco*. Para obtener más información sobre los archivos temporales y su uso, consulte [Administración de archivos temporales con PostgreSQL](PostgreSQL.ManagingTempFiles.md).
**Topics**
+ [Versiones del motor admitidas](#wait-event.iobuffile.context.supported)
+ [Contexto](#wait-event.iobuffile.context)
+ [Causas probables del aumento de las esperas](#wait-event.iobuffile.causes)
+ [Acciones](#wait-event.iobuffile.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Contexto
`IO:BufFileRead` e `IO:BufFileWrite` se relacionan con el área de memoria de trabajo y el área de memoria de trabajo de mantenimiento. Para obtener más información acerca de estas áreas de memoria locales, consulte el punto [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) (Consumo de recursos) en la documentación de PostgreSQL.
El valor predeterminado de `work_mem` es de 4 MB. Si una sesión ejecuta operaciones en paralelo, cada proceso de trabajo que maneja el paralelismo utiliza 4 MB de memoria. Por esta razón, configure `work_mem` con cuidado. Si el valor es demasiado alto, una base de datos con muchas sesiones puede consumir demasiada memoria. Si establece el valor demasiado bajo, RDS para PostgreSQL crea archivos temporales en el almacenamiento local. La E/S del disco para estos archivos temporales puede reducir el rendimiento.
Si se observa la siguiente secuencia de eventos, es posible que la base de datos genere archivos temporales:
1. Disminución repentina y brusca de la disponibilidad
1. Recuperación rápida del espacio libre
También puede observar un patrón de “motosierra”. Este patrón puede indicar que la base de datos crea archivos pequeños de forma constante.
## Causas probables del aumento de las esperas
En general, estos eventos de espera son causados por operaciones que consumen más memoria de la que asignan los parámetros `work_mem` o `maintenance_work_mem`. Para compensar, las operaciones se escriben en archivos temporales. Las causas más comunes de los eventos `IO:BufFileRead` y `IO:BufFileWrite` son las siguientes:
**Consultas que necesitan más memoria de la que existe en la zona de memoria de trabajo**
Las consultas con las siguientes características utilizan el área de memoria de trabajo:
+ Combinaciones hash
+ `ORDER BY`Cláusula
+ `GROUP BY`Cláusula
+ `DISTINCT`
+ Funciones de ventana
+ `CREATE TABLE AS SELECT`
+ Actualización de la vista materializada
**Instrucciones que necesitan más memoria de la que existe en el área de memoria de trabajo de mantenimiento**
Las siguientes instrucciones utilizan el área de memoria de trabajo de mantenimiento:
+ `CREATE INDEX`
+ `CLUSTER`
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Identifique el problema](#wait-event.iobuffile.actions.problem)
+ [Examine sus consultas de unión (join)](#wait-event.iobuffile.actions.joins)
+ [Examinar las consultas ORDER BY y GROUP BY](#wait-event.iobuffile.actions.order-by)
+ [Evite utilizar la operación DISTINCT](#wait-event.iobuffile.actions.distinct)
+ [Considere la posibilidad de utilizar funciones de ventana en lugar de funciones GROUP BY](#wait-event.iobuffile.actions.window)
+ [Investigar las vistas materializadas y las instrucciones CTA](#wait-event.iobuffile.actions.mv-refresh)
+ [Utilizar pg\$1repack al reconstruir índices](#wait-event.iobuffile.actions.pg_repack)
+ [Aumentar maintenance\$1work\$1mem al hacer un clúster de tablas](#wait-event.iobuffile.actions.cluster)
+ [Ajustar la memoria para evitar IO:BufFileRead e IO:BufFileWrite](#wait-event.iobuffile.actions.tuning-memory)
### Identifique el problema
Puede ver el uso de archivos temporales directamente en información de rendimiento. Para obtener más información, consulte [Visualización del uso de archivos temporales con Información de rendimiento](PostgreSQL.ManagingTempFiles.Example.md). Cuando la información de rendimiento está desactivada, es posible que observe un aumento de las operaciones `IO:BufFileRead` e `IO:BufFileWrite`.
Para identificar el origen del problema, puede configurar el parámetro `log_temp_files` para registrar todas las consultas que generen más KB de archivos temporales que el umbral especificado. De forma predeterminada, `log_temp_files` se establece en `-1`, lo que desactiva esta función de registro. Si establece este parámetro como `0`, RDS para PostgreSQL registra todos los archivos temporales. Si lo establece en `1024`, RDS para PostgreSQL registra todas las consultas que produzcan archivos temporales de más de 1 MB. Para más información sobre `log_temp_files`, consulte [Error Reporting and Logging](https://www.postgresql.org/docs/current/runtime-config-logging.html) en la documentación de PostgreSQL.
### Examine sus consultas de unión (join)
Es probable que la consulta utilice combinaciones. Por ejemplo, la siguiente consulta une cuatro tablas.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = order.customer_id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
Una posible causa de los picos de uso de archivos temporales es un problema en la propia consulta. Por ejemplo, una cláusula rota podría no filtrar las uniones correctamente. Considere la segunda unión interna en el siguiente ejemplo.
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = customer.id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
La consulta anterior une por error `customer.id` con `customer.id`, lo que genera un producto cartesiano entre cada cliente y cada pedido. Este tipo de unión accidental genera grandes archivos temporales. Según el tamaño de las tablas, una consulta cartesiana puede incluso llenar el almacenamiento. Es posible que la aplicación tenga uniones cartesianas cuando se den las siguientes condiciones:
+ Se observan grandes y bruscas disminuciones en la disponibilidad del almacenamiento, seguidas de una rápida recuperación.
+ No se crean índices.
+ No se emiten instrucciones `CREATE TABLE FROM SELECT`.
+ No se actualizan las vistas materializadas.
Para ver si las tablas se unen con las claves adecuadas, inspeccione las directivas de consulta y de asignación objeto-relacional. Tenga en cuenta que algunas consultas de la aplicación no se llaman todo el tiempo, y algunas consultas se generan de forma dinámica.
### Examinar las consultas ORDER BY y GROUP BY
En algunos casos, una cláusula `ORDER BY` puede dar lugar a un exceso de archivos temporales. Tenga en cuenta estas directrices:
+ Incluya las columnas en una cláusula `ORDER BY` solo cuando sea necesario ordenarlas. Esta directriz es especialmente importante para las consultas que devuelven miles de filas y especifican muchas columnas en la cláusula `ORDER BY`.
+ Considere la posibilidad de crear índices para acelerar las cláusulas `ORDER BY` cuando coincidan con columnas que tengan el mismo orden ascendente o descendente. Los índices parciales son preferibles porque son más pequeños. Los índices más pequeños se leen y recorren más rápidamente.
+ Si crea índices para columnas que pueden aceptar valores nulos, considere si quiere que los valores nulos se almacenen al final o al principio de los índices.
Si es posible, reduzca el número de filas que hay que ordenar, mediante el filtrado del conjunto de resultados. Si utiliza instrucciones de la cláusula `WITH` o subconsultas, recuerde que una consulta interna genera un conjunto de resultados y lo pasa a la consulta externa. Cuantas más filas pueda filtrar una consulta, menos tendrá que ordenar esta última.
+ Si no necesita obtener el conjunto de resultados completo, utilice la cláusula `LIMIT`. Por ejemplo, si solo quiere las cinco primeras filas, una consulta que utilice la cláusula `LIMIT` no sigue generando resultados. De este modo, la consulta requiere menos memoria y archivos temporales.
Una consulta que utiliza una cláusula `GROUP BY` también puede requerir archivos temporales. Las consultas `GROUP BY` resumen los valores con funciones como las siguientes:
+ `COUNT`
+ `AVG`
+ `MIN`
+ `MAX`
+ `SUM`
+ `STDDEV`
Para ajustar las consultas `GROUP BY`, siga las recomendaciones para las consultas `ORDER BY`.
### Evite utilizar la operación DISTINCT
Si es posible, evite utilizar la operación `DISTINCT` para eliminar las filas duplicadas. Cuantas más filas innecesarias y duplicadas devuelva la consulta, más cara será la operación `DISTINCT`. Si es posible, agregue filtros en la cláusula `WHERE`, incluso si utiliza los mismos filtros para diferentes tablas. Filtrar la consulta y unirla correctamente mejora su rendimiento y reduce el uso de recursos. Además, evita que los informes y resultados sean incorrectos.
Si necesita utilizar `DISTINCT` para varias filas de una misma tabla, considere la posibilidad de crear un índice compuesto. Agrupar varias columnas en un índice puede mejorar el tiempo de evaluación de las filas distintas. Además, si utiliza RDS para PostgreSQL versión 10 o posterior, puede correlacionar estadísticas entre varias columnas con el comando `CREATE STATISTICS`.
### Considere la posibilidad de utilizar funciones de ventana en lugar de funciones GROUP BY
Al utilizar `GROUP BY`, se modifica el conjunto de resultados y luego se recupera el resultado agregado. Con las funciones de ventana, se agregan los datos sin cambiar el conjunto de resultados. Una función de ventana utiliza la cláusula `OVER` para efectuar cálculos a través de los conjuntos definidos por la consulta, correlacionando una fila con otra. Puede utilizar todas las funciones `GROUP BY` en las funciones de ventana, pero también puede utilizar funciones como las siguientes:
+ `RANK`
+ `ARRAY_AGG`
+ `ROW_NUMBER`
+ `LAG`
+ `LEAD`
Para minimizar el número de archivos temporales generados por una función de ventana, elimine las duplicaciones para el mismo conjunto de resultados cuando necesite dos agregaciones distintas. Analice la siguiente consulta.
```
SELECT sum(salary) OVER (PARTITION BY dept ORDER BY salary DESC) as sum_salary
, avg(salary) OVER (PARTITION BY dept ORDER BY salary ASC) as avg_salary
FROM empsalary;
```
Puede volver a escribir la consulta con la cláusula `WINDOW` de la siguiente manera.
```
SELECT sum(salary) OVER w as sum_salary
, avg(salary) OVER w as_avg_salary
FROM empsalary
WINDOW w AS (PARTITION BY dept ORDER BY salary DESC);
```
De forma predeterminada, el planificador de ejecución de RDS para PostgreSQL consolida nodos similares para no duplicar operaciones. Sin embargo, al utilizar una declaración explícita para el bloque de la ventana, puede actualizar la consulta más fácilmente. También puede mejorar el rendimiento al evitar la duplicación.
### Investigar las vistas materializadas y las instrucciones CTA
Cuando una vista materializada se actualiza, ejecuta una consulta. Esta consulta puede contener una operación como `GROUP BY`, `ORDER BY` o `DISTINCT`. Durante una actualización, es posible que observe un gran número de archivos temporales y los eventos de espera `IO:BufFileWrite` e `IO:BufFileRead`. Del mismo modo, cuando se crea una tabla basada en una instrucción `SELECT`, la instrucción `CREATE TABLE` ejecuta una consulta. Para reducir los archivos temporales necesarios, optimice la consulta.
### Utilizar pg\$1repack al reconstruir índices
Cuando se crea un índice, el motor ordena el conjunto de resultados. A medida que las tablas aumentan de tamaño y los valores de la columna indexada se diversifican, los archivos temporales requieren más espacio. En la mayoría de los casos, no se puede evitar la creación de archivos temporales para tablas grandes sin modificar el área de memoria de trabajo de mantenimiento. Para obtener más información acerca de `maintenance_work_mem`, consulte [https://www.postgresql.org/docs/current/runtime-config-resource.html](https://www.postgresql.org/docs/current/runtime-config-resource.html) en la documentación de PostgreSQL.
Una posible solución para recrear un índice grande es utilizar la extensión pg\$1repack. Para más información, consulte [Reorganize tables in PostgreSQL databases with minimal locks](https://reorg.github.io/pg_repack/) en la documentación de pg\$1repack. Para obtener información sobre la configuración de la extensión en su instancia de base de datos de RDS para PostgreSQL, consulte [Reducción de la sobrecarga en tablas e índices con la extensión pg\$1repack](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md).
### Aumentar maintenance\$1work\$1mem al hacer un clúster de tablas
El comando `CLUSTER` hace un clúster de la tabla especificada por *table\$1name* basado en un índice existente especificado por *index\$1name*. RDS para PostgreSQL recrea físicamente la tabla para que coincida con el orden de un índice determinado.
Cuando el almacenamiento magnético era frecuente, los clústeres eran comunes porque el rendimiento del almacenamiento era limitado. Ahora que el almacenamiento basado en SSD es común, los clústeres son menos populares. Sin embargo, si se hacen clústeres en las tablas, se puede aumentar ligeramente el rendimiento en función del tamaño de la tabla, índice, consulta, etc.
Si ejecuta el comando `CLUSTER` y observa los eventos de espera `IO:BufFileWrite` e `IO:BufFileRead`, ajuste `maintenance_work_mem`. Aumente el tamaño de la memoria a una cantidad bastante grande. Un valor alto significa que el motor puede utilizar más memoria para la operación de clusterización.
### Ajustar la memoria para evitar IO:BufFileRead e IO:BufFileWrite
En algunas situaciones, es necesario ajustar la memoria. Su objetivo es equilibrar la memoria en las siguientes áreas de consumo mediante los parámetros adecuados, de la siguiente manera.
+ El valor `work_mem`
+ La memoria restante después de descontar el valor `shared_buffers`
+ El máximo de conexiones abiertas y en uso, que está limitado por `max_connections`
Para obtener más información sobre el ajuste de la memoria, consulte el punto [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) (Consumo de recursos) en la documentación de PostgreSQL.
#### Aumentar el tamaño del área de memoria de trabajo
En algunas situaciones, la única opción es aumentar la memoria que utiliza la sesión. Si las consultas están correctamente escritas y se utilizan las claves correctas para las uniones, considere aumentar el valor `work_mem`.
Para saber cuántos archivos temporales genera una consulta, establezca `log_temp_files` en `0`. Si aumenta el valor de `work_mem` hasta el valor máximo identificado en los registros, evitará que la consulta genere archivos temporales. Sin embargo, `work_mem` establece el máximo por nodo del plan para cada conexión o proceso de trabajo paralelo. Si la base de datos tiene 5000 conexiones, y si cada una utiliza 256 MiB de memoria, el motor necesita 1.2 TiB de RAM. Esto significa que la instancia podría quedarse sin memoria.
#### Reservar suficiente memoria para el grupo de búferes compartidos
La base de datos utiliza áreas de memoria como el grupo de búferes compartidos, no solo el área de memoria de trabajo. Tenga en cuenta los requisitos de estas áreas de memoria adicionales antes de aumentar `work_mem`.
Por ejemplo, supongamos que su clase de instancia de RDS para PostgreSQL es db.r5.2xlarge. Esta clase tiene 64 GiB de memoria. De forma predeterminada, el 25 por ciento de la memoria se reserva para el grupo de búferes compartidos. Después de restar la cantidad asignada al área de memoria compartida, quedan 16 384 MB. No asigne la memoria restante exclusivamente al área de memoria de trabajo porque el sistema operativo y el motor también necesitan memoria.
La memoria que puedes asignar a `work_mem` depende de la clase de instancia. Si utiliza una clase de instancia más grande, habrá más memoria disponible. Sin embargo, en el ejemplo anterior, no puedes usar más de 16 GiB. De lo contrario, la instancia dejará de estar disponible cuando se agote la memoria. Para recuperar la instancia del estado no disponible, los servicios de automatización de RDS para PostgreSQL se reinician automáticamente.
#### Administrar el número de conexiones
Supongamos que la instancia de su base de datos tiene 5 000 conexiones simultáneas. Cada conexión utiliza al menos 4 MiB de `work_mem`. El alto consumo de memoria de las conexiones puede degradar el rendimiento. Para ello, tiene las siguientes opciones:
+ Actualizar a una clase de instancia mayor.
+ Disminuir el número de conexiones simultáneas a la base de datos mediante el uso de un proxy de conexión o un grupo de conexiones.
En el caso de los proxies, considere Amazon RDS Proxy, pgBouncer o un grupo de conexiones acorde con su aplicación. Esta solución alivia la carga de la CPU. También reduce el riesgo cuando todas las conexiones requieren el área de memoria de trabajo. Cuando hay menos conexiones a la base de datos, puede aumentar el valor de `work_mem`. De esta manera, se reduce la ocurrencia de los eventos de espera `IO:BufFileRead` y `IO:BufFileWrite`. Además, las consultas que esperan el área de memoria de trabajo se aceleran de forma significativa.
# IO:DataFileRead
El evento `IO:DataFileRead` ocurre cuando una conexión espera en un proceso backend para leer una página requerida del almacenamiento porque la página no está disponible en la memoria compartida.
**Topics**
+ [Versiones del motor admitidas](#wait-event.iodatafileread.context.supported)
+ [Contexto](#wait-event.iodatafileread.context)
+ [Causas probables del aumento de las esperas](#wait-event.iodatafileread.causes)
+ [Acciones](#wait-event.iodatafileread.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Contexto
Todas las consultas y operaciones de manipulación de datos (DML) acceden a páginas en el grupo de búferes. Las instrucciones que pueden inducir lecturas incluyen `SELECT`, `UPDATE` y `DELETE`. Por ejemplo, un `UPDATE` puede leer páginas de tablas o índices. Si la página que se solicita o actualiza no está en el grupo de búferes compartidos, esta lectura puede provocar el evento `IO:DataFileRead`.
Dado que el grupo de búferes compartidos es finito, puede llenarse. En este caso, las solicitudes de páginas que no están en la memoria obligan a la base de datos a leer bloques del disco. Si el evento `IO:DataFileRead` se produce con frecuencia, es posible que el grupo de búferes compartidos sea demasiado pequeño para acomodar la carga de trabajo. Este problema se agudiza en las consultas `SELECT` que leen un gran número de filas que no caben en el grupo de búferes. Para obtener más información acerca del grupo de búferes, consulte el punto [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) (Consumo de recursos) en la documentación de PostgreSQL.
## Causas probables del aumento de las esperas
Las causas más comunes del evento `IO:DataFileRead` son las siguientes:
**Picos de conexión**
Es posible que varias conexiones generen el mismo número de eventos de espera IO:DataFileRead. En este caso, puede producirse un pico (aumento repentino y grande) en los eventos `IO:DataFileRead`.
**Instrucciones SELECT y DML que hacen escaneos secuenciales**
Es posible que la aplicación realice una nueva operación. O una operación existente podría cambiar debido a un nuevo plan de ejecución. En estos casos, busque las tablas (particularmente las tablas grandes) que tengan un valor de `seq_scan` mayor. Encuéntrelas mediante la consulta de `pg_stat_user_tables`. Para rastrear las consultas que generan más operaciones de lectura, utilice la extensión `pg_stat_statements`.
**CTAS y CREATE INDEX para grandes conjuntos de datos**
Un *CTAS* es una instrucción `CREATE TABLE AS SELECT`. Si ejecuta un CTAS con un conjunto de datos grande como origen, o crea un índice en una tabla grande, puede producirse el evento `IO:DataFileRead`. Cuando se crea un índice, es posible que la base de datos tenga que leer todo el objeto mediante una exploración secuencial. Un CTAS genera lecturas `IO:DataFile` cuando las páginas no están en la memoria.
**Varios procesos de trabajo de vacío que se ejecutan al mismo tiempo**
Los procesos de trabajo de vacío pueden activarse de forma manual o automática. Se recomienda adoptar una estrategia de vacío agresiva. Sin embargo, cuando una tabla tiene muchas filas actualizadas o eliminadas, las esperas `IO:DataFileRead` aumentan. Una vez recuperado el espacio, el tiempo de vacío dedicado a `IO:DataFileRead` disminuye.
**Ingesta de grandes cantidades de datos**
Cuando la aplicación ingiere grandes cantidades de datos, las operaciones `ANALYZE` pueden producirse con mayor frecuencia. El proceso `ANALYZE` se puede activar mediante un desencadenador de autovacuum o invocarse de forma manual.
La operación `ANALYZE` lee un subconjunto de la tabla. El número de páginas que deben ser escaneadas se calcula al multiplicar 30 por el valor de `default_statistics_target`. Para obtener más información, consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET). El parámetro `default_statistics_target` acepta valores entre 1 y 10 000, siendo el valor por defecto 100.
**Falta de recursos**
Si el ancho de banda de la red de la instancia o la CPU se consumen, el evento `IO:DataFileRead` podría ocurrir con más frecuencia.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Verificar los filtros de predicado para las consultas que generan esperas](#wait-event.iodatafileread.actions.filters)
+ [Minimizar el efecto de las operaciones de mantenimiento](#wait-event.iodatafileread.actions.maintenance)
+ [Responder a un gran número de conexiones](#wait-event.iodatafileread.actions.connections)
### Verificar los filtros de predicado para las consultas que generan esperas
Supongamos que identifica consultas específicas que generan eventos de espera `IO:DataFileRead`. Puede identificarlos con las siguientes técnicas:
+ Información sobre rendimiento
+ Vistas de catálogo como la que proporciona la extensión `pg_stat_statements`
+ La vista de catálogo `pg_stat_all_tables`, si muestra de forma periódica un aumento del número de lecturas físicas
+ La vista `pg_statio_all_tables`, si muestra que los contadores `_read` aumentan
Le recomendamos que determine qué filtros se utilizan en el predicado (cláusula `WHERE`) de estas consultas. Siga estas instrucciones:
+ Ejecute el comando `EXPLAIN`. En la salida, identifique qué tipos de escaneos se utilizan. Un escaneo secuencial no indica necesariamente un problema. Las consultas que utilizan escaneos secuenciales producen naturalmente más eventos `IO:DataFileRead` en comparación con las consultas que utilizan filtros.
Averigüe si la columna que aparece en la cláusula `WHERE` se encuentra en un índice. Si no es así, considere la posibilidad de crear un índice para esta columna. Este enfoque evita los escaneos secuenciales y reduce los eventos `IO:DataFileRead`. Si una consulta tiene filtros restrictivos y produce aún escaneos secuenciales, evalúe si se utilizan los índices adecuados.
+ Verifique si la consulta tiene acceso a una tabla muy grande. En algunos casos, la partición de una tabla puede mejorar el rendimiento, ya que permite que la consulta solo lea las particiones necesarias.
+ Examine la cardinalidad (número total de filas) de sus operaciones de unión. Tenga en cuenta lo restrictivos que son los valores que se pasan en los filtros de la cláusula `WHERE`. Si es posible, ajuste su consulta para reducir el número de filas que se pasan en cada paso del plan.
### Minimizar el efecto de las operaciones de mantenimiento
Las operaciones de mantenimiento como `VACUUM` y `ANALYZE` son importantes. Le recomendamos que no las desactive ya que encontrará eventos de espera `IO:DataFileRead` relacionados con estas operaciones de mantenimiento. Los siguientes enfoques pueden minimizar el efecto de estas operaciones:
+ Ejecute las operaciones de mantenimiento de forma manual durante las horas de menor actividad. Esta técnica evita que la base de datos alcance el umbral de las operaciones automáticas.
+ Para tablas muy grandes, considere la posibilidad de particionar la tabla. Esta técnica reduce la sobrecarga de las operaciones de mantenimiento. La base de datos solo accede a las particiones que requieren mantenimiento.
+ Cuando capture grandes cantidades de datos, considere la posibilidad de desactivar la característica de autoanálisis.
La característica de autovacuum se activa de forma automática para una tabla cuando la siguiente fórmula es verdadera.
```
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
```
La vista `pg_stat_user_tables` y el catálogo `pg_class` tienen varias filas. Una fila puede corresponder a una fila de la tabla. Esta fórmula asume que las `reltuples` son para una tabla específica. Los parámetros `autovacuum_vacuum_scale_factor` (0,20 de forma predeterminada) y `autovacuum_vacuum_threshold` (50 tuplas de forma predeterminada) se suelen establecer de forma global para toda la instancia. Sin embargo, puede establecer valores diferentes para una tabla específica.
**Topics**
+ [Buscar tablas que consuman espacio de forma innecesaria](#wait-event.iodatafileread.actions.maintenance.tables)
+ [Buscar índices que consuman espacio de forma innecesaria](#wait-event.iodatafileread.actions.maintenance.indexes)
+ [Buscar tablas aptas para autovacuum](#wait-event.iodatafileread.actions.maintenance.autovacuumed)
#### Buscar tablas que consuman espacio de forma innecesaria
Para encontrar tablas que consuman espacio innecesariamente, puede utilizar funciones de la extensión `pgstattuple` de PostgreSQL. Esta extensión (módulo) está disponible de forma predeterminada en todas las instancias de base de datos de RDS para PostgreSQL y se puede instanciar en la instancia con el siguiente comando.
```
CREATE EXTENSION pgstattuple;
```
Para obtener más información sobre esta extensión, consulte [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html) en la documentación de PostgreSQL.
Puede comprobar si hay una sobrecarga de tablas e índices en su aplicación. Para obtener más información, consulte [Diagnóstico de sobrecarga de tablas e índices](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html).
#### Buscar índices que consuman espacio de forma innecesaria
Para encontrar índices sobrecargados y estimar la cantidad de espacio consumida innecesariamente en las tablas para las que tiene privilegios de lectura, puede ejecutar la siguiente consulta.
```
-- WARNING: rows with is_na = 't' are known to have bad statistics ("name" type is not supported).
-- This query is compatible with PostgreSQL 8.2 and later.
SELECT current_database(), nspname AS schemaname, tblname, idxname, bs*(relpages)::bigint AS real_size,
bs*(relpages-est_pages)::bigint AS extra_size,
100 * (relpages-est_pages)::float / relpages AS extra_ratio,
fillfactor, bs*(relpages-est_pages_ff) AS bloat_size,
100 * (relpages-est_pages_ff)::float / relpages AS bloat_ratio,
is_na
-- , 100-(sub.pst).avg_leaf_density, est_pages, index_tuple_hdr_bm,
-- maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, sub.reltuples, sub.relpages
-- (DEBUG INFO)
FROM (
SELECT coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)/(4+nulldatahdrwidth)::float)), 0
-- ItemIdData size + computed avg size of a tuple (nulldatahdrwidth)
) AS est_pages,
coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)*fillfactor/(100*(4+nulldatahdrwidth)::float))), 0
) AS est_pages_ff,
bs, nspname, table_oid, tblname, idxname, relpages, fillfactor, is_na
-- , stattuple.pgstatindex(quote_ident(nspname)||'.'||quote_ident(idxname)) AS pst,
-- index_tuple_hdr_bm, maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples
-- (DEBUG INFO)
FROM (
SELECT maxalign, bs, nspname, tblname, idxname, reltuples, relpages, relam, table_oid, fillfactor,
( index_tuple_hdr_bm +
maxalign - CASE -- Add padding to the index tuple header to align on MAXALIGN
WHEN index_tuple_hdr_bm%maxalign = 0 THEN maxalign
ELSE index_tuple_hdr_bm%maxalign
END
+ nulldatawidth + maxalign - CASE -- Add padding to the data to align on MAXALIGN
WHEN nulldatawidth = 0 THEN 0
WHEN nulldatawidth::integer%maxalign = 0 THEN maxalign
ELSE nulldatawidth::integer%maxalign
END
)::numeric AS nulldatahdrwidth, pagehdr, pageopqdata, is_na
-- , index_tuple_hdr_bm, nulldatawidth -- (DEBUG INFO)
FROM (
SELECT
i.nspname, i.tblname, i.idxname, i.reltuples, i.relpages, i.relam, a.attrelid AS table_oid,
current_setting('block_size')::numeric AS bs, fillfactor,
CASE -- MAXALIGN: 4 on 32bits, 8 on 64bits (and mingw32 ?)
WHEN version() ~ 'mingw32' OR version() ~ '64-bit|x86_64|ppc64|ia64|amd64' THEN 8
ELSE 4
END AS maxalign,
/* per page header, fixed size: 20 for 7.X, 24 for others */
24 AS pagehdr,
/* per page btree opaque data */
16 AS pageopqdata,
/* per tuple header: add IndexAttributeBitMapData if some cols are null-able */
CASE WHEN max(coalesce(s.null_frac,0)) = 0
THEN 2 -- IndexTupleData size
ELSE 2 + (( 32 + 8 - 1 ) / 8)
-- IndexTupleData size + IndexAttributeBitMapData size ( max num filed per index + 8 - 1 /8)
END AS index_tuple_hdr_bm,
/* data len: we remove null values save space using it fractionnal part from stats */
sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024)) AS nulldatawidth,
max( CASE WHEN a.atttypid = 'pg_catalog.name'::regtype THEN 1 ELSE 0 END ) > 0 AS is_na
FROM pg_attribute AS a
JOIN (
SELECT nspname, tbl.relname AS tblname, idx.relname AS idxname,
idx.reltuples, idx.relpages, idx.relam,
indrelid, indexrelid, indkey::smallint[] AS attnum,
coalesce(substring(
array_to_string(idx.reloptions, ' ')
from 'fillfactor=([0-9]+)')::smallint, 90) AS fillfactor
FROM pg_index
JOIN pg_class idx ON idx.oid=pg_index.indexrelid
JOIN pg_class tbl ON tbl.oid=pg_index.indrelid
JOIN pg_namespace ON pg_namespace.oid = idx.relnamespace
WHERE pg_index.indisvalid AND tbl.relkind = 'r' AND idx.relpages > 0
) AS i ON a.attrelid = i.indexrelid
JOIN pg_stats AS s ON s.schemaname = i.nspname
AND ((s.tablename = i.tblname AND s.attname = pg_catalog.pg_get_indexdef(a.attrelid, a.attnum, TRUE))
-- stats from tbl
OR (s.tablename = i.idxname AND s.attname = a.attname))
-- stats from functional cols
JOIN pg_type AS t ON a.atttypid = t.oid
WHERE a.attnum > 0
GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9
) AS s1
) AS s2
JOIN pg_am am ON s2.relam = am.oid WHERE am.amname = 'btree'
) AS sub
-- WHERE NOT is_na
ORDER BY 2,3,4;
```
#### Buscar tablas aptas para autovacuum
Para buscar tablas que se puedan vaciar automáticamente, ejecute la siguiente consulta.
```
--This query shows tables that need vacuuming and are eligible candidates.
--The following query lists all tables that are due to be processed by autovacuum.
-- During normal operation, this query should return very little.
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold
FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold')
, vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor
FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor')
, fma AS (SELECT setting AS autovacuum_freeze_max_age
FROM pg_settings WHERE name = 'autovacuum_freeze_max_age')
, sto AS (SELECT opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value
FROM (SELECT oid opt_oid, unnest(reloptions) setting FROM pg_class) opt)
SELECT
'"'||ns.nspname||'"."'||c.relname||'"' as relation
, pg_size_pretty(pg_table_size(c.oid)) as table_size
, age(relfrozenxid) as xid_age
, coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age
, (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
as autovacuum_vacuum_tuples
, n_dead_tup as dead_tuples
FROM pg_class c
JOIN pg_namespace ns ON ns.oid = c.relnamespace
JOIN pg_stat_all_tables stat ON stat.relid = c.oid
JOIN vbt on (1=1)
JOIN vsf ON (1=1)
JOIN fma on (1=1)
LEFT JOIN sto cvbt ON cvbt.param = 'autovacuum_vacuum_threshold' AND c.oid = cvbt.opt_oid
LEFT JOIN sto cvsf ON cvsf.param = 'autovacuum_vacuum_scale_factor' AND c.oid = cvsf.opt_oid
LEFT JOIN sto cfma ON cfma.param = 'autovacuum_freeze_max_age' AND c.oid = cfma.opt_oid
WHERE c.relkind = 'r'
AND nspname <> 'pg_catalog'
AND (
age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
or
coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup
-- or 1 = 1
)
ORDER BY age(relfrozenxid) DESC;
```
### Responder a un gran número de conexiones
Cuando se monitorea Amazon CloudWatch, se puede encontrar que la métrica `DatabaseConnections` se dispara. Este aumento indica un mayor número de conexiones a su base de datos. Se recomienda el siguiente enfoque:
+ Limite el número de conexiones que la aplicación puede abrir con cada instancia. Si la aplicación tiene una característica de grupo de conexiones integrada, establezca un número razonable de conexiones. Base el número en lo que las vCPU de su instancia puedan paralelizar de forma efectiva.
Si su aplicación no utiliza una característica de grupo de conexiones, considere utilizar Amazon RDS Proxy o una alternativa. Este enfoque permite que su aplicación abra varias conexiones con el equilibrador de carga. El equilibrador puede entonces abrir un número restringido de conexiones con la base de datos. Como se ejecutan menos conexiones en paralelo, la instancia de base de datos hace menos cambios de contexto en el núcleo. Las consultas deberían progresar más rápido, lo que provocaría menos eventos de espera. Para obtener más información, consulte [Amazon RDS Proxy ](rds-proxy.md).
+ Siempre que sea posible, aproveche las réplicas de lectura para RDS para PostgreSQL. Cuando la aplicación ejecute una operación de solo lectura, envíe estas solicitudes a la(s) réplica(s) de lectura. Esta técnica reduce la presión de E/S en el nodo principal (de escritura).
+ Considere la posibilidad de escalar verticalmente su instancia de base de datos. Una clase de instancia de mayor capacidad proporciona más memoria, lo que le da a RDS para PostgreSQL un grupo de búferes compartidos mayor para mantener las páginas. El tamaño más grande también le da a la instancia de base de datos más vCPU para manejar las conexiones. Más vCPU son especialmente útiles cuando las operaciones que generan eventos de espera `IO:DataFileRead` se escriben.
# IO:WALWrite
**Topics**
+ [Versiones del motor admitidas](#wait-event.iowalwrite.context.supported)
+ [Contexto](#wait-event.iowalwrite.context)
+ [Causas probables del aumento del tiempo de espera](#wait-event.iowalwrite.causes)
+ [Acciones](#wait-event.iowalwrite.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL 10 y posteriores.
## Contexto
La actividad de la base de datos que genera datos de registro de escritura anticipada llena primero los búferes de WAL y, a continuación, los escribe en el disco de forma asincrónica. El evento de espera `IO:WALWrite` se genera cuando la sesión de SQL espera a que los datos de WAL terminen de escribirse en el disco para poder lanzar la llamada COMMIT de la transacción.
## Causas probables del aumento del tiempo de espera
Si este evento de espera se produce con frecuencia, debe revisar su carga de trabajo, el tipo de actualizaciones que realiza y su frecuencia. En particular, busque los siguientes tipos de actividad.
**Actividad intensa de DML**
El cambio de datos en las tablas de bases de datos no se produce de forma instantánea. Es posible que una inserción en una tabla deba esperar a que otro cliente inserte o actualice la misma tabla. Las instrucciones del lenguaje de manipulación de datos (DML) para cambiar los valores de los datos (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) pueden generar disputas que hagan que el archivo de registro de escritura anticipada espere a que se vacíen los búferes. Esta situación se refleja en las siguientes métricas de Información de rendimiento de Amazon RDS, que indican una actividad de DML intensa.
+ `tup_inserted`
+ `tup_updated`
+ `tup_deleted`
+ `xact_rollback`
+ `xact_commit`
Para obtener más información sobre estas métricas, consulte [Contadores de Información sobre rendimiento para Amazon RDS para PostgreSQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.PostgreSQL).
**Actividad de puntos de comprobación frecuente**
Los puntos de control frecuentes contribuyen a aumentar el número de archivos WAL. En RDS para PostgreSQL, la escritura de páginas completas siempre está «activada». La escritura de páginas completas ayuda a proteger contra la pérdida de datos. Sin embargo, cuando los puntos de comprobación se realizan con demasiada frecuencia, el sistema puede sufrir problemas de rendimiento general. Esto es especialmente cierto en sistemas con una actividad intensa de DML. En algunos casos, es posible que encuentres mensajes de error en tel `postgresql.log` que indiquen que «los puntos de comprobación se producen con demasiada frecuencia».
Le recomendamos que, al ajustar los puntos de comprobación, equilibre cuidadosamente el rendimiento con el tiempo esperado de recuperación en caso de que se produzca un cierre anormal.
## Acciones
Le recomendamos que realice las siguientes acciones para reducir los números de este evento de espera.
**Topics**
+ [Reducir el número de confirmaciones](#wait-event.iowalwrite.actions.problem)
+ [Monitorear los puntos de comprobación](#wait-event.iowalwrite.actions.monitor)
+ [Escalar la E/S verticalmente](#wait-event.iowalwrite.actions.scale-io)
+ [Volumen de registro específico (DLV)](#wait-event.iowalwrite.actions.dlv)
### Reducir el número de confirmaciones
Para reducir el número de confirmaciones, combine las instrucciones en bloques de transacciones. Utilice Información de rendimiento de Amazon RDS para examinar el tipo de consultas que se está ejecutando. También puede trasladar las grandes operaciones de mantenimiento a las horas de menor actividad. Por ejemplo, cree índices o utilice operaciones `pg_repack` durante las horas que no sean de producción.
### Monitorear los puntos de comprobación
Hay dos parámetros que puede monitorear para ver con qué frecuencia su instancia de base de datos de RDS para PostgreSQL escribe puntos de comprobación en el archivo WAL.
+ `log_checkpoints`: este parámetro está activado de forma predeterminada. Hace que se envíe un mensaje al registro de PostgreSQL para cada punto de comprobación. Estos mensajes de registro incluyen la cantidad de búferes escritos, el tiempo dedicado a escribirlos y la cantidad de archivos WAL agregados, eliminados o reciclados para un punto de comprobación determinado.
Para más información sobre este parámetro, consulte Error Reporting and Logging (Registro y notificación de errores) en la documentación de PostgreSQL.
+ `checkpoint_warning`: este parámetro establece un valor umbral (en segundos) para la frecuencia del punto de comprobación por encima del cual se genera una advertencia. De forma predeterminada, este parámetro no está configurado en RDS para PostgreSQL. Puede establecer el valor de este parámetro de modo que reciba una advertencia cuando los cambios en la base de datos de su instancia de base de datos de RDS para PostgreSQL se escriban a una velocidad para la que los archivos WAL no tengan el tamaño adecuado. Por ejemplo, supongamos que establece este parámetro en 30. Si su instancia de RDS para PostgreSQL necesita escribir cambios con mayor frecuencia que cada 30 segundos, se envía la advertencia «los puntos de comprobación se producen con demasiada frecuencia» al registro de PostgreSQL. Esto puede indicar que su valor `max_wal_size` debe aumentarse.
Para obtener más información, consulte [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS) (Registro de escritura anticipada) en la documentación de PostgreSQL.
### Escalar la E/S verticalmente
Este tipo de evento de espera de entrada/salida (E/S) se puede solucionar escalando las operaciones de entrada/salida por segundo (IOPS) para proporcionar una E/S más rápida. Es preferible escalar la E/S a escalar la CPU, ya que escalar la CPU puede generar aún más contención de E/S, ya que el aumento de la CPU puede soportar más trabajo y, por lo tanto, agravar aún más el cuello de botella de E/S. En general, recomendamos que considere ajustar la carga de trabajo antes de realizar las operaciones de escalado.
### Volumen de registro específico (DLV)
Puede utilizar un volumen de registro específico (DLV) para una instancia de base de datos que utilice el almacenamiento de IOPS aprovisionadas (PIOPS) mediante la consola de Amazon RDS, la AWS CLI o la API de Amazon RDS. Un DLV transporta los registros de transacciones de la base de datos PostgreSQL a un volumen de almacenamiento independiente del volumen que contiene las tablas de la base de datos. Para obtener más información, consulte [Volumen de registro específico (DLV)](CHAP_Storage.md#CHAP_Storage.dlv).
# Eventos de espera de IPC:parallel
Los siguientes `IPC:parallel wait events` indican que una sesión está esperando una comunicación entre procesos relacionada con operaciones de ejecución de consultas en paralelo.
+ `IPC:BgWorkerStartup`: un proceso está esperando a que un proceso de trabajo paralelo complete la secuencia de inicio. Esto sucede al inicializar los procesos de trabajo para la ejecución de consultas en paralelo.
+ `IPC:BgWorkerShutdown`: un proceso está esperando a que un proceso de trabajo paralelo complete la secuencia de apagado. Esto sucede durante la fase de limpieza de la ejecución de consultas en paralelo.
+ `IPC:ExecuteGather`: un proceso está esperando recibir datos de procesos de trabajo paralelos durante la ejecución de consultas. Esto ocurre cuando el proceso líder necesita recopilar resultados de los procesos de trabajo.
+ `IPC:ParallelFinish`: un proceso está esperando a que los procesos de trabajo paralelos finalicen la ejecución y comuniquen los resultados finales. Esto sucede durante la fase de finalización de la ejecución de consultas en paralelo.
**Topics**
+ [Versiones del motor admitidas](#rpg-ipc-parallel-context-supported)
+ [Contexto](#rpg-ipc-parallel-context)
+ [Causas probables del aumento de las esperas](#rpg-ipc-parallel-causes)
+ [Acciones](#rpg-ipc-parallel-actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de Aurora PostgreSQL.
## Contexto
La ejecución de consultas en paralelo en PostgreSQL implica que varios procesos trabajan juntos para procesar una sola consulta. Cuando se determina que una consulta es adecuada para la paralelización, un proceso líder coordina uno o varios procesos de trabajo paralelos en función de la configuración del parámetro `max_parallel_workers_per_gather`. El proceso líder divide el trabajo entre los procesos de trabajo, cada proceso de trabajo procesa la parte de los datos de forma independiente y los resultados se recopilan de nuevo en el proceso líder.
**nota**
Cada proceso de trabajo paralelo funciona como un proceso independiente con requisitos de recursos similares a los de una sesión de usuario completa. Esto significa que una consulta en paralelo con cuatro procesos de trabajo puede consumir hasta cinco veces más recursos (CPU, memoria y ancho de banda de E/S) que una consulta que no sea en paralelo, ya que tanto el proceso líder como cada proceso de trabajo mantienen las asignaciones de recursos propias. Por ejemplo, la configuración como `work_mem` se aplica individualmente a cada proceso de trabajo, lo que puede multiplicar el uso total de memoria en todos los procesos.
La arquitectura de consulta en paralelo consta de tres componentes principales:
+ Proceso líder: el proceso principal que inicia la operación paralela, divide la carga de trabajo y coordina los procesos de trabajo.
+ Procesos de trabajo: procesos en segundo plano que ejecutan partes de la consulta en paralelo.
+ Recopilación/combinación de recopilaciones: operaciones que combinan los resultados de varios procesos de trabajo y los devuelven al líder
Durante la ejecución en paralelo, los procesos deben comunicarse entre sí a través de mecanismos de comunicación entre procesos (IPC). Estos eventos de espera de IPC se producen durante diferentes fases:
+ Inicio de procesos de trabajo: cuando se inicializan los procesos de trabajo paralelos
+ Intercambio de datos: cuando los procesos de trabajo procesan datos y envían los resultados al líder
+ Cierre de procesos de trabajo: cuando finaliza la ejecución paralela y se terminan los procesos de trabajo
+ Puntos de sincronización: cuando los procesos necesitan coordinarse o esperar a que otros procesos completen las tareas
Comprender estos eventos de espera es fundamental para diagnosticar problemas de rendimiento relacionados con la ejecución de consultas en paralelo, sobre todo en entornos de alta simultaneidad en los que pueden ejecutarse varias consultas en paralelo al mismo tiempo.
## Causas probables del aumento de las esperas
Hay varios factores que pueden contribuir a un aumento de los eventos de espera de IPC relacionados con la ejecución en paralelo:
**Alta simultaneidad de consultas en paralelo**
Cuando se ejecutan muchas consultas en paralelo al mismo tiempo, puede producirse una contención de recursos y un aumento de los tiempos de espera para las operaciones de IPC. Esto es muy habitual en sistemas con grandes volúmenes de transacciones o cargas de trabajo de análisis.
**Planes de consultas en paralelo poco óptimos**
Si el planificador de consultas elige planes paralelos ineficientes, puede dar lugar a una paralelización innecesaria o a una distribución deficiente del trabajo entre los procesos de trabajo. Esto puede provocar un aumento de las esperas de IPC, sobre todo para los eventos `IPC:ExecuteGather` e `IPC:ParallelFinish`. Estos problemas de planificación suelen deberse a estadísticas obsoletas y a la saturación de tablas e índices.
**Inicio y apagado frecuentes de procesos de trabajo paralelos**
Las consultas de corta duración que inician y terminan con frecuencia procesos de trabajo paralelos pueden provocar un aumento de los eventos `IPC:BgWorkerStartup` y `IPC:BgWorkerShutdown`. Esto se observa a menudo en cargas de trabajo OLTP con muchas consultas pequeñas y paralelizables.
**Limitaciones de recursos**
La capacidad limitada de CPU, memoria o E/S puede provocar cuellos de botella en la ejecución paralela, lo que aumenta los tiempos de espera en todos los eventos de IPC. Por ejemplo, si la CPU está saturada, los procesos de trabajo pueden tardar más en iniciarse o en procesar la parte del trabajo.
**Estructuras de consultas complejas**
Las consultas con varios niveles de paralelismo (por ejemplo, uniones paralelas seguidas de agregaciones paralelas) pueden dar lugar a patrones de IPC más complejos y a un aumento de los tiempos de espera, sobre todo para eventos `IPC:ExecuteGather`.
**Grandes conjuntos de resultados**
Las consultas que producen conjuntos de resultados grandes pueden provocar un aumento de los tiempos de espera de `IPC:ExecuteGather`, ya que el proceso líder dedica más tiempo a recopilar y procesar los resultados de los procesos de trabajo.
Comprender estos factores puede ayudar a diagnosticar y resolver problemas de rendimiento relacionados con la ejecución de consultas paralelas en Aurora PostgreSQL.
## Acciones
Cuando ve esperas relacionadas con consultas en paralelo, normalmente significa que un proceso backend está coordinando o esperando procesos de trabajo paralelos. Estas esperas son comunes durante la ejecución de planes paralelos. Puede investigar y mitigar el impacto de estas esperas mediante la supervisión del uso de procesos de trabajo paralelos, la revisión de la configuración de los parámetros y el ajuste de la ejecución de las consultas y asignación de recursos.
**Topics**
+ [Análisis de los planes de consulta en busca de paralelismo ineficiente](#rpg-ipc-parallel-analyze-plans)
+ [Supervisión del uso de consultas en paralelo](#rpg-ipc-parallel-monitor)
+ [Revisión y ajuste de la configuración de consultas en paralelo](#rpg-ipc-parallel-adjust-settings)
+ [Optimización de la asignación de recursos](#rpg-ipc-parallel-optimize-resources)
+ [Investigación de la administración de conexiones](#rpg-ipc-parallel-connection-management)
+ [Revisión y optimización de las operaciones de mantenimiento](#rpg-ipc-parallel-maintenance)
### Análisis de los planes de consulta en busca de paralelismo ineficiente
La ejecución de consultas en paralelo a menudo puede provocar inestabilidad del sistema, picos de CPU y variaciones impredecibles en el rendimiento de las consultas. Es fundamental analizar a fondo si el paralelismo mejora realmente la carga de trabajo específica. Utilice EXPLAIN ANALYZE para revisar los planes de ejecución de consultas en paralelo.
Deshabilite temporalmente el paralelismo de la sesión para comparar la eficiencia del plan:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
```
Vuelva a habilitar el paralelismo y compare:
```
RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE ;
```
Si al deshabilitar el paralelismo se obtienen resultados mejores o más coherentes, considere la posibilidad de deshabilitarlo para consultas específicas de sesión mediante comandos SET. Para lograr un impacto más amplio, es posible que desee deshabilitar el paralelismo de instancia mediante el ajuste de los parámetros pertinentes en el grupo de parámetros de base de datos. Para obtener más información, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Supervisión del uso de consultas en paralelo
Utilice las siguientes consultas para obtener visibilidad de la actividad y la capacidad de las consultas en paralelo:
Compruebe los procesos de trabajo paralelos activos:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Esta consulta muestra el número de procesos de trabajo paralelos activos. Un valor alto puede indicar que “max\$1parallel\$1workers” se ha configurado con un valor alto y es recomendable que considere la posibilidad de reducirlo.
Compruebe las consultas en paralelo simultáneas:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Esta consulta devuelve el número de procesos líderes distintos que han iniciado consultas en paralelo. Un número alto indica que varias sesiones están ejecutando consultas en paralelo simultáneamente, lo que puede aumentar la demanda de CPU y memoria.
### Revisión y ajuste de la configuración de consultas en paralelo
Revise los siguientes parámetros para asegurarse de que se ajusten a la carga de trabajo:
+ `max_parallel_workers`: número total de procesos de trabajo paralelos en todas las sesiones.
+ `max_parallel_workers_per_gather`: número máximo de procesos de trabajo por consulta.
Para cargas de trabajo OLAP, aumentar estos valores puede mejorar el rendimiento. Para cargas de trabajo OLTP, por lo general, se prefieren valores más bajos.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Optimización de la asignación de recursos
Supervise la utilización de la CPU y considere la posibilidad de ajustar el número de vCPU si es coherentemente alto y si la aplicación se beneficia de las consultas en paralelo. Asegúrese de que haya memoria suficiente para las operaciones paralelas.
+ Utilice las métricas de Información de rendimiento para determinar si el sistema está limitado por la CPU.
+ Cada proceso de trabajo paralelo utiliza un `work_mem` propio. Asegúrese de que el uso total de memoria se encuentre dentro de los límites de la instancia.
Las consultas en paralelo pueden consumir muchos más recursos que las consultas que no son en paralelo, ya que cada proceso de trabajo es un proceso completamente independiente que tiene aproximadamente el mismo impacto en el sistema que una sesión de usuario adicional. Esto debe tenerse en cuenta al elegir un valor para esta configuración, así como al configurar otras opciones que controlan la utilización de recursos, como `work_mem`. Para obtener más información, consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Los límites de recursos, como `work_mem`, se aplican individualmente a cada proceso de trabajo, lo que significa que la utilización total puede ser mucho mayor en todos los procesos de lo que sería normalmente para un solo proceso.
Considere la posibilidad de aumentar las vCPU o ajustar los parámetros de memoria si la carga de trabajo está muy paralelizada.
### Investigación de la administración de conexiones
Si se agota la conexión, revise las estrategias de agrupación de conexiones de la aplicación. Considere la posibilidad de implementar la agrupación de conexiones de aplicación si aún no se utiliza.
### Revisión y optimización de las operaciones de mantenimiento
Coordine la creación de índices y otras tareas de mantenimiento para evitar la contención de recursos. Considere la posibilidad de programar estas operaciones durante las horas de menor actividad. Evite programar tareas de mantenimiento intensas (por ejemplo, creaciones de índices en paralelo) durante periodos de alta carga de consultas de los usuarios. Estas operaciones pueden consumir procesos de trabajo paralelos y afectar al rendimiento de las consultas habituales.
# IPC:ProcArrayGroupUpdate
El evento `IPC:ProcArrayGroupUpdate` se produce cuando una sesión está esperando a que líder de grupo actualice el estado de la transacción al final de esa operación. Mientras PostgreSQL generalmente asocia los eventos de espera de tipo IPC con las operaciones de consulta paralelas, este evento de espera en particular no es específico de las consultas paralelas.
**Topics**
+ [Versiones del motor admitidas](#apg-rpg-ipcprocarraygroup.supported)
+ [Contexto](#apg-rpg-ipcprocarraygroup.context)
+ [Causas probables del aumento de las esperas](#apg-rpg-ipcprocarraygroup.causes)
+ [Acciones](#apg-rpg-ipcprocarraygroup.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Contexto
**Descripción de la matriz de procesos**: la matriz de procesos (proc) es una estructura de memoria compartida en PostgreSQL. Contiene información sobre todos los procesos en ejecución, incluidos los detalles de las transacciones. Al finalizar la transacción (`COMMIT` o `ROLLBACK`), el ProcArray debe actualizarse para reflejar el cambio y borrar el ID de transacción de la matriz. La sesión que intente finalizar su transacción debe adquirir un bloqueo exclusivo en el ProcArray. Esto evita que otros procesos obtengan bloqueos compartidos o exclusivos sobre ella.
**Mecanismo de actualización grupal**: al realizar un COMMIT o ROLLBACK, si un proceso de backend no puede obtener un ProcArrayLock en modo exclusivo, actualiza un campo especial llamado ProcArrayGroupMember. Esto agrega la transacción a la lista de sesiones que pretenden finalizar. A continuación, este proceso de backend se suspende y el tiempo que duerme se configura como el evento de espera ProcArrayGroupUpdate. El primer proceso de ProcArray con ProcArrayGroupMember, denominado proceso de líder, adquiere el ProcArrayLock en modo exclusivo. A continuación, borra la lista de procesos en espera de ser liquidados por el ID de transacción del grupo. Una vez finalizada esta operación, el líder libera el ProcArrayLock y activa todos los procesos de la lista y les notifica que la transacción se ha completado.
## Causas probables del aumento de las esperas
Cuantos más procesos estén en ejecución, más tiempo conservará el líder un ProcArrayLock en modo exclusivo. En consecuencia, cuantas más transacciones de escritura acaben en un escenario de actualización grupal, más se provocará una posible acumulación de procesos en espera en el evento de espera `ProcArrayGroupUpdate`. En la vista de SQL principal de información de base de datos, verá que COMMIT es la instrucción que contiene la mayor parte del tiempo de espera. Esto es de esperar, pero requerirá una investigación más profunda del SQL de escritura específico que se está ejecutando para determinar qué medidas se deben tomar.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera. Identifique eventos de `IPC:ProcArrayGroupUpdate` mediante Información de rendimiento de Amazon RDS o la consulta de la vista del sistema PostgreSQL `pg_stat_activity`.
**Topics**
+ [Supervisión de las operaciones de confirmación y reversión de transacciones](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Reducción de la simultaneidad](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Implementación de la agrupación de conexiones](#apg-rpg-ipcprocarraygroup.actions.pooling)
+ [Uso de un almacenamiento más rápido](#apg-rpg-ipcprocarraygroup.actions.storage)
### Supervisión de las operaciones de confirmación y reversión de transacciones
**Supervise las confirmaciones y las reversiones**: un mayor número de confirmaciones y reversiones puede aumentar la presión sobre ProcArray. Por ejemplo, si una instrucción SQL comienza a producir errores debido al aumento de las infracciones de claves duplicadas, es posible que se produzca un aumento de las reversiones, lo que puede aumentar la contención de ProcArray y la sobrecarga de tablas.
La información de base de datos de Amazon RDS proporciona las métricas de PostgreSQL `xact_commit` y `xact_rollback` para informar del número de confirmaciones y reversiones por segundo.
### Reducción de la simultaneidad
**Transacciones por lotes**: siempre que sea posible, agrupe las operaciones en transacciones individuales para reducir las operaciones de confirmación o reversión.
**Limite la simultaneidad**: reduzca la cantidad de transacciones activas simultáneamente para evitar la contención de bloqueos en ProcArray. Si bien requerirá algunas pruebas, reducir el número total de conexiones simultáneas puede reducir la contención y mantener el rendimiento.
### Implementación de la agrupación de conexiones
**Soluciones de agrupación de conexiones**: utilice la agrupación de conexiones para administrar las conexiones de bases de datos de manera eficiente, lo que reduce la cantidad total de backends y, por lo tanto, la carga de trabajo de ProcArray. Si bien requerirá algunas pruebas, reducir el número total de conexiones simultáneas puede reducir la contención y mantener el rendimiento.
**Reduzca las tormentas de conexiones**: del mismo modo, un patrón de creación y terminación frecuentes de conexiones genera una presión adicional sobre ProcArray. Al reducir este patrón, se reduce la contención general.
### Uso de un almacenamiento más rápido
**Volumen de registro dedicado**: si el evento de espera `IPC:ProcArrayGroupUpdate` va acompañado de eventos de espera `IO:WALWrite` altos, la configuración de un volumen de registro dedicado puede reducir los cuellos de botella que se producen al escribir en WAL. A su vez, esto mejora el rendimiento de las confirmaciones.
Para obtener más información, consulte [Volumen de registro específico](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.dlv.html).
# Lock:advisory
El evento `Lock:advisory` ocurre cuando una aplicación PostgreSQL utiliza un bloqueo para coordinar la actividad entre varias sesiones.
**Topics**
+ [Versiones del motor relevantes](#wait-event.lockadvisory.context.supported)
+ [Context](#wait-event.lockadvisory.context)
+ [Causas](#wait-event.lockadvisory.causes)
+ [Acciones](#wait-event.lockadvisory.actions)
## Versiones del motor relevantes
La información de eventos de espera es relevante para RDS para PostgreSQL versión 9.6 y posteriores.
## Context
Los bloqueos consultivos de PostgreSQL son bloqueos cooperativos a nivel de aplicación, bloqueados y desbloqueados explícitamente por el código de la aplicación del usuario. Una aplicación puede usar los bloqueos consultivos de PostgreSQL para coordinar la actividad a través de varias sesiones. A diferencia de los bloqueos regulares a nivel de objeto o de fila, la aplicación tiene control total sobre el tiempo de vida del bloqueo. Para más información, consulte [Advisory Locks](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) en la documentación de PostgreSQL.
Los bloqueos consultivos se pueden liberar antes de que finalice una transacción o mantenerse en una sesión a través de las transacciones. Esto no es verdadero para los bloqueos implícitos, forzados por el sistema, como un bloqueo de acceso exclusivo a una tabla adquirido por una instrucción `CREATE INDEX`.
Para una descripción de las funciones que se utilizan para adquirir (bloquear) y liberar (desbloquear) los bloqueos de asesoramiento, consulte [Advisory Lock Functions](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS) en la documentación de PostgreSQL.
Los bloqueos consultivos se implementan sobre el sistema de bloqueo regular de PostgreSQL y son visibles en la vista del sistema `pg_locks`.
## Causas
Este tipo de bloqueo es controlado exclusivamente por una aplicación que lo utiliza de forma explícita. Los bloqueos consultivos que se adquieren para cada fila como parte de una consulta pueden causar un pico de bloqueos o una acumulación a largo plazo.
Estos efectos se producen cuando la consulta se ejecuta de forma que adquiere bloqueos en más filas de las que devuelve la consulta. La aplicación debe liberar finalmente todos los bloqueos, pero si se adquieren bloqueos en filas que no se devuelven, la aplicación no puede encontrar todos los bloqueos.
El siguiente ejemplo proviene de [Advisory Locks](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) en la documentación de PostgreSQL.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
En este ejemplo, la cláusula `LIMIT` solo puede detener la salida de la consulta después de que las filas se hayan seleccionado internamente y sus valores de ID se hayan bloqueado. Esto puede ocurrir de forma repentina cuando un volumen de datos creciente hace que el planificador elija un plan de ejecución diferente que no fue probado durante el desarrollo. La acumulación en este caso ocurre porque la aplicación llama explícitamente a `pg_advisory_unlock` para cada valor de ID que fue bloqueado. Sin embargo, en este caso no se puede encontrar el conjunto de bloqueos adquiridos en las filas que no fueron devueltas. Como los bloqueos se adquieren a nivel de sesión, no se liberan automáticamente al final de la transacción.
Otra posible causa de los picos de intentos de bloqueo son los conflictos involuntarios. En estos conflictos, partes no relacionadas de la aplicación comparten el mismo espacio de ID de bloqueo por error.
## Acciones
Revisar el uso de la aplicación de los bloqueos consultivos y detallar dónde y cuándo en el flujo de la aplicación se adquiere y libera cada tipo de bloqueo consultivo.
Determine si una sesión adquiere demasiados bloqueos o si una sesión de larga duración no libera los bloqueos con suficiente antelación, lo que provoca una acumulación lenta de bloqueos. Puede corregir una acumulación lenta de bloqueos de sesión si finaliza la sesión con `pg_terminate_backend(pid)`.
Un cliente en espera de un bloqueo consultivo aparece en `pg_stat_activity` con `wait_event_type=Lock` y `wait_event=advisory`. Puede obtener valores de bloqueo específicos al consultar la vista del sistema `pg_locks` para el mismo `pid`, buscando `locktype=advisory` y `granted=f`.
A continuación, puede identificar la sesión de bloqueo al consultar `pg_locks` para el mismo bloqueo consultivo con `granted=t`, como se muestra en el siguiente ejemplo.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Todas las funciones de la API de bloqueo consultivo tienen dos conjuntos de argumentos, un argumento `bigint` o dos argumentos `integer`:
+ Para las funciones API con un argumento `bigint`, los 32 bits superiores están en `pg_locks.classid` y los 32 bits inferiores están en `pg_locks.objid`.
+ Para las funciones de la API con dos argumentos `integer`, el primer argumento es `pg_locks.classid` y el segundo argumento es `pg_locks.objid`.
El valor de `pg_locks.objsubid` indica qué forma de la API se utilizó: `1` significa un argumento `bigint`; `2` significa dos argumentos `integer`.
# Lock:extend
El evento `Lock:extend` se produce cuando un proceso del backend espera bloquear una relación para extenderla mientras otro proceso tiene un bloqueo en esa relación con el mismo propósito.
**Topics**
+ [Versiones del motor admitidas](#wait-event.lockextend.context.supported)
+ [Context](#wait-event.lockextend.context)
+ [Causas probables del aumento de las esperas](#wait-event.lockextend.causes)
+ [Acciones](#wait-event.lockextend.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Context
El evento `Lock:extend` indica que un proceso backend se encuentra a la espera de extender una relación sobre la que otro proceso backend tiene un bloqueo mientras está extendiendo esa relación. Debido a que solo un proceso a la vez puede extender una relación, el sistema genera un evento de espera `Lock:extend`. Las operaciones `INSERT`, `COPY` y `UPDATE` pueden generar este evento.
## Causas probables del aumento de las esperas
Cuando el evento `Lock:extend` aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
**Aumento de las inserciones o actualizaciones concurrentes en la misma tabla **
Puede haber un aumento en el número de sesiones concurrentes con consultas que insertan o actualizan la misma tabla.
**Ancho de banda de red insuficiente**
El ancho de banda de la red en la instancia de base de datos puede ser insuficiente para las necesidades de comunicación del almacenamiento de la carga de trabajo actual. Esto puede contribuir a la latencia del almacenamiento que provoca un aumento de los eventos `Lock:extend`.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Reducir las inserciones y actualizaciones concurrentes en la misma relación](#wait-event.lockextend.actions.action1)
+ [Aumentar el ancho de banda de la red](#wait-event.lockextend.actions.increase-network-bandwidth)
### Reducir las inserciones y actualizaciones concurrentes en la misma relación
En primer lugar, determine si hay un aumento de las métricas `tup_inserted` y `tup_updated` y un aumento de este evento de espera. Si es así, verifique qué relaciones están en alta contención para las operaciones de inserción y actualización. Para determinar esto, consulte la vista `pg_stat_all_tables` para los valores de los campos `n_tup_ins` y `n_tup_upd`. Para obtener información sobre la vista `pg_stat_all_tables`, consulte [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) en la documentación de PostgreSQL.
Para obtener más información acerca de las consultas bloqueadas y no bloqueadas, consulte `pg_stat_activity` como en el siguiente ejemplo:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Después de identificar las relaciones que contribuyen a aumentar los eventos `Lock:extend`, utilice las siguientes técnicas para reducir la contención:
+ Compruebe si puede utilizar el particionamiento para reducir la contención para la misma tabla. Separar las tuplas insertadas o actualizadas en diferentes particiones puede reducir la contención. Para obtener información sobre las particiones, consulte [Administración de las particiones de PostgreSQL con la extensión pg\$1partman](PostgreSQL_Partitions.md).
+ Si el evento de espera se debe principalmente a la actividad de actualización, considere reducir el valor de fillfactor de la relación. Esto puede reducir las solicitudes de nuevos bloques durante la actualización. El fillfactor es un parámetro de almacenamiento para una tabla que determina la cantidad máxima de espacio para empaquetar una página de la tabla. Se expresa como un porcentaje del espacio total de una página. Para más información sobre el parámetro fillfactor, consulte [CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html) en la documentación de PostgreSQL.
**importante**
Recomendamos ampliamente que pruebe su sistema si cambia el fillfactor porque cambiar este valor puede impactar negativamente en el rendimiento, de acuerdo a su carga de trabajo.
### Aumentar el ancho de banda de la red
Para ver si hay un aumento en la latencia de escritura, verifique la métrica `WriteLatency` en CloudWatch. Si lo hay, utilice las métricas `WriteThroughput` y `ReadThroughput` de Amazon CloudWatch para monitorear el tráfico relacionado con el almacenamiento en la instancia de base de datos. Estas métricas pueden ayudarle a determinar si el ancho de banda de la red es suficiente para la actividad de almacenamiento de su carga de trabajo.
Si el ancho de banda de su red no es suficiente, auméntelo. Si la instancia de base de datos alcanza los límites del ancho de banda de la red, la única forma de aumentar el ancho de banda es aumentar el tamaño de la instancia de base de datos.
Para obtener más información acerca de las métricas de CloudWatch, consulte [Métricas de nivel de instancia de Amazon CloudWatch para Amazon RDS](rds-metrics.md#rds-cw-metrics-instance). Para obtener información sobre el rendimiento de la red para cada clase de instancia de base de datos, consulte [Métricas de nivel de instancia de Amazon CloudWatch para Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
# Lock:Relation
El evento `Lock:Relation` ocurre cuando una consulta espera adquirir un bloqueo en una tabla o vista (relación) que se encuentra bloqueada por otra transacción.
**Topics**
+ [Versiones del motor admitidas](#wait-event.lockrelation.context.supported)
+ [Contexto](#wait-event.lockrelation.context)
+ [Causas probables del aumento de las esperas](#wait-event.lockrelation.causes)
+ [Acciones](#wait-event.lockrelation.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Contexto
La mayoría de los comandos de PostgreSQL utilizan implícitamente bloqueos para controlar el acceso concurrente a los datos de las tablas. También puede utilizar estos bloqueos explícitamente en su código de aplicación con el comando `LOCK`. Muchos modos de bloqueo no son compatibles entre sí, y pueden bloquear las transacciones cuando intentan acceder al mismo objeto. Cuando esto sucede, RDS para PostgreSQL genera un evento `Lock:Relation`. Algunos ejemplos comunes son los siguientes:
+ Los bloqueos exclusivos como `ACCESS EXCLUSIVE` pueden bloquear todos los accesos concurrentes. Las operaciones del lenguaje de definición de datos (DDL) como `DROP TABLE`, `TRUNCATE`, `VACUUM FULL` y `CLUSTER` adquieren bloqueos `ACCESS EXCLUSIVE` implícitamente. `ACCESS EXCLUSIVE` es también el modo de bloqueo por defecto para las instrucciones `LOCK TABLE` que no especifican un modo explícitamente.
+ El uso de `CREATE INDEX (without CONCURRENT)` en una tabla entra en conflicto con las instrucciones de lenguaje de manipulación de datos (DML) `UPDATE`, `DELETE` e `INSERT`, que adquieren bloqueos `ROW EXCLUSIVE`.
Para más información sobre los bloqueos a nivel de tabla y los modos de bloqueo conflictivos, consulte [Explicit Locking](https://www.postgresql.org/docs/13/explicit-locking.html) en la documentación de PostgreSQL.
Las consultas y transacciones que se bloquean normalmente se desbloquean de una de las siguientes maneras:
+ Consulta de bloqueo: la aplicación puede cancelar la consulta o el usuario puede terminar el proceso. El motor también puede forzar la finalización de la consulta debido al tiempo de espera de una sesión o a un mecanismo de detección de bloqueos.
+ Transacción bloqueada: una transacción deja de bloquearse cuando se ejecuta una instrucción `ROLLBACK` o `COMMIT`. Las restauraciones también ocurren de forma automática cuando las sesiones se desconectan por un cliente o por problemas de red, o se terminan. Las sesiones se pueden terminar cuando el motor de base de datos se apaga, cuando el sistema se queda sin memoria, etc.
## Causas probables del aumento de las esperas
Cuando el evento `Lock:Relation` se produce con más frecuencia de lo normal, puede indicar un problema de rendimiento. Las causas típicas son las siguientes:
**Aumento de las sesiones concurrentes con bloqueos de tablas en conflicto**
Puede haber un aumento en el número de sesiones concurrentes con consultas que bloquean la misma tabla con modos de bloqueo conflictivos.
**Operaciones de mantenimiento**
Las operaciones de mantenimiento de estado como `VACUUM` y `ANALYZE` pueden aumentar significativamente el número de bloqueos conflictivos. `VACUUM FULL` adquiere un bloqueo `ACCESS EXCLUSIVE`, y `ANALYSE` adquiere un bloqueo `SHARE UPDATE EXCLUSIVE`. Ambos tipos de bloqueos pueden causar un evento de espera `Lock:Relation`. Las operaciones de mantenimiento de datos de la aplicación, como la actualización de una vista materializada, también pueden aumentar las consultas y transacciones bloqueadas.
**Bloqueos en instancias de lectura**
Puede haber un conflicto entre los bloqueos de relaciones que mantienen el escritor y los lectores. En la actualidad, solo los bloqueos de relaciones de `ACCESS EXCLUSIVE` se replican en instancias de lector. Sin embargo, el bloqueo de relaciones `ACCESS EXCLUSIVE` entrará en conflicto con cualquier bloqueo de relaciones `ACCESS SHARE` que mantenga el lector. Esto puede provocar un aumento de los eventos de espera de las relaciones de bloqueo en el lector.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Reducir el impacto de las instrucciones SQL que se bloquean](#wait-event.lockrelation.actions.reduce-blocks)
+ [Minimizar el efecto de las operaciones de mantenimiento](#wait-event.lockrelation.actions.maintenance)
### Reducir el impacto de las instrucciones SQL que se bloquean
Para reducir el impacto de las instrucciones SQL que se bloquean, modifique el código de su aplicación cuando sea posible. A continuación se presentan dos técnicas comunes para reducir los bloqueos:
+ Utilizar la opción `NOWAIT`: algunos comandos SQL, como las instrucciones `SELECT` y `LOCK`, admiten esta opción. La directiva `NOWAIT` cancela la consulta que solicita el bloqueo si éste no puede adquirirse inmediatamente. Esta técnica puede ayudar a evitar que una sesión bloqueada provoque una acumulación de sesiones bloqueadas detrás de ella.
Por ejemplo: Supongamos que la transacción A espera un bloqueo que tiene la transacción B. Ahora, si B solicita un bloqueo en una tabla que está bloqueada por la transacción C, la transacción A podría quedar bloqueada hasta que la transacción C finalice. Pero si la transacción B utiliza un `NOWAIT` cuando solicita el bloqueo en C, puede fallar rápido y asegurar que la transacción A no tenga que esperar de forma indefinida.
+ Utilice `SET lock_timeout`: establezca un valor de `lock_timeout` para limitar el tiempo que una sentencia SQL espera para adquirir un bloqueo en una relación. Si el bloqueo no se adquiere dentro del tiempo de espera especificado, la transacción que solicita el bloqueo se cancela. Establezca este valor en la sesión.
### Minimizar el efecto de las operaciones de mantenimiento
Las operaciones de mantenimiento como `VACUUM` y `ANALYZE` son importantes. Le recomendamos que no las desactive ya que encontrará eventos de espera `Lock:Relation` relacionados con estas operaciones de mantenimiento. Los siguientes enfoques pueden minimizar el efecto de estas operaciones:
+ Ejecute las operaciones de mantenimiento de forma manual durante las horas de menor actividad.
+ Para reducir las esperas de `Lock:Relation` causadas por las tareas de autovacuum, realice los ajustes de autovacuum necesarios. Para obtener información sobre el ajuste de autovacuum, consulte [Trabajo con Autovacuum de PostgreSQL en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) en la *Guía del usuario de Amazon RDS*.
# Lock:transactionid
El evento `Lock:transactionid` se produce cuando una transacción espera un bloqueo a nivel de fila.
**Topics**
+ [Versiones del motor admitidas](#wait-event.locktransactionid.context.supported)
+ [Contexto](#wait-event.locktransactionid.context)
+ [Causas probables del aumento de las esperas](#wait-event.locktransactionid.causes)
+ [Acciones](#wait-event.locktransactionid.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Contexto
El evento `Lock:transactionid` ocurre cuando una transacción intenta adquirir un bloqueo a nivel de fila que ya fue otorgado a una transacción que se está ejecutando al mismo tiempo. La sesión que muestra el evento de espera `Lock:transactionid` se encuentra bloqueada debido a este bloqueo. Después de que la transacción bloqueada termine con una instrucción `COMMIT` o `ROLLBACK`, la transacción bloqueada puede continuar.
La semántica de control de concurrencia multiversión de RDS para PostgreSQL garantiza que los lectores no bloqueen a los escritores y que los escritores no bloqueen a los lectores. ara que se produzcan conflictos en las filas, las transacciones bloqueantes y bloqueadas deben emitir instrucciones conflictivas de los siguientes tipos:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
La instrucción `SELECT … FOR KEY SHARE` es un caso especial. La base de datos utiliza la cláusula `FOR KEY SHARE` para optimizar el rendimiento de la integridad referencial. Un bloqueo en una fila puede bloquear los comandos `INSERT`, `UPDATE` y `DELETE` en otras tablas que hacen referencia a la fila.
## Causas probables del aumento de las esperas
Cuando este evento aparece más de lo normal, la causa suele ser instrucciones `UPDATE`, `SELECT … FOR UPDATE` o `SELECT … FOR KEY SHARE` combinadas con las siguientes condiciones.
**Topics**
+ [Gran concurrencia](#wait-event.locktransactionid.concurrency)
+ [Inactividad en la transacción](#wait-event.locktransactionid.idle)
+ [Transacciones de larga duración](#wait-event.locktransactionid.long-running)
### Gran concurrencia
RDS para PostgreSQL puede utilizar una semántica de bloqueo pormenorizada por filas. La probabilidad de conflictos entre filas aumenta cuando se cumplen las siguientes condiciones:
+ Una carga de trabajo de gran concurrencia compite por las mismas filas.
+ Aumenta la concurrencia.
### Inactividad en la transacción
A veces la columna `pg_stat_activity.state` muestra el valor `idle in transaction`. Este valor aparece para las sesiones que iniciaron una transacción, pero aún no han emitido un `COMMIT` o `ROLLBACK`. Si el valor de `pg_stat_activity.state` no se encuentra `active`, la consulta mostrada en `pg_stat_activity` es la más reciente en terminar de ejecutarse. La sesión de bloqueo no se encuentra en proceso activo de una consulta porque una transacción abierta está manteniendo un bloqueo.
Si una transacción inactiva adquirió un bloqueo entre filas, puede impedir que otras sesiones lo adquieran. Esta condición conduce a la aparición frecuente del evento de espera `Lock:transactionid`. Para diagnosticar el problema, examine la salida de `pg_stat_activity` y `pg_locks`.
### Transacciones de larga duración
Las transacciones que se ejecutan durante mucho tiempo obtienen bloqueos durante mucho tiempo. Estos bloqueos de larga duración pueden bloquear la ejecución de otras transacciones.
## Acciones
El bloqueo de filas es un conflicto entre las instrucciones `UPDATE`, `SELECT … FOR UPDATE`, o `SELECT … FOR KEY SHARE`. Antes de intentar una solución, averigüe cuándo se están ejecutando estas instrucciones en la misma fila. Utilice esta información para elegir una estrategia descrita en las siguientes secciones.
**Topics**
+ [Responder a la alta concurrencia](#wait-event.locktransactionid.actions.problem)
+ [Responder a las transacciones inactivas](#wait-event.locktransactionid.actions.find-blocker)
+ [Responder a las transacciones de larga duración](#wait-event.locktransactionid.actions.concurrency)
### Responder a la alta concurrencia
Si el problema es la concurrencia, pruebe una de las siguientes técnicas:
+ Reduzca la concurrencia en la aplicación. Por ejemplo, disminuya el número de sesiones activas.
+ Implemente un grupo de conexiones. Para saber cómo agrupar conexiones con RDS Proxy, consulte [Amazon RDS Proxy ](rds-proxy.md).
+ Diseñe la aplicación o el modelo de datos para evitar las instrucciones `UPDATE` y `SELECT … FOR UPDATE` en conflicto. También puede disminuir el número de claves foráneas a las que se accede mediante instrucciones `SELECT … FOR KEY SHARE`.
### Responder a las transacciones inactivas
Si `pg_stat_activity.state` muestra una transacción `idle in transaction`, utilice las siguientes estrategias:
+ Active la confirmación automática siempre que sea posible. Este enfoque evita que las transacciones bloqueen otras transacciones mientras esperan un `COMMIT` o `ROLLBACK`.
+ Busque rutas de código en las que falten `COMMIT`, `ROLLBACK` o `END`.
+ Asegúrese de que la lógica de manejo de excepciones en su aplicación siempre tiene una ruta hacia válido `end of transaction`.
+ Asegúrese de que su aplicación procesa los resultados de la consulta después de finalizar la transacción con `COMMIT` o `ROLLBACK`.
### Responder a las transacciones de larga duración
Si las transacciones de larga duración provocan la aparición frecuente de `Lock:transactionid`, pruebe las siguientes estrategias:
+ Mantenga los bloqueos de filas fuera de las transacciones de larga duración.
+ Limite la longitud de las consultas mediante la implementación de confirmación automática siempre que sea posible.
# Lock:tuple
El evento `Lock:tuple` se produce cuando un proceso backend espera adquirir un bloqueo sobre una tupla.
**Topics**
+ [Versiones del motor admitidas](#wait-event.locktuple.context.supported)
+ [Context](#wait-event.locktuple.context)
+ [Causas probables del aumento de las esperas](#wait-event.locktuple.causes)
+ [Acciones](#wait-event.locktuple.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Context
El evento `Lock:tuple` indica que un backend espera adquirir un bloqueo sobre una tupla mientras otro backend mantiene un bloqueo conflictivo sobre la misma tupla. La siguiente tabla ilustra un escenario en el que las sesiones generan el evento `Lock:tuple`.
| Tiempo | Sesión 1 | Sesión 2 | Sesión 3 |
| --- | --- | --- | --- |
| t1 | Inicia una transacción. | | |
| t2 | Actualiza la fila 1. | | |
| t3 | | Actualiza la fila 1. La sesión adquiere un bloqueo exclusivo sobre la tupla y luego espera a que la sesión 1 libere el bloqueo mediante la confirmación o reversión. | |
| t4 | | | Actualiza la fila 1. La sesión espera a que la sesión 2 libere el bloqueo exclusivo en la tupla. |
También puede simular este evento de espera con la herramienta de punto de referencia `pgbench`. Configure un alto número de sesiones concurrentes para actualizar la misma fila en una tabla con un archivo SQL personalizado.
Para obtener más información sobre los modos de bloqueo conflictivos, consulte [E](https://www.postgresql.org/docs/current/explicit-locking.html) en la documentación de PostgreSQL. Para más información sobre `pgbench`, consulte [pgbench](https://www.postgresql.org/docs/current/pgbench.html) en la documentación de PostgreSQL.
## Causas probables del aumento de las esperas
Cuando este evento aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
+ Un gran número de sesiones concurrentes están intentando adquirir un bloqueo conflictivo para la misma tupla al ejecutar instrucciones `UPDATE` o `DELETE`.
+ Las sesiones altamente concurrentes se encuentran en ejecución con una instrucción `SELECT` que utiliza los modos de bloqueo `FOR UPDATE` o `FOR NO KEY UPDATE`.
+ Varios factores hacen que la aplicación o los grupos de conexión abran más sesiones para ejecutar las mismas operaciones. A medida que nuevas sesiones intentan modificar las mismas filas, la carga de la base de datos puede aumentar y puede aparecer `Lock:tuple`.
Para más información, consulte [Row-Level Locks](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS) en la documentación de PostgreSQL.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Investigue la lógica de su aplicación](#wait-event.locktuple.actions.problem)
+ [Encontrar la sesión bloqueadora](#wait-event.locktuple.actions.find-blocker)
+ [Reducir la concurrencia cuando es alta](#wait-event.locktuple.actions.concurrency)
+ [Solucionar los cuellos de botella](#wait-event.locktuple.actions.bottlenecks)
### Investigue la lógica de su aplicación
Verifique si una sesión del bloqueador se encuentra en el estado `idle in transaction` por mucho tiempo. Si es así, considere la posibilidad de finalizar la sesión del bloqueador como una solución a corto plazo. Puede utilizar la función `pg_terminate_backend`. Para más información sobre esta función, consulte [Server Signaling Functions](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL) en la documentación de PostgreSQL.
Para una solución a largo plazo, haga lo siguiente:
+ Ajuste la lógica de la aplicación.
+ Utilice el parámetro `idle_in_transaction_session_timeout`. Este parámetro finaliza cualquier sesión con una transacción abierta que haya estado inactiva durante más tiempo del especificado. Para más información, consulte [Client Connection Defaults](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) en la documentación de PostgreSQL.
+ Utilice la confirmación automática en la medida de lo posible. Para más información, consulte [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html) en la documentación de PostgreSQL.
### Encontrar la sesión bloqueadora
Mientras se produce el evento de espera `Lock:tuple`, identifique el bloqueador y la sesión bloqueada mediante la búsqueda de los bloqueos que dependen unos de otros. Para más información, consulte la [Información sobre dependencia de bloqueos](https://wiki.postgresql.org/wiki/Lock_dependency_information) en el wiki de PostgreSQL.
El siguiente ejemplo muestra todas las sesiones, con un filtro `tuple` y ordenadas por `wait_time`.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
### Reducir la concurrencia cuando es alta
El evento `Lock:tuple` puede producirse de manera frecuente, especialmente en un momento de carga de trabajo elevada. En esta situación, considere reducir la alta concurrencia para las filas muy ocupadas. A menudo, solo unas pocas filas controlan una cola o la lógica booleana, lo que hace que estas filas estén muy ocupadas.
Puede reducir la concurrencia mediante el uso de diferentes enfoques basados en los requisitos de la empresa, lógica de la aplicación y tipo de carga de trabajo. Por ejemplo, puede hacer lo siguiente:
+ Rediseñar la lógica de la tabla y los datos para reducir la alta concurrencia.
+ Cambiar la lógica de la aplicación para reducir la alta concurrencia entre filas.
+ Aprovechar y rediseñar las consultas con bloqueos entre filas.
+ Utilizar la cláusula `NOWAIT` con operaciones de reintento.
+ Considerar el uso de control de concurrencia optimista y de lógica de bloqueo híbrida.
+ Considerar la posibilidad de cambiar el nivel de aislamiento de la base de datos.
### Solucionar los cuellos de botella
La `Lock:tuple` producirse con cuellos de botella, como el agotamiento de la CPU o el uso máximo del ancho de banda de Amazon EBS. Para reducir los cuellos de botella, considere los siguientes enfoques:
+ Escalar verticalmente el tipo de clase de instancia.
+ Optimizar las consultas que consumen muchos recursos.
+ Cambiar la lógica de la aplicación.
+ Archivar los datos a los que rara vez se accede.
# LWLock:BufferMapping (LWLock:buffer\$1mapping)
Este evento se produce cuando una sesión espera asociar un bloque de datos con un búfer en el grupo de búferes compartidos.
**nota**
Para la versión 13 y posteriores de RDS para PostgreSQL, el nombre de este evento es `LWLock:BufferMapping`. Para la versión 12 y posteriores de RDS para PostgreSQL, el nombre de este evento es `LWLock:buffer_mapping`.
**Topics**
+ [Versiones del motor admitidas](#wait-event.lwl-buffer-mapping.context.supported)
+ [Contexto](#wait-event.lwl-buffer-mapping.context)
+ [Causas](#wait-event.lwl-buffer-mapping.causes)
+ [Acciones](#wait-event.lwl-buffer-mapping.actions)
## Versiones del motor admitidas
La información del evento de espera es relevante para RDS para PostgreSQL versión 9.6 y posteriores.
## Contexto
El *grupo de búferes compartidos* es un área de memoria de PostgreSQL que contiene todas las páginas que utilizan o utilizaban los procesos. Cuando un proceso necesita una página, lee la página en el grupo de búferes compartidos. El parámetro `shared_buffers` establece el tamaño del búfer compartido y reserva un área de memoria para almacenar las páginas de tablas e índices. Si cambia este parámetro, asegúrese de reiniciar la base de datos.
El evento de espera `LWLock:buffer_mapping` ocurre en los siguientes escenarios:
+ Un proceso busca una página en la tabla de búferes y adquiere un bloqueo de asignación de búferes compartidos.
+ Un proceso carga una página en el grupo de búferes y adquiere un bloqueo de asignación de búferes exclusivo.
+ Un proceso elimina una página del grupo y adquiere un bloqueo de asignación de búferes exclusivo.
## Causas
Cuando este evento aparece más de lo normal, lo que puede indicar un problema de rendimiento, la base de datos entra y sale del grupo de búferes compartidos. Las causas típicas son las siguientes:
+ Consultas grandes
+ Índices y tablas sobrecargados
+ Escaneos completos de tablas
+ Un tamaño del grupo compartido menor que el conjunto de trabajo
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Monitorear las métricas relacionadas con el buffer](#wait-event.lwl-buffer-mapping.actions.monitor-metrics)
+ [Evaluar la estrategia de indexación](#wait-event.lwl-buffer-mapping.actions.indexes)
+ [Reducir el número de búferes que deben ser asignados rápidamente](#wait-event.lwl-buffer-mapping.actions.buffers)
### Monitorear las métricas relacionadas con el buffer
Cuando las esperas de `LWLock:buffer_mapping` se disparan, hay que investigar la tasa de aciertos del búfer. Puede utilizar estas métricas para comprender mejor lo que ocurre en la caché del búfer. Examina las siguientes métricas:
`blks_hit`
Esta métrica del contador de Información sobre rendimiento indica el número de bloques que se recuperaron del grupo de búferes compartidos. Después de que aparezca el evento de espera `LWLock:buffer_mapping`, se puede observar un pico en `blks_hit`.
`blks_read`
Esta métrica del contador de Información sobre rendimiento indica el número de bloques que requirieron E/S para leerse en el grupo de búferes compartidos. Puede observar un pico en `blks_read` en el periodo previo al evento de espera `LWLock:buffer_mapping`.
### Evaluar la estrategia de indexación
Para confirmar que la estrategia de indexación no disminuye el rendimiento, verifique lo siguiente:
Sobrecarga del índice
Asegúrese de que el índice y la sobrecarga de la tabla no provocan la lectura de páginas innecesarias en el búfer compartido. Si las tablas contienen filas que no se utilizan, considere la posibilidad de archivar los datos y eliminar las filas de las tablas. A continuación, puede reconstruir los índices para las tablas redimensionadas.
Índices para consultas de uso frecuente
Para determinar si cuenta con los índices óptimos, monitoree las métricas del motor de base de datos en Información sobre rendimiento. La métrica `tup_returned` muestra el número de filas leídas. La métrica `tup_fetched` muestra el número de filas devueltas al cliente. Si `tup_returned` es mucho mayor que `tup_fetched`, es posible que los datos no estén bien indexados. Además, es posible que las estadísticas de la tabla no se encuentren actualizadas.
### Reducir el número de búferes que deben ser asignados rápidamente
Para reducir los eventos de espera de `LWLock:buffer_mapping`, intente reducir el número de búferes que se deben asignar de forma rápida. Una estrategia es hacer operaciones por lotes más pequeños. Se pueden conseguir lotes más pequeños por medio de la partición de las tablas.
# LWLock:BufferIO (IPC:BufferIO)
El evento `LWLock:BufferIO` ocurre cuando RDS para PostgreSQL espera que otros procesos terminen sus operaciones de entrada/salida (E/S) cuando intentan acceder a una página de forma simultánea. Su propósito es que la misma página se lea en el búfer compartido.
**Topics**
+ [Versiones del motor relevantes](#wait-event.lwlockbufferio.context.supported)
+ [Context](#wait-event.lwlockbufferio.context)
+ [Causas](#wait-event.lwlockbufferio.causes)
+ [Acciones](#wait-event.lwlockbufferio.actions)
## Versiones del motor relevantes
Esta información de eventos de espera es relevante para todas las versiones de RDS para PostgreSQL. Para RDS para PostgreSQL 12 y versiones anteriores, este evento de espera se denomina lwlock:buffer\$1io, mientras que en la versión 13 de RDS para PostgreSQL se denomina lwlock:bufferio. A partir de la versión 14 de RDS para PostgreSQL, el evento de espera BufferIO se movió de tipo de evento de espera `LWLock` a `IPC` (IPC:bufferIO).
## Context
Cada búfer compartido tiene un bloqueo de E/S que está asociado con el evento de espera `LWLock:BufferIO`, cada vez que un bloque (o una página) se tiene que recuperar fuera del grupo de búferes compartidos.
Este bloqueo se utiliza para manejar múltiples sesiones que requieren acceso al mismo bloque. Este bloque se tiene que leer desde fuera del grupo de búferes compartidos, que se define con el parámetro `shared_buffers`.
Tan pronto como la página se lee dentro del grupo de búferes compartidos, el bloqueo `LWLock:BufferIO` se libera.
**nota**
El evento de espera `LWLock:BufferIO` precede al evento de espera [IO:DataFileRead](wait-event.iodatafileread.md). El evento de espera `IO:DataFileRead` se produce mientras se leen datos del almacenamiento.
Para obtener más información sobre los bloqueos ligeros, consulte [Información general sobre los bloqueos](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Causas
Las causas más comunes para que el evento `LWLock:BufferIO` aparezca en el máximo de esperas son las siguientes:
+ Varios backends o conexiones que intentan acceder a la misma página que también tiene pendiente una operación de E/S
+ La relación entre el tamaño del grupo de búferes compartidos (definido por el parámetro `shared_buffers`) y el número de búferes que necesita la carga de trabajo actual
+ El tamaño del grupo de búferes compartidos no está bien equilibrado con el número de páginas que se desalojan por otras operaciones
+ Índices grandes o sobrecargados que requieren que el motor lea más páginas de las necesarias en el grupo de búferes compartidos
+ La falta de índices obliga al motor de la base de datos a leer más páginas de las necesarias en las tablas
+ Puntos de control que se producen con demasiada frecuencia o que necesitan vaciar demasiadas páginas modificadas
+ Picos repentinos de conexiones a la base de datos que intentan hacer operaciones en la misma página
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera:
+ Observe las métricas de Amazon CloudWatch en busca de una correlación entre los descensos bruscos de los eventos de espera `BufferCacheHitRatio` y `LWLock:BufferIO`. Este efecto a veces significa que tiene una configuración de búferes compartidos pequeña. Puede que tenga que aumentarla o escalar verticalmente la clase de instancia de base de datos. Puede dividir su carga de trabajo en más nodos de lectura.
+ Ajuste `max_wal_size` y `checkpoint_timeout` en función del tiempo de pico de su carga de trabajo si ve que `LWLock:BufferIO` coincide con las caídas de la métrica `BufferCacheHitRatio`. A continuación, identifique qué consulta puede ser la causa.
+ Verifique si tiene índices sin utilizar y elimínelos.
+ Utilice tablas particionadas (que también tengan índices particionados). Esto ayuda a mantener un bajo nivel de reordenación de índices y reduce su impacto.
+ Evite indexar columnas innecesariamente.
+ Evite los picos repentinos de conexión a la base de datos, utilice un grupo de conexiones.
+ Limite el número máximo de conexiones a la base de datos como práctica recomendada.
# LWLock:buffer\$1content (BufferContent)
El evento `LWLock:buffer_content` ocurre cuando una sesión espera para leer o escribir una página de datos en memoria mientras otra sesión tiene esa página bloqueada para escribir. En RDS para PostgreSQL 13 y versiones posteriores, este evento de espera se llama `BufferContent`.
**Topics**
+ [Versiones del motor admitidas](#wait-event.lwlockbuffercontent.context.supported)
+ [Context](#wait-event.lwlockbuffercontent.context)
+ [Causas probables del aumento de las esperas](#wait-event.lwlockbuffercontent.causes)
+ [Acciones](#wait-event.lwlockbuffercontent.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Context
Para leer o manipular datos, PostgreSQL accede a ellos a través de búferes de memoria compartida. Para leer del búfer, un proceso obtiene un bloqueo ligero (LWLock) sobre el contenido del búfer en modo compartido. Para escribir en el búfer, obtiene ese bloqueo en modo exclusivo. Los bloqueos compartidos permiten a otros procesos adquirir simultáneamente bloqueos compartidos sobre ese contenido. Los bloqueos exclusivos impiden que otros procesos obtengan cualquier tipo de bloqueo sobre él.
El evento `LWLock:buffer_content` (`BufferContent`) indica que varios procesos intentan obtener un bloqueo sobre el contenido de un búfer específico.
## Causas probables del aumento de las esperas
Cuando el evento `LWLock:buffer_content` (`BufferContent`) aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
**Aumento de las actualizaciones simultáneas de los mismos datos**
Puede haber un aumento en el número de sesiones concurrentes con consultas que actualizan el mismo contenido del búfer. Esta contención puede ser más pronunciada en tablas con muchos índices.
**Los datos de carga de trabajo no están en la memoria**
Cuando los datos que la carga de trabajo activa está procesando no están en memoria, estos eventos de espera pueden aumentar. Este efecto se debe a que los procesos que mantienen bloqueos pueden mantenerlos durante más tiempo mientras hacen operaciones de E/S en disco.
**Uso excesivo de restricciones de clave externa**
Las restricciones de clave externa pueden aumentar el tiempo que un proceso mantiene un bloqueo de contenido de búfer. Este efecto se debe a que las operaciones de lectura requieren un bloqueo de contenido de búfer compartido en la clave referenciada mientras se actualiza dicha clave.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera. Puede identificar los eventos `LWLock:buffer_content` (`BufferContent`) mediante Información sobre rendimiento de Amazon RDS o consultar la vista `pg_stat_activity`.
**Topics**
+ [Mejorar la eficiencia en memoria](#wait-event.lwlockbuffercontent.actions.in-memory)
+ [Reducir el uso de restricciones de clave externa](#wait-event.lwlockbuffercontent.actions.foreignkey)
+ [Eliminar los índices que no se utilizan](#wait-event.lwlockbuffercontent.actions.indexes)
+ [Aumentar el tamaño de la memoria caché al utilizar secuencias](#wait-event.lwlockbuffercontent.actions.sequences)
### Mejorar la eficiencia en memoria
Para aumentar la posibilidad de que los datos de la carga de trabajo activa estén en memoria, particione las tablas o escale verticalmente su clase de instancia. Para obtener información acerca de las clases de instancia de base de datos, consulte [Clases de instancia de base de datos de ](Concepts.DBInstanceClass.md).
### Reducir el uso de restricciones de clave externa
Examine las cargas de trabajo que experimentan un elevado número de eventos de espera `LWLock:buffer_content` (`BufferContent`) para comprobar el uso de las restricciones de clave externa. Elimine las restricciones de clave externa innecesarias.
### Eliminar los índices que no se utilizan
Para las cargas de trabajo que experimentan un gran número de eventos de espera `LWLock:buffer_content` (`BufferContent`), identifique los índices que no se utilizan y elimínelos.
### Aumentar el tamaño de la memoria caché al utilizar secuencias
Si las tablas usan secuencias, aumente el tamaño de la memoria caché para eliminar la contención en las páginas de secuencias y las páginas de índice. Cada secuencia es una página individual en la memoria compartida. La memoria caché predefinida es por conexión. Es posible que esto no sea suficiente para gestionar la carga de trabajo cuando muchas sesiones simultáneas reciben un valor de secuencia.
# LWLock:lock\$1manager (LWLock:lockmanager)
Este evento ocurre cuando el motor de RDS para PostgreSQL mantiene el área de memoria del bloqueo compartido para asignar, verificar y desasignar un bloqueo cuando no es posible un bloqueo de ruta rápida.
**Topics**
+ [Versiones del motor admitidas](#wait-event.lw-lock-manager.context.supported)
+ [Contexto](#wait-event.lw-lock-manager.context)
+ [Causas probables del aumento de las esperas](#wait-event.lw-lock-manager.causes)
+ [Acciones](#wait-event.lw-lock-manager.actions)
## Versiones del motor admitidas
La información del evento de espera es relevante para RDS para PostgreSQL versión 9.6 y posteriores. Para las versiones de RDS para PostgreSQL anteriores a la 13, el nombre de este evento de espera es `LWLock:lock_manager`. Para la versión 13 de RDS para PostgreSQL y posteriores, el nombre de este evento de espera es `LWLock:lockmanager`.
## Contexto
Cuando se emite una instrucción SQL, RDS para PostgreSQL registra bloqueos para proteger la estructura, los datos y la integridad de la base de datos durante las operaciones simultáneas. El motor puede lograr este objetivo con un bloqueo de ruta rápido o con un bloqueo de ruta que no es rápido. Un bloqueo de ruta que no es rápido es más caro y crea más sobrecarga que un bloqueo de ruta rápido.
### Bloqueo rápido de la ruta
Para reducir la sobrecarga de los bloqueos que se toman y liberan con frecuencia, pero que rara vez entran en conflicto, los procesos del backend pueden utilizar el bloqueo de ruta rápido. La base de datos utiliza este mecanismo para los bloqueos que cumplen los siguientes criterios:
+ Utilizan el método de bloqueo DEFAULT.
+ Representan un bloqueo en una relación de la base de datos y no en una relación compartida.
+ Son bloqueos débiles que probablemente no entren en conflicto.
+ El motor puede verificar rápidamente que no pueden existir bloqueos conflictivos.
El motor no puede utilizar el bloqueo de ruta rápida cuando se cumple alguna de las siguientes condiciones:
+ El bloqueo no cumple los criterios anteriores.
+ No hay más ranuras disponibles para el proceso de backend.
Para ajustar las consultas para que se bloqueen rápidamente, puede utilizar la siguiente consulta.
```
SELECT count(*), pid, mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 4,3,2
ORDER BY pid, mode;
count | pid | mode | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock | t
```
La siguiente consulta muestra solo el total de la base de datos.
```
SELECT count(*), mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 3,2
ORDER BY mode,1;
count | mode | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock | t
(3 rows)
```
Para más información sobre el bloqueo de ruta rápida, consulte [fast path](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) en el README del administrador de bloqueos de PostgreSQL y [pg-locks](https://www.postgresql.org/docs/9.3/view-pg-locks.html#AEN98195) en la documentación de PostgreSQL.
### Ejemplo de un problema de escalado para el administrador de bloqueos
En este ejemplo, una tabla con el nombre `purchases` almacena cinco años de datos, particionados por día. Cada partición tiene dos índices. Se produce la siguiente secuencia de eventos:
1. Se consultan los datos de muchos días, lo que requiere que la base de datos lea muchas particiones.
1. La base de datos crea una entrada de bloqueo para cada partición. Si los índices de las particiones forman parte de la ruta de acceso del optimizador, la base de datos también crea una entrada de bloqueo para ellos.
1. Cuando el número de entradas de bloqueo solicitadas para el mismo proceso backend es superior a 16, que es el valor `FP_LOCK_SLOTS_PER_BACKEND`, el administrador de bloqueos utiliza el método de bloqueo de ruta no rápida.
Las aplicaciones modernas pueden tener cientos de sesiones. Si las sesiones simultáneas consultan la base de datos principal sin una poda adecuada de las particiones, la base de datos puede crear cientos o incluso miles de bloqueos de ruta no rápida. Normalmente, cuando esta simultaneidad es mayor que el número de vCPU, aparece el evento de espera `LWLock:lock_manager`.
**nota**
El evento de espera `LWLock:lock_manager` no está relacionado con el número de particiones o índices en un esquema de base de datos. En cambio, está relacionado con el número de bloqueos de rutas no rápidas que la base de datos debe controlar.
## Causas probables del aumento de las esperas
Cuando el evento de espera `LWLock:lock_manager` ocurre más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas más probables de los picos repentinos son las siguientes:
+ Las sesiones activas simultáneas ejecutan consultas que no utilizan bloqueos de ruta rápida. Estas sesiones también exceden el máximo de vCPU.
+ Un gran número de sesiones activas simultáneas acceden a una tabla con muchas particiones. Cada partición tiene múltiples índices.
+ La base de datos está experimentando una tormenta de conexiones. De forma predeterminada, algunas aplicaciones y software de grupo de conexiones crean más conexiones cuando la base de datos es lenta. Esta práctica empeora el problema. Ajuste el software de grupo de conexiones para que no se produzcan tormentas de conexiones.
+ Un gran número de sesiones consultan una tabla principal sin borrar particiones.
+ Un lenguaje de definición de datos (DDL), un lenguaje de manipulación de datos (DML) o un comando de mantenimiento bloquea exclusivamente una relación ocupada o tuplas a las que se accede o modifica con frecuencia.
## Acciones
Si se produce el evento de espera `CPU`, no indica necesariamente un problema de rendimiento. Responda a este evento solo cuando el rendimiento disminuya y este evento de espera domine la carga de la base de datos.
**Topics**
+ [Utilizar la poda de particiones](#wait-event.lw-lock-manager.actions.pruning)
+ [Eliminar índices innecesarios](#wait-event.lw-lock-manager.actions.indexes)
+ [Ajustar sus consultas para el bloqueo rápido de rutas](#wait-event.lw-lock-manager.actions.tuning)
+ [Ajustar otros eventos de espera](#wait-event.lw-lock-manager.actions.other-waits)
+ [Reducir los cuellos de botella del hardware](#wait-event.lw-lock-manager.actions.hw-bottlenecks)
+ [Utilizar un grupo de conexiones](#wait-event.lw-lock-manager.actions.pooler)
+ [Actualización de la versión de RDS para PostgreSQL](#wait-event.lw-lock-manager.actions.pg-version)
### Utilizar la poda de particiones
La *poda de particiones* es una estrategia de optimización de consultas para tablas partidas de forma declarativa que excluye las particiones innecesarias de los escaneos de tablas, lo que mejora el rendimiento. La poda de particiones está activada de forma predeterminada. Si está desactivada, actívela de la siguiente manera.
```
SET enable_partition_pruning = on;
```
Las consultas pueden aprovechar la poda de particiones cuando la cláusula `WHERE` contiene la columna que se utiliza para la partición. Para más información, consulte [Partition Pruningc](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) en la documentación de PostgreSQL.
### Eliminar índices innecesarios
Es posible que la base de datos contenga índices que no se utilicen o que se utilicen muy poco. Si es así, considere eliminarlos. Haga una de estas dos operaciones:
+ Aprenda a encontrar índices innecesarios al leer [Índices no utilizados](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) en el wiki de PostgreSQL.
+ Ejecute PG Collector. Este script SQL recopila información de la base de datos y la presenta en un informe HTML consolidado. Verifique la sección “Índices no utilizados”. Para más información, consulte [pg-collector](https://github.com/awslabs/pg-collector) en el repositorio GitHub de AWS Labs.
### Ajustar sus consultas para el bloqueo rápido de rutas
Para averiguar si las consultas utilizan el bloqueo de ruta rápida, consulte la columna `fastpath` en la tabla `pg_locks`. Si las consultas no utilizan el bloqueo de ruta rápida, intente reducir el número de relaciones por consulta a menos de 16.
### Ajustar otros eventos de espera
Si `LWLock:lock_manager` es el primero o el segundo en la lista de esperas principales, verifique si los siguientes eventos de espera también aparecen en la lista:
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
Si los eventos anteriores aparecen en primer lugar en la lista, considere la posibilidad de ajustar estos eventos de espera en primer lugar. Estos eventos pueden ser un controlador para `LWLock:lock_manager`.
### Reducir los cuellos de botella del hardware
Es posible que tenga un cuello de botella en el hardware, como el agotamiento de la CPU o el uso máximo de su ancho de banda de Amazon EBS. En estos casos, considere la posibilidad de reducir los cuellos de botella de hardware. Considere las siguientes acciones:
+ Escalar verticalmente la clase de instancia.
+ Optimizar las consultas que consumen grandes cantidades de CPU y memoria.
+ Cambiar la lógica de su aplicación.
+ Archivar los datos.
Para más información sobre la CPU, memoria y ancho de banda de red de EBS, consulte [Tipos de instancias de Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Utilizar un grupo de conexiones
Si el número total de conexiones activas supera el máximo de vCPU, más procesos del sistema operativo requieren CPU de lo que su tipo de instancia puede admitir. En este caso, considere la posibilidad de utilizar o ajustar un grupo de conexiones. Para más información sobre las vCPU de su tipo de instancia, consulte [Tipos de instancias de Amazon RDS](https://aws.amazon.com/rds/instance-types/).
Para más información sobre la agrupación de conexiones, consulte los siguientes recursos:
+ [Amazon RDS Proxy ](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Connection Pools and Data Sources](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) en la *documentación de PostgreSQL*
### Actualización de la versión de RDS para PostgreSQL
Si la versión actual de RDS para PostgreSQL es inferior a la 12, actualice a la versión 12 o posterior. Las versiones 12 y posteriores de PostgreSQL tienen un mecanismo de partición mejorado. Para más información sobre la versión 12, consulte las [Notas de la versión 12.0 de PostgreSQL]( https://www.postgresql.org/docs/release/12.0/). Para más información sobre la actualización de RDS para PostgreSQL, consulte [Actualizaciones del motor de base de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md).
# LWLock:pg\$1stat\$1statements
El evento de espera LWLock:pg\$1stat\$1statements se produce cuando la extensión `pg_stat_statements` toma un bloqueo exclusivo en la tabla hash que rastrea las instrucciones SQL. Esto ocurre en las siguientes situaciones:
+ Cuando el número de instrucciones rastreadas alcanza el valor del parámetro `pg_stat_statements.max` configurado y es necesario dejar espacio para más entradas, la extensión realiza una clasificación del número de llamadas, elimina el 5 % de las instrucciones menos ejecutadas y vuelve a rellenar el hash con las entradas restantes.
+ Cuando `pg_stat_statements` realiza una operación de `garbage collection` en el archivo `pgss_query_texts.stat` del disco y lo vuelve a escribir.
**Topics**
+ [Versiones del motor admitidas](#apg-rpg-lwlockpgstat.supported)
+ [Contexto](#apg-rpg-lwlockpgstat.context)
+ [Causas probables del aumento de las esperas](#apg-rpg-lwlockpgstat.causes)
+ [Acciones](#apg-rpg-lwlockpgstat.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Contexto
**Descripción de la extensión pg\$1stat\$1statements**: la extensión pg\$1stat\$1statements rastrea las estadísticas de ejecución de instrucción SQL en una tabla hash. La extensión rastrea las instrucciones SQL hasta el límite definido por el parámetro `pg_stat_statements.max`. Este parámetro determina el número máximo de instrucciones que se pueden rastrear, lo que corresponde al número máximo de filas en la vista de pg\$1stat\$1statements.
**Persistencia de las estadísticas de las instrucciones**: la extensión mantiene las estadísticas de las instrucciones a través de reinicios de instancia mediante:
+ Escritura de datos en un archivo llamado pg\$1stat\$1statements.stat
+ Uso del parámetro pg\$1stat\$1statements.save para controlar el comportamiento de persistencia
Cuando pg\$1stat\$1statements.save se establece en:
+ activado (predeterminado): las estadísticas se guardan al apagar el servidor y se vuelven a cargar al iniciar el servidor
+ desactivado (predeterminado): las estadísticas no se guardan al apagar el servidor ni se vuelven a cargar al iniciar el servidor
**Almacenamiento de texto de consulta**: la extensión almacena el texto de las consultas rastreadas en un archivo denominado `pgss_query_texts.stat`. Este archivo puede crecer hasta duplicar el tamaño medio de todas las instrucciones SQL rastreadas antes de que se produzca la recopilación de elementos no utilizados. La extensión requiere un bloqueo exclusivo en la tabla de hash durante las operaciones de limpieza y reescritura del archivo `pgss_query_texts.stat`.
**Proceso de desasignación de instrucciones**: cuando el número de instrucciones rastreadas alcanza el límite `pg_stat_statements.max` y es necesario realizar un seguimiento de las nuevas, la extensión:
+ Toma un bloqueo exclusivo (LWLock:pg\$1stat\$1statements) en la tabla de hash.
+ Carga los datos existentes en la memoria local.
+ Realiza una clasificación rápida en función del número de llamadas.
+ Elimina las instrucciones menos solicitadas (el 5 % inferior).
+ Vuelve a rellenar la tabla hash con las entradas restantes.
**Supervisión de la desasignación de instrucciones**: en PostgreSQL 14 y versiones posteriores, puede supervisar la desasignación de las instrucciones mediante la vista pg\$1stat\$1statements\$1info. Esta vista incluye una columna dealloc que muestra cuántas veces se desasignaron las instrucciones para dejar espacio a otras nuevas
Si la desasignación de las instrucciones se produce con frecuencia, se realizará con más frecuencia la recopilación de elementos no utilizados del archivo `pgss_query_texts.stat` en el disco.
## Causas probables del aumento de las esperas
Entre las causas típicas del aumento de las esperas de `LWLock:pg_stat_statements` se incluyen las siguientes:
+ Un aumento en el número de consultas únicas utilizadas por la aplicación.
+ El valor del parámetro `pg_stat_statements.max` es pequeño en comparación con el número de consultas únicas que se utilizan.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera. Puede identificar los eventos de `LWLock:pg_stat_statements` mediante Información de rendimiento de Amazon RDS o consultando la vista de `pg_stat_activity`.
Ajuste los siguientes parámetros `pg_stat_statements` para controlar el comportamiento de seguimiento y reducir los eventos de espera de las instrucciones LWLock:pg\$1stat\$1statements.
**Topics**
+ [Desactivación del parámetro pg\$1stat\$1statements.track](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [Aumento del parámetro pg\$1stat\$1statements.max](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [Desactivación del parámetro pg\$1stat\$1statements.track\$1utility](#apg-rpg-lwlockpgstat.actions.disableutility)
### Desactivación del parámetro pg\$1stat\$1statements.track
Si el evento de espera de LWLock:pg\$1stat\$1statements está afectando negativamente al rendimiento de la base de datos y se requiere una solución rápida antes de continuar con el análisis de la vista de `pg_stat_statements` para identificar la causa raíz, el parámetro `pg_stat_statements.track` se puede desactivar configurándolo en `none`. Esto desactivará la recopilación de estadísticas de instrucciones.
### Aumento del parámetro pg\$1stat\$1statements.max
Para reducir la desasignación y minimizar la recopilación de elementos no utilizados del archivo `pgss_query_texts.stat` en el disco, aumente el valor del parámetro `pg_stat_statements.max`. El valor predeterminado es `5,000`.
**nota**
El parámetro `pg_stat_statements.max` está estático. Debe reiniciar la instancia de base de datos para aplicar los cambios a este parámetro.
### Desactivación del parámetro pg\$1stat\$1statements.track\$1utility
Puede analizar la vista de pg\$1stat\$1statements para determinar qué comandos de utilidad consumen la mayor cantidad de recursos rastreados por `pg_stat_statements`.
El parámetro `pg_stat_statements.track_utility` controla si el módulo realiza un seguimiento de los comandos de utilidad, que incluyen todos los comandos excepto SELECT, INSERT, UPDATE, DELETE y MERGE. Este parámetro está establecido en de forma predeterminada `on`.
Por ejemplo, cuando la aplicación utiliza muchas consultas de puntos de guardado, que son intrínsecamente únicas, puede aumentar la desasignación de instrucciones. Para abordar este problema, puede desactivar el parámetro `pg_stat_statements.track_utility` para impedir que `pg_stat_statements` realice un seguimiento de las consultas de puntos de guardado.
**nota**
El parámetro `pg_stat_statements.track_utility` es un parámetro dinámico. Puede cambiar su valor sin necesidad de reiniciar la instancia de la base de datos.
**Example Ejemplo de consultas de punto de guardado únicas en pg\$1stat\$1statements**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 presenta varias mejoras para el seguimiento de comandos de utilidades:
+ Los nombres de los puntos de guardado ahora se muestran como constantes.
+ Los ID de transacción globales (GID) de los comandos de confirmación de dos fases ahora se muestran como constantes.
+ Los nombres de las instrucciones DEALLOCATE se muestran como constantes.
+ Los parámetros CALL ahora se muestran como constantes.
# LWLock:SubtransSLRU (LWLock:SubtransControlLock)
Los eventos de espera `LWLock:SubtransSLRU` y `LWLock:SubtransBuffer` indican que una sesión está esperando para acceder a la caché simple de uso menos reciente (SLRU) para la información de subtransacciones. Esto ocurre al determinar la visibilidad de las transacciones y las relaciones entre principales y secundarios.
+ `LWLock:SubtransSLRU`: un proceso está esperando para acceder a la caché simple de uso menos reciente (SLRU) para una subtransacción. En RDS para PostgreSQL anterior a la versión 13, este evento de espera se llama `SubtransControlLock`.
+ `LWLock:SubtransBuffer`: un proceso está esperando la E/S en un búfer simple de uso menos reciente (SLRU) para una subtransacción. En RDS para PostgreSQL anterior a la versión 13, este evento de espera se llama `subtrans`.
**Topics**
+ [Versiones del motor admitidas](#wait-event.lwlocksubtransslru.supported)
+ [Contexto](#wait-event.lwlocksubtransslru.context)
+ [Causas probables del aumento de las esperas](#wait-event.lwlocksubtransslru.causes)
+ [Acciones](#wait-event.lwlocksubtransslru.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Contexto
**Descripción de las subtransacciones**: una subtransacción es una transacción dentro de una transacción en PostgreSQL. También se conoce como transacción anidada.
Por lo general, las subtransacciones se crean cuando se utiliza:
+ `SAVEPOINT`Comandos de
+ Bloques de excepciones (`BEGIN/EXCEPTION/END`)
Las subtransacciones le permiten revertir partes de una transacción sin que ello afecte a toda la transacción. Esto le brinda un control minucioso sobre la administración de transacciones.
**Detalles de implementación**: PostgreSQL implementa subtransacciones como estructuras anidadas dentro de las transacciones principales. Cada subtransacción recibe su propio ID de transacción.
Aspectos de implementación claves:
+ Los ID de las transacciones se rastrean en `pg_xact`
+ Las relaciones principal-secundario se almacenan en el subdirectorio `pg_subtrans` en `PGDATA`
+ Cada sesión de base de datos puede mantener hasta `64` subtransacciones activas
+ Si se supera este límite se produce un desbordamiento de subtransacciones, lo que requiere acceder a la caché simple de uso menos reciente (SLRU) para la información de subtransacciones
## Causas probables del aumento de las esperas
Entre las causas más comunes de la contención de SLRU en las subtransacciones se incluyen:
+ **Uso excesivo del manejo de SAVEPOINT y EXCEPTION**: los procedimientos PL/pgSQL con controladores `EXCEPTION` crean automáticamente puntos de almacenamiento implícitos, independientemente de si se producen o no excepciones. Cada `SAVEPOINT` inicia una nueva subtransacción. Cuando una sola transacción acumula más de 64 subtransacciones, desencadena un desbordamiento de SLRU de subtransacciones.
+ **Configuraciones de controladores y ORM**: el uso de `SAVEPOINT` puede ser explícito en el código de la aplicación o implícito en las configuraciones de los controladores. Muchas de las herramientas ORM y los marcos de aplicaciones más utilizados admiten transacciones anidadas de forma nativa. Estos son algunos ejemplos comunes:
+ El parámetro del controlador JDBC `autosave`, si está establecido en `always` o `conservative`, genera puntos de almacenamiento antes de cada consulta.
+ Definiciones de transacciones de Spring Framework cuando se establece en `propagation_nested`.
+ Registros de seguimiento cuando `requires_new: true` está configurado.
+ SQLAlchemy cuando `session.begin_nested` se usa.
+ Django cuando se usan bloques de `atomic()` anidados.
+ GORM cuando se usa `Savepoint`.
+ psqlODBC cuando la configuración por reversión se establece en la reversión por instrucción (por ejemplo, `PROTOCOL=7.4-2`).
+ **Cargas de trabajo simultáneas altas con transacciones y subtransacciones de larga duración**: cuando se produce un desbordamiento de la SLRU de subtransacciones durante cargas de trabajo simultáneas altas y transacciones y subtransacciones de larga duración, PostgreSQL experimenta una mayor contención. Esto se manifiesta como eventos de espera elevados para bloqueos `LWLock:SubtransBuffer` y `LWLock:SubtransSLRU`.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera. Algunas acciones proporcionan un alivio inmediato, mientras que otras requieren una investigación y una corrección a largo plazo.
**Topics**
+ [Supervisión del uso de subtransacciones](#wait-event.lwlocksubtransslru.actions.monitor)
+ [Configuración de los parámetros de memoria](#wait-event.lwlocksubtransslru.actions.memory)
+ [Acciones a largo plazo](#wait-event.lwlocksubtransslru.actions.longterm)
### Supervisión del uso de subtransacciones
Para las versiones 16.1 y posteriores de PostgreSQL, utilice la siguiente consulta para supervisar los recuentos de subtransacciones y el estado de desbordamiento por backend. Esta consulta combina las estadísticas del backend con la información de la actividad para mostrar qué procesos utilizan subtransacciones:
```
SELECT a.pid, usename, query, state, wait_event_type,
wait_event, subxact_count, subxact_overflowed
FROM (SELECT id, pg_stat_get_backend_pid(id) pid, subxact_count, subxact_overflowed
FROM pg_stat_get_backend_idset() id
JOIN LATERAL pg_stat_get_backend_subxact(id) AS s ON true
) a
JOIN pg_stat_activity b ON a.pid = b.pid;
```
Para las versiones 13.3 y posteriores de PostgreSQL, supervise la vista `pg_stat_slru` para comprobar la presión de la caché de las subtransacciones. La siguiente consulta SQL recupera las estadísticas de la caché de la SLRU para el componente Subtrans:
```
SELECT * FROM pg_stat_slru WHERE name = 'Subtrans';
```
Un valor `blks_read` que aumenta de forma coherente indica el acceso frecuente al disco para las subtransacciones no almacenadas en caché, lo que indica una posible presión en la memoria caché de la SLRU.
### Configuración de los parámetros de memoria
Para PostgreSQL 17.1 y versiones posteriores, puede configurar el tamaño de la caché de SLRU de la subtransacción mediante el parámetro `subtransaction_buffers`. En el siguiente ejemplo de configuración, se muestra cómo establecer el parámetro de búfer de subtransacciones:
```
subtransaction_buffers = 128
```
Este parámetro especifica la cantidad de memoria compartida que se utiliza para almacenar en caché el contenido de las subtransacciones (`pg_subtrans`). Si se especifica sin unidades, el valor representa bloques de `BLCKSZ` bytes, normalmente de 8 KB cada uno. Por ejemplo, si se establece el valor en 128, se asigna 1 MB (128 \$1 8 KB) de memoria para la caché de subtransacciones.
**nota**
Puede establecer este parámetro por clúster para que todas las instancias se mantengan coherentes. Pruebe y ajuste el valor para que se adapte a los requisitos de carga de trabajo específicos y a la clase de instancia. Debe reiniciar la instancia de escritor para que los cambios de parámetro tengan efecto.
### Acciones a largo plazo
+ **Examine el código y las configuraciones de la aplicación**: revise las configuraciones del código de la aplicación y del controlador de la base de datos para ver el uso explícito e implícito de `SAVEPOINT` y el uso de subtransacciones en general. Identifique las transacciones que podrían generar más de 64 subtransacciones.
+ **Reduzca el uso de puntos de almacenamiento**: minimice el uso de puntos de almacenamiento en las transacciones:
+ Revise los procedimientos y las funciones de PL/pgSQL con bloques EXCEPTION. Los bloques EXCEPTION crean automáticamente puntos de almacenamiento implícitos, que pueden contribuir al desbordamiento de las subtransacciones. Cada cláusula EXCEPTION crea una subtransacción, independientemente de si realmente se produce una excepción durante la ejecución.
**Example**
Ejemplo 1: Uso problemático del bloque EXCEPTION
En el siguiente ejemplo de código, se muestra el uso problemático del bloque EXCEPTION que crea varias subtransacciones:
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
BEGIN
-- This creates a subtransaction for each iteration
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW());
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
EXCEPTION
WHEN unique_violation THEN
-- Handle duplicate audit entries
UPDATE user_audit
SET timestamp = NOW()
WHERE user_id = user_record.id AND action = 'processed';
END;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
El ejemplo de código mejorado siguiente reduce el uso de subtransacciones mediante el uso de UPSERT en lugar del manejo de excepciones:
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
-- Use UPSERT to avoid exception handling
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW())
ON CONFLICT (user_id, action)
DO UPDATE SET timestamp = NOW();
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
**Example**
Ejemplo 2: Controlador de excepciones STRICT
En el ejemplo de código siguiente, se muestra un manejo problemático de EXCEPTION con NO\$1DATA\$1FOUND:
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
BEGIN
-- STRICT causes an exception if no rows or multiple rows found
SELECT email INTO STRICT user_email
FROM users
WHERE id = p_user_id;
RETURN user_email;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN 'Email not found';
END;
END;
$$ LANGUAGE plpgsql;
```
El ejemplo de código mejorado siguiente evita subtransacciones mediante el uso de IF NOT FOUND en lugar del manejo de excepciones:
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
SELECT email INTO user_email
FROM users
WHERE id = p_user_id;
IF NOT FOUND THEN
RETURN 'Email not found';
ELSE
RETURN user_email;
END IF;
END;
$$ LANGUAGE plpgsql;
```
+ Controlador JDBC: el parámetro `autosave`, si está establecido en `always` o `conservative`, genera puntos de almacenamiento antes de cada consulta. Evalúe si la configuración de `never` sería aceptable para la aplicación.
+ Controlador ODBC de PostgreSQL (psqlODBC): la configuración del nivel de reversión (para la reversión por instrucción) crea puntos de almacenamiento implícitos para habilitar la funcionalidad de reversión de instrucciones. Evalúe si el nivel de la transacción o sin reversión sería aceptable para la aplicación.
+ Examen de las configuraciones de transacciones de ORM
+ Consideración de estrategias alternativas de manejo de errores que no requieran puntos de almacenamiento
+ **Optimización del diseño de las transacciones**: reestructure las transacciones para evitar el anidamiento excesivo y reducir la probabilidad de que se produzcan desbordamientos de las subtransacciones.
+ **Reduzca las transacciones de larga duración**: las transacciones de larga duración pueden agravar los problemas relacionados con las subtransacciones al conservar la información de las subtransacciones durante más tiempo. Supervise las métricas de información de rendimiento y configure el parámetro `idle_in_transaction_session_timeout` para terminar automáticamente las transacciones inactivas.
+ Supervise las métricas de información de rendimiento: realice un seguimiento de las métricas, incluido `idle_in_transaction_count` (número de sesiones inactivas en estado de transacción) y `idle_in_transaction_max_time` (duración de la transacción inactiva más prolongada) para detectar transacciones de larga duración.
+ Configure `idle_in_transaction_session_timeout`: defina este parámetro en el grupo de parámetros para terminar automáticamente las transacciones inactivas después de un periodo especificado.
+ Supervisión proactiva: supervise los eventos de espera de alta frecuencia `LWLock:SubtransBuffer` y `LWLock:SubtransSLRU` para detectar conflictos relacionados con las subtransacciones antes de que se conviertan en críticos.
# Timeout:PgSleep
El evento `Timeout:PgSleep` ocurre cuando un proceso del servidor llama a la función `pg_sleep` y espera a que el tiempo de espera expire.
**Topics**
+ [Versiones del motor admitidas](#wait-event.timeoutpgsleep.context.supported)
+ [Causas probables del aumento del tiempo de espera](#wait-event.timeoutpgsleep.causes)
+ [Acciones](#wait-event.timeoutpgsleep.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Causas probables del aumento del tiempo de espera
Este evento de espera ocurre cuando una aplicación, función almacenada o usuario emite una sentencia SQL que llama a una de las siguientes funciones:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
Las funciones anteriores retrasan la ejecución hasta que transcurra el número de segundos especificado. Por ejemplo, `SELECT pg_sleep(1)` hace una pausa de 1 segundo. Para más información, consulte [Delaying Execution](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) en la documentación de PostgreSQL.
## Acciones
Identifique la sentencia que estaba ejecutando la función `pg_sleep`. Determine si el uso de la función es adecuado.
# Timeout:VacuumDelay
El evento `Timeout:VacuumDelay` indica que se ha superado el límite de costo de las E/S de vacío y que el proceso de vacío está en reposo. Las operaciones de aspiración se detienen durante el tiempo especificado en el parámetro de retraso de coste correspondiente y, a continuación, reanudan su trabajo. Para el comando de limpieza manual, el retraso se especifica en el parámetro `vacuum_cost_delay`. Para el deamon autovacuum, el retraso se especifica en `autovacuum_vacuum_cost_delay parameter.`.
**Topics**
+ [Versiones del motor admitidas](#wait-event.timeoutvacuumdelay.context.supported)
+ [Context](#wait-event.timeoutvacuumdelay.context)
+ [Causas probables del aumento del tiempo de espera](#wait-event.timeoutvacuumdelay.causes)
+ [Acciones](#wait-event.timeoutvacuumdelay.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
## Context
PostgreSQL tiene un daemon autovaccum y un comando de limpieza manual. El proceso de autovacuum está “activado” de forma predeterminada para las instancias de base de datos de RDS para PostgreSQL. El comando de limpieza manual se usa según sea necesario, por ejemplo, para purgar tablas de tuplas muertas o para generar nuevas estadísticas.
Cuando se realiza la limpieza, PostgreSQL utiliza un contador interno para realizar un seguimiento de los costos estimados a medida que el sistema realiza diversas operaciones de E/S. Cuando el contador alcanza el valor especificado en el parámetro de límite de costo, el proceso que realiza la operación permanece en reposo durante el breve período especificado en el parámetro de retraso de costo. A continuación, reinicia el contador y continúa con las operaciones.
El proceso de vacío tiene parámetros que se pueden utilizar para regular el consumo de recursos. El vacío automático y el comando de vacío manual tienen sus propios parámetros para establecer el valor de límite de costo. También tienen sus propios parámetros para especificar un retraso en el costo, una cantidad de tiempo para poner la limpieza en reposo cuando se alcanza el límite. De esta manera, el parámetro de retraso de costos funciona como un mecanismo de limitación del consumo de recursos. En las siguientes listas encontrará las descripciones de estos parámetros.
**Parámetros que afectan a la limitación del daemon autovacuum**
+ `[autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)`: especifica el valor límite de costo que se utilizará en las operaciones de vacío automático. El aumento de la configuración de este parámetro permite que el proceso de vacío utilice más recursos y reduce el evento de espera `Timeout:VacuumDelay`.
+ `[autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)`: especifica el valor retardo de costo que se utilizará en las operaciones de vacío automático. El valor predeterminado es de 2 milisegundos. Al establecer el parámetro de retardo en 0, se desactiva el mecanismo de limitación y, por lo tanto, el evento de espera `Timeout:VacuumDelay` no aparecerá.
Para más información, visite [Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY) (Vacío automático) en la documentación de PostgreSQL.
**Parámetros que afectan a la limitación del proceso de vacío manual**
+ `vacuum_cost_limit`: umbral en el que el proceso de limitación está en reposo. El límite predeterminado de es de 200. Este número representa las estimaciones de costos acumulados para las E/S adicionales que necesitan varios recursos. Al aumentar este valor, se reduce el número del evento de espera `Timeout:VacuumDelay`.
+ `vacuum_cost_delay`: cantidad de tiempo que el proceso de vacío está en reposo cuando se ha alcanzado el límite de costo de vacío. La configuración predeterminada es 0, lo que significa que esta función está desactivada. Puede configurarla con un valor entero para especificar el número de milisegundos necesarios para activar esta función, pero le recomendamos que la deje como configuración predeterminada.
Para obtener más información acerca del parámetro `vacuum_cost_delay`, consulte el punto [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST) (Consumo de recursos) en la documentación de PostgreSQL.
Para obtener más información acerca del uso del vacío automático con RDS para PostgreSQL, consulte [Uso de autovacuum de PostgreSQL en Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
## Causas probables del aumento del tiempo de espera
`Timeout:VacuumDelay` se ve afectado por el equilibrio entre la configuración de los parámetros del límite de costo (`vacuum_cost_limit`, `autovacuum_vacuum_cost_limit`) y los parámetros de retraso de costo (`vacuum_cost_delay`, `autovacuum_vacuum_cost_delay`) que controlan la duración del reposo del vacío. Al aumentar el valor de un parámetro de límite de costo, el vacío puede utilizar más recursos antes de que entre en reposo. Esto se traduce en menos eventos de espera `Timeout:VacuumDelay`. El aumento de cualquiera de los parámetros de retraso hace que el evento de espera `Timeout:VacuumDelay` se produzca con más frecuencia y durante períodos de tiempo más prolongados.
La configuración del parámetro `autovacuum_max_workers` también puede aumentar el número de `Timeout:VacuumDelay`. Cada proceso adicional de trabajo de autovacuum contribuye al mecanismo de contador interno y, por lo tanto, se puede alcanzar el límite más rápidamente que con un solo proceso de trabajo de autovacuum. A medida que se alcanza el límite de costo más rápidamente, el retraso en el costo se hace efectivo con más frecuencia, lo que resulta en más eventos de espera `Timeout:VacuumDelay`. Para más información, consulte [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS) en la documentación de PostgreSQL.
Los objetos grandes, como de 500 GB o más, también aumentan este evento de espera, ya que el vacío puede tardar algún tiempo en completar el procesamiento de objetos grandes.
## Acciones
Si las operaciones de vacío se completan según lo previsto, no es necesario realizar ninguna corrección. En otras palabras, este evento de espera no significa necesariamente que se trate de un problema. Indica que el vacío está en reposo durante el período de tiempo especificado en el parámetro de retraso, de modo que los recursos se puedan aplicar a otros procesos que deben completarse.
Si desea que las operaciones de vacío se completen más rápido, puede reducir los parámetros de retardo. Esto acorta el tiempo que el vacío permanece inactivo.
# Ajuste de RDS para PostgreSQL con información proactiva de Amazon DevOps Guru
La información proactiva de DevOps Guru detecta las condiciones en sus instancias de base de datos de RDS para PostgreSQL que pueden causar problemas y le permiten conocerlos antes de que se produzcan. La información proactiva puede alertarle sobre algún elemento que lleve tiempo inactivo en la conexión de la transacción. Para obtener más información sobre cómo resolver un problema relacionado con una inactividad prolongada en las conexiones de transacciones, consulte [La base de datos lleva mucho tiempo inactiva en la conexión de la transacción](#proactive-insights.idle-txn).
DevOps Guru puede hacer lo siguiente:
+ Evitar muchos problemas comunes en las bases de datos cotejando la configuración de la base de datos con la configuración habitual recomendada.
+ Alertar sobre problemas críticos en su flota que, si no se comprueban, pueden provocar problemas mayores en el futuro.
+ Avisarle de los problemas que acaban de descubrirse.
Cada información proactiva contiene un análisis de la causa del problema y recomendaciones para las acciones correctivas.
Para obtener más información sobre Amazon DevOps Guru para Amazon RDS, consulte [Análisis de anomalías de rendimiento con Amazon DevOps Guru para Amazon RDS](devops-guru-for-rds.md).
## La base de datos lleva mucho tiempo inactiva en la conexión de la transacción
Una conexión a la base de datos lleva en el estado `idle in transaction` más de 1800 segundos.
**Topics**
+ [Versiones del motor admitidas](#proactive-insights.idle-txn.context.supported)
+ [Contexto](#proactive-insights.idle-txn.context)
+ [Causas probables de este problema](#proactive-insights.idle-txn.causes)
+ [Acciones](#proactive-insights.idle-txn.actions)
+ [Métricas relevantes](#proactive-insights.idle-txn.metrics)
### Versiones del motor admitidas
Esta información es compatible con todas las versiones de RDS para PostgreSQL.
### Contexto
Una transacción en el estado `idle in transaction` puede contener bloqueos que bloqueen otras consultas. También puede evitar que `VACUUM` (incluido autovacuum) limpie las filas inactivas, lo que provoca una sobrecarga de índices o tablas o un resumen de los ID de transacciones.
### Causas probables de este problema
Una transacción iniciada en una sesión interactiva con BEGIN o START TRANSACTION no ha finalizado con los comandos COMMIT, ROLLBACK o END. Esto hace que la transacción pase al estado `idle in transaction`.
### Acciones
Para encontrar transacciones inactivas, consulte `pg_stat_activity`.
En su cliente SQL, ejecute la siguiente consulta para ver todas las conexiones en el estado `idle in transaction` y ordenarlas por duración:
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Recomendamos diferentes acciones en función de las causas.
**Topics**
+ [Finalización de la transacción](#proactive-insights.idle-txn.actions.end-txn)
+ [Finalización de la conexión](#proactive-insights.idle-txn.actions.end-connection)
+ [Configure el parámetro idle\$1in\$1transaction\$1session\$1timeout](#proactive-insights.idle-txn.actions.parameter)
+ [Compruebe el estado AUTOCOMMIT](#proactive-insights.idle-txn.actions.autocommit)
+ [Compruebe la lógica de la transacción en el código de su aplicación](#proactive-insights.idle-txn.actions.app-logic)
#### Finalización de la transacción
Al iniciar una transacción en una sesión interactiva con BEGIN o START TRANSACTION, esta pasa al estado `idle in transaction`. Permanecerá en este estado hasta que finalice la transacción al emitir los comandos COMMIT, ROLLBACK, END o hasta que finalice la conexión por completo para revertir la transacción.
#### Finalización de la conexión
Finalice la conexión con una transacción inactiva mediante la siguiente consulta:
```
SELECT pg_terminate_backend(pid);
```
pid es el ID del proceso de la conexión.
#### Configure el parámetro idle\$1in\$1transaction\$1session\$1timeout
Configure el parámetro `idle_in_transaction_session_timeout` en el grupo de parámetros. La ventaja de configurar este parámetro es que no requiere una intervención manual para finalizar el periodo de inactividad prolongado de la transacción. Para obtener más información sobre este parámetro, consulte [la documentación de PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-client.html).
El siguiente mensaje aparecerá en el archivo de registro de PostgreSQL una vez finalizada la conexión y cuando haya una transacción en el estado idle\$1in\$1transaction durante más tiempo del especificado.
```
FATAL: terminating connection due to idle in transaction timeout
```
#### Compruebe el estado AUTOCOMMIT
AUTOCOMMIT está activado de forma predeterminada. Pero si se desactiva accidentalmente en el cliente, asegúrese de volver a activarlo.
+ En su cliente psql, ejecute el siguiente comando:
```
postgres=> \set AUTOCOMMIT on
```
+ En pgadmin, para activarlo, seleccione la opción AUTOCOMMIT en la flecha hacia abajo.
![\[En pgadmin, elija AUTOCOMMIT para activarlo.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/apg-insight-pgadmin-autocommit.png)
#### Compruebe la lógica de la transacción en el código de su aplicación
Investigue la lógica de su aplicación para detectar posibles problemas. Considere las siguientes acciones:
+ Compruebe si la confirmación automática de JDBC está activada en su aplicación. Además, considere la posibilidad de usar comandos `COMMIT` explícitos en su código.
+ Compruebe su lógica de gestión de errores para ver si cierra una transacción después de que se produzcan errores.
+ Compruebe si su aplicación tarda mucho en procesar las filas devueltas por una consulta mientras la transacción está abierta. Si es así, considere la posibilidad de programar la aplicación para que cierre la transacción antes de procesar las filas.
+ Compruebe si una transacción contiene muchas operaciones de larga duración. Si es así, divida una sola transacción en varias transacciones.
### Métricas relevantes
Las siguientes métricas de PI están relacionadas con esta información:
+ idle\$1in\$1transaction\$1count: número de sesiones en el estado `idle in transaction`.
+ idle\$1in\$1transaction\$1max\$1time: la duración de la transacción en ejecución de más larga duración en el estado `idle in transaction`.
# Uso de extensiones PostgreSQL con Amazon RDS para PostgreSQL
Puede ampliar la funcionalidad de PostgreSQL instalando una variedad de extensiones y módulos. Por ejemplo, para trabajar con datos espaciales, puede instalar y utilizar la extensión de PostGIS. Para obtener más información, consulte [Administración de datos espaciales con la extensión PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md). Otro ejemplo, si desea mejorar la entrada de datos para tablas muy grandes, puede considerar la posibilidad de particionar los datos con la extensión `pg_partman`. Para obtener más información, consulte [Administración de las particiones de PostgreSQL con la extensión pg\$1partman](PostgreSQL_Partitions.md).
**nota**
RDS para PostgreSQL admite extensiones de lenguaje de confianza para PostgreSQL a través de la extensión `pg_tle`, que puede agregar a la instancia de base de datos. Con esta extensión, los desarrolladores pueden crear sus propias extensiones de PostgreSQL en un entorno seguro que simplifica los requisitos de instalación y configuración. Para obtener información sobre las versiones de RDS para PostgreSQL que admiten la extensión `pg_tle` y para más detalles, consulte [Uso de Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension.md).
En algunos casos, en lugar de instalar una extensión, puede agregar un módulo específico a la lista de `shared_preload_libraries` en el grupo de parámetros de la base de datos personalizado de la instancia de base de datos de RDS para PostgreSQL. Por lo general, el grupo de parámetros del clúster de base de datos predeterminado solo carga las `pg_stat_statements`, pero hay varios otros módulos disponibles para agregarlos a la lista. Por ejemplo, puede añadir la capacidad de programación añadiendo el módulo`pg_cron`, tal como se detalla en [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL](PostgreSQL_pg_cron.md). Como otro ejemplo, puede registrar los planes de ejecución de consultas cargando el módulo `auto_explain`. Para obtener más información, consulte [Logging execution plans of queries](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) (Registro de los planes de ejecución de las consultas) en el centro de conocimiento de AWS.
Según la versión de RDS para PostgreSQL, la instalación de una extensión podría requerir permisos `rds_superuser`, de la siguiente forma:
+ Para versiones 12 y anteriores de RDS para PostgreSQL, la instalación de extensiones requiere privilegios de `rds_superuser`.
+ Para la versión 13 y superiores de RDS para PostgreSQL , los usuarios (roles) con permisos de creación en una instancia de base de datos determinada pueden instalar y utilizar cualquier *extensión de confianza*. Para obtener una lista de las extensiones de confianza, consulte [Extensiones de confianza de PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted).
También puede especificar con precisión qué extensiones se pueden instalar en la instancia de base de datos de RDS para PostgreSQL, enumerándolas en el parámetro `rds.allowed_extensions`. Para obtener más información, consulte [Restringir la instalación de extensiones de PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Para obtener más información acerca del rol `rds_superuser`, consulte [Descripción de los roles y permisos de PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
**Topics**
+ [Uso de las funciones de la extensión orafce](Appendix.PostgreSQL.CommonDBATasks.orafce.md)
+ [Uso de la compatibilidad de extensiones delegadas de Amazon RDS para PostgreSQL](RDS_delegated_ext.md)
+ [Administración de las particiones de PostgreSQL con la extensión pg\$1partman](PostgreSQL_Partitions.md)
+ [Uso de pgAudit para registrar la actividad de la base de datos](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL](PostgreSQL_pg_cron.md)
+ [Uso de pglogical para sincronizar datos entre instancias](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [Uso de pgactive para admitir la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.md)
+ [Reducción de la sobrecarga en tablas e índices con la extensión pg\$1repack](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md)
+ [Actualización y uso de la extensión PLV8](PostgreSQL.Concepts.General.UpgradingPLv8.md)
+ [Uso de PL/Rust para escribir funciones de PostgreSQL en lenguaje Rust](PostgreSQL.Concepts.General.Using.PL_Rust.md)
+ [Administración de datos espaciales con la extensión PostGIS](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
# Uso de las funciones de la extensión orafce
La extensión orafce brinda funciones y operadores que emulan un subconjunto de funciones y paquetes de una base de datos de Oracle. La extensión orafce facilita la realización de la portabilidad de una aplicación Oracle a PostgreSQL. Esta extensión es compatible con la versión 9.6.6 y posteriores de RDS for PostgreSQL. Para obtener más información sobre orafce, consulte [orafce](https://github.com/orafce/orafce) en GitHub.
**nota**
RDS for PostgreSQL no admite el paquete `utl_file` que forma parte de la extensión orafce. Esto se debe a que las funciones del esquema `utl_file` proporcionan operaciones de lectura y escritura con archivos de texto del sistema operativo, lo que requiere el acceso de los superusuarios al host subyacente. Como servicio administrado, RDS for PostgreSQL no brinda acceso al host.
**Para usar la extensión orafce**
1. Conéctese a la instancia de base de datos con el nombre de usuario principal que utilizó para crear la instancia de base de datos.
Si desea activar orafce para una base de datos diferente en la misma instancia de base de datos, utilice el comando psql `/c dbname`. Con este comando, cambia de la base de datos principal después de iniciar la conexión.
1. Active la extensión orafce con la instrucción `CREATE EXTENSION`.
```
CREATE EXTENSION orafce;
```
1. Transfiera la propiedad del esquema de Oracle al rol rds\$1superuser con la instrucción `ALTER SCHEMA`.
```
ALTER SCHEMA oracle OWNER TO rds_superuser;
```
Si desea ver la lista de propietarios del esquema de Oracle, utilice el comando `\dn` de psql.
# Uso de la compatibilidad de extensiones delegadas de Amazon RDS para PostgreSQL
Al utilizar la compatibilidad de extensiones delegadas de Amazon RDS para PostgreSQL, puede delegar la administración de la extensión a un usuario que no necesita ser un `rds_superuser`. Con esta compatibilidad de extensiones delegadas, se crea un nuevo rol denominado `rds_extension` que debe asignarse a un usuario para que administre otras extensiones. Este rol puede crear, actualizar y eliminar extensiones.
Puede especificar qué extensiones se pueden instalar en la instancia de base de datos de RDS enumerándolas en el parámetro `rds.allowed_extensions`. Para obtener más información, consulte [Uso de extensiones PostgreSQL con Amazon RDS para PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html).
Puede restringir la lista de extensiones disponibles que el usuario puede administrar con el rol `rds_extension` utilizando el parámetro `rds.allowed_delegated_extensions`.
La compatibilidad de extensiones delegadas está disponible en las siguientes versiones:
+ Todas las versiones superiores
+ Versión 16.4 y otras versiones 16 superiores
+ Versión 15.8 y otras versiones 15 superiores
+ Versión 14.13 y otras versiones 14 superiores
+ Versión 13.16 y otras versiones 13 superiores
+ Versión 12.20 y otras versiones 12 superiores
**Topics**
+ [Activación de la compatibilidad con extensiones delegadas a un usuario](#RDSPostgreSQL.delegated_ext_mgmt)
+ [Configuración utilizada en la compatibilidad de extensiones delegadas de RDS para PostgreSQL](#RDSPostgreSQL.delegated_ext_config)
+ [Desactivar la compatibilidad para la extensión delegada](#RDSPostgreSQL.delegated_ext_disable)
+ [Ventajas del uso de la compatibilidad de extensiones delegadas de Amazon RDS](#RDSPostgreSQL.delegated_ext_benefits)
+ [Limitación de la compatibilidad de extensiones delegadas de Amazon RDS para PostgreSQL](#RDSPostgreSQL.delegated_ext_limit)
+ [Permisos necesarios para determinadas extensiones](#RDSPostgreSQL.delegated_ext_perm)
+ [Consideraciones de seguridad](#RDSPostgreSQL.delegated_ext_sec)
+ [Eliminación de extensión en cascada deshabilitada](#RDSPostgreSQL.delegated_ext_drop)
+ [Ejemplos de extensiones que se pueden agregar mediante la compatibilidad de extensiones delegadas](#RDSPostgreSQL.delegated_ext_support)
## Activación de la compatibilidad con extensiones delegadas a un usuario
Debe realizar lo siguiente para habilitar la compatibilidad con extensiones delegadas en un usuario:
1. **Otorgar el rol `rds_extension` a un usuario**: conéctese a la base de datos como `rds_superuser` y ejecute el siguiente comando:
```
Postgres => grant rds_extension to user_name;
```
1. **Defina la lista de extensiones disponibles para que las administren los usuarios delegados**: `rds.allowed_delegated_extensions` permite especificar un subconjunto de las extensiones disponibles utilizando `rds.allowed_extensions` en el parámetro del clúster de base de datos. Puede realizar esto en uno de los siguientes niveles:
+ En el clúster o en el grupo de parámetros de la instancia, a través de la Consola de administración de AWS o la API. Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
+ Use el siguiente comando en el nivel de la base de datos:
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ Use el siguiente comando en el nivel de usuario:
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**nota**
No es necesario reiniciar la base de datos después de cambiar el parámetro dinámico `rds.allowed_delegated_extensions`.
1. **Permita el acceso del usuario delegado a los objetos creados durante el proceso de creación de la extensión**: algunas extensiones crean objetos que requieren la concesión de permisos adicionales antes de que el usuario con el rol `rds_extension` pueda acceder a ellos. El `rds_superuser` debe conceder al usuario delegado acceso a esos objetos. Una de las opciones es utilizar un desencadenador de eventos para conceder automáticamente el permiso al usuario delegado.
**Ejemplo de desencadenador de eventos**
Si desea permitir que un usuario delegado con `rds_extension` utilice extensiones que requieran configurar permisos en los objetos creados al crear la extensión, puede personalizar el siguiente ejemplo de un desencadenador de eventos y agregar solo las extensiones para las que desee que los usuarios delegados tengan acceso a todas las funciones. Este activador de eventos se puede crear en la plantilla 1 (la plantilla predeterminada), por lo que todas las bases de datos creadas a partir de la plantilla 1 tendrán ese desencadenador de eventos. Cuando un usuario delegado instala la extensión, este desencadenador otorgará automáticamente la propiedad de los objetos creados por la extensión.
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## Configuración utilizada en la compatibilidad de extensiones delegadas de RDS para PostgreSQL
| Nombre de la configuración | Descripción | Valor predeterminado | Notas | Quién puede modificar o conceder el permiso |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | Este parámetro limita las extensiones que un rol de rds\$1extension puede administrar en una base de datos. Debe ser un subconjunto de rds.allowed\$1extensions. | empty string | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/RDS_delegated_ext.html) Para obtener más información sobre la configuración de este parámetro, consulte [Activación de la compatibilidad con extensiones delegadas a un usuario](#RDSPostgreSQL.delegated_ext_mgmt). | rds\$1superuser |
| `rds.allowed_extensions` | Este parámetro permite que un cliente limite las extensiones que se pueden instalar en la instancia de base de datos de RDS. Para obtener más información, consulte [Restringir la instalación de extensiones de PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction). | "\$1" | De forma predeterminada, este parámetro está establecido en “\$1”, lo que significa que los usuarios con los privilegios necesarios pueden crear todas las extensiones compatibles con RDS para PostgreSQL y Aurora PostgreSQL. Vacío significa que no se pueden instalar extensiones en la instancia de base de datos de RDS. | administrator |
| `rds-delegated_extension_allow_drop_cascade` | Este parámetro controla la capacidad del usuario con `rds_extension` de eliminar la extensión mediante una opción en cascada. | apagar | De forma predeterminada, `rds-delegated_extension_allow_drop_cascade` está establecido en `off`. Esto significa que los usuarios con `rds_extension` no pueden eliminar una extensión mediante la opción en cascada. Para otorgar esa habilidad, el parámetro `rds.delegated_extension_allow_drop_cascade` debe configurarse como `on`. | rds\$1superuser |
## Desactivar la compatibilidad para la extensión delegada
**Desactivación parcial**
Los usuarios delegados no pueden crear nuevas extensiones, pero sí pueden actualizar las existentes.
+ Restablece `rds.allowed_delegated_extensions` al valor predeterminado en el grupo de parámetros del clúster de base de datos.
+ Use el siguiente comando en el nivel de la base de datos:
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ Use el siguiente comando en el nivel de usuario:
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**Desactivación completa**
Al revocar el rol `rds_extension` de un usuario, el usuario recuperará los permisos estándar. El usuario ya no puede crear, actualizar ni eliminar extensiones.
```
postgres => revoke rds_extension from user_name;
```
## Ventajas del uso de la compatibilidad de extensiones delegadas de Amazon RDS
Al utilizar la compatibilidad de extensiones delegadas de Amazon RDS para PostgreSQL, delega de forma segura la administración de la extensión a los usuarios que no tengan el rol `rds_superuser`. Esta característica proporciona los siguientes beneficios:
+ Puede delegar fácilmente la administración de extensiones a los usuarios de su elección.
+ Esto no requiere el rol `rds_superuser`.
+ Ofrece la posibilidad de admitir diferentes conjuntos de extensiones para diferentes bases de datos en el mismo clúster de base de datos.
## Limitación de la compatibilidad de extensiones delegadas de Amazon RDS para PostgreSQL
+ Los objetos creados durante el proceso de creación de la extensión pueden requerir privilegios adicionales para que la extensión funcione correctamente.
+ De forma predeterminada, hay algunas extensiones que el usuario de la extensión delegada no puede administrar, como `log_fdw`, `pg_cron`, `pg_tle`, `pgactive`, `pglogical`, `postgis_raster`, `postgis_tiger_geocoder`, `postgis_topology`.
## Permisos necesarios para determinadas extensiones
Para crear, usar o actualizar las siguientes extensiones, el usuario delegado debe tener los privilegios necesarios en las siguientes funciones, tablas y esquemas.
| Extensiones que necesitan propiedad o permisos | Función | Tablas | Esquema | Diccionario de búsqueda de texto | Comment |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | none | us\$1gaz, us\$1lex, us\$1lex, I.us\$1rules | none | none | none |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | none | none | none | none |
| dict\$1int | none | none | none | intdict | none |
| pg\$1partman | none | custom\$1time\$1partitions, part\$1config, part\$1config\$1sub | none | none | none |
| pg\$1stat\$1statements | none | none | none | none | none |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | none | none | none |
| postgis\$1raster | none | none | none | none | none |
| postgis\$1topology | none | topology, layer | topology | none | el usuario delegado debe ser el propietario de la base de datos |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | none | none | none | none |
| rds\$1tools | role\$1password\$1encryption\$1type | none | none | none | none |
| postgis\$1tiger\$1geocoder | none | geocode\$1settings\$1default, geocode\$1settings | tiger | none | none |
| pg\$1freespacemap | pg\$1freespace | none | none | none | none |
| pg\$1visibility | pg\$1visibility | none | none | none | none |
## Consideraciones de seguridad
Tenga en cuenta que un usuario con el rol `rds_extension` podrá administrar las extensiones en todas las bases de datos en las que tenga el privilegio de conexión. Si la intención es que un usuario delegado administre la extensión en una única base de datos, una práctica recomendada consiste en revocar todos los privilegios del público en cada base de datos y, a continuación, conceder de forma explícita el privilegio de conexión para esa base de datos específica al usuario delegado.
Existen varias extensiones que permiten a un usuario acceder a la información de varias bases de datos. Asegúrese de que los usuarios a los que conceda `rds_extension` tengan capacidades para múltiples bases de datos antes de agregar estas extensiones a `rds.allowed_delegated_extensions`. Por ejemplo, `postgres_fdw` y `dblink` proporcionan la funcionalidad de realizar consultas en todas las bases de datos de la misma instancia o de instancias remotas. `log_fdw` lee los archivos de registro del motor postgres, que son de todas las bases de datos de la instancia, y pueden contener consultas lentas o mensajes de error de varias bases de datos. `pg_cron` permite ejecutar trabajos en segundo plano programados en la instancia de base de datos y puede configurar los trabajos para que se ejecuten en una base de datos diferente.
## Eliminación de extensión en cascada deshabilitada
La posibilidad de eliminar la extensión con la opción en cascada por parte de un usuario con el rol `rds_extension` la controla el parámetro `rds.delegated_extension_allow_drop_cascade`. De forma predeterminada, `rds-delegated_extension_allow_drop_cascade` está establecido en `off`. Esto significa que los usuarios con el tol `rds_extension` no pueden eliminar una extensión mediante la opción en cascada como se muestra en la siguiente consulta.
```
DROP EXTENSION CASCADE;
```
Esto eliminará automáticamente los objetos que dependan de la extensión y, a su vez, todos los objetos que dependan de esos objetos. El intento de utilizar la opción en cascada generará un error.
Para otorgar esa habilidad, el parámetro `rds.delegated_extension_allow_drop_cascade` debe configurarse como `on`.
Cambiar el parámetro dinámico `rds.delegated_extension_allow_drop_cascade` no requiere un reinicio de la base de datos. Puede realizar esto en uno de los siguientes niveles:
+ En el clúster o en el grupo de parámetros de la instancia, a través de la Consola de administración de AWS o la API.
+ Con el siguiente comando en el nivel de la base de datos:
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ Con el siguiente comando en el nivel de usuario:
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## Ejemplos de extensiones que se pueden agregar mediante la compatibilidad de extensiones delegadas
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# Administración de las particiones de PostgreSQL con la extensión pg\$1partman
Las particiones de tablas de PostgreSQL proporcionan un marco para el manejo de alto rendimiento de la entrada de datos y la generación de informes. Utilice particiones para bases de datos que requieren una entrada muy rápida de grandes cantidades de datos. Las particiones también proporcionan consultas más rápidas de tablas grandes. Las particiones ayudan a mantener los datos sin afectar la instancia de base de datos porque requiere menos recursos de E/S.
Mediante el uso de particiones, puede dividir los datos en fragmentos de tamaño personalizado para su procesamiento. Por ejemplo, puede dividir datos de series temporales para rangos como por hora, por día, por semana, por mes, por trimestre, por año, personalizados o cualquier combinación de estos. Para un ejemplo de datos de series temporales, si divide la tabla por hora, cada partición contiene una hora de datos. Si divide la tabla de series temporales por día, las particiones contienen datos de un día, y así sucesivamente. La clave de partición controla el tamaño de una partición.
Cuando se utiliza un comando `INSERT` o `UPDATE` de SQL en una tabla particionada, el motor de base de datos enruta los datos a la partición adecuada. Las particiones de tablas de PostgreSQL que almacenan los datos son tablas secundarias de la tabla principal.
Durante las lecturas de consultas de la base de datos, el optimizador de PostgreSQL analiza la cláusula `WHERE` de la consulta y, si es posible, dirige el análisis de la base de datos solo a las particiones relevantes.
A partir de la versión 10, PostgreSQL utiliza particiones declarativas para implementar particiones de tablas. Esto también se conoce como particionado PostgreSQL nativo. Antes de PostgreSQL versión 10, usaba desencadenadores para implementar particiones.
Las particiones de tablas de PostgreSQL proporcionan las siguientes características:
+ Creación de nuevas particiones en cualquier momento.
+ Rangos de particiones variables.
+ Particiones desmontables y reconectables mediante instrucciones de lenguaje de definición de datos (DDL).
Por ejemplo, las particiones desmontables son útiles para eliminar datos históricos de la partición principal, pero mantienen los datos históricos para su análisis.
+ Las nuevas particiones heredan las propiedades de la tabla de base de datos principal, incluidas las siguientes:
+ Índices
+ Claves principales, que deben incluir la columna de la clave de partición
+ Claves externas
+ Restricciones de comprobación
+ Referencias
+ creación de índices para la tabla completa o cada partición específica
No se puede modificar el esquema de una partición individual. Sin embargo, se puede modificar la tabla principal (como agregar una nueva columna), que se propaga a las particiones.
**Topics**
+ [Información general de la extensión pg\$1partman de PostgreSQL](#PostgreSQL_Partitions.pg_partman)
+ [Habilitación de la extensión pg\$1partman](#PostgreSQL_Partitions.enable)
+ [Configuración de particiones mediante la función create\$1parent](#PostgreSQL_Partitions.create_parent)
+ [Configuración del mantenimiento de particiones mediante la función run\$1maintenance\$1proc](#PostgreSQL_Partitions.run_maintenance_proc)
## Información general de la extensión pg\$1partman de PostgreSQL
Puede utilizar la extensión `pg_partman` de PostgreSQL para automatizar la creación y el mantenimiento de las particiones de tablas. Para obtener más información general, consulte [PG Partition Manager](https://github.com/pgpartman/pg_partman) en la documentación de `pg_partman`.
**nota**
La extensión `pg_partman` es compatible con las versiones 12.5 y posteriores de RDS for PostgreSQL.
En lugar de tener que crear manualmente cada partición, configure `pg_partman` con las siguientes opciones:
+ Tabla que se dividirá
+ Tipo de partición
+ Clave de partición
+ Grado de detalle de la partición
+ Opciones de precreación y administración de particiones
Después de crear una tabla con particiones de PostgreSQL, la registra con `pg_partman` al llamar a la función `create_parent`. Al hacerlo, se crean las particiones necesarias en función de los parámetros que pase a la función.
La extensión `pg_partman` también proporciona la función `run_maintenance_proc`, que puede ejecutarse de forma programada para administrar automáticamente las particiones. Para asegurarse de que se creen las particiones apropiadas según sea necesario, programe esta función para que se ejecute periódicamente (por ejemplo, por hora). También puede asegurarse de que las particiones se eliminen automáticamente.
## Habilitación de la extensión pg\$1partman
Si tiene varias bases de datos dentro de la misma instancia de base de dato de PostgreSQL para la que desea administrar particiones, debe habilitar la extensión `pg_partman` por separado para cada base de datos. Para habilitar la extensión `pg_partman` para una base de datos específica, cree el esquema de mantenimiento de particiones y, después, cree la extensión `pg_partman` de la siguiente manera:
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**nota**
Para crear la extensión `pg_partman`, asegúrese de tener privilegios `rds_superuser`.
Si recibe un error como el siguiente, conceda los privilegios `rds_superuser` a la cuenta o utilice su cuenta de superusuario.
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
Para conceder privilegios `rds_superuser`, conéctese con su cuenta de superusuario y ejecute el siguiente comando:
```
GRANT rds_superuser TO user-or-role;
```
Para los ejemplos que muestran el uso de la extensión pg\$1partman, utilizamos la siguiente tabla de base de datos y partición de muestra. Esta base de datos utiliza una tabla particionada basada en una marca temporal. Un esquema `data_mart` contiene una tabla denominada `events` con una columna denominada `created_at`. En la `events` tabla se incluyen los siguientes ajustes:
+ Claves primarias `event_id` y `created_at`, que deben tener la columna utilizada para guiar la partición.
+ Una restricción de comprobación `ck_valid_operation` para aplicar los valores para una columna de la tabla `operation`.
+ Dos claves externas, donde una (`fk_orga_membership)` apunta a la tabla externa `organization` y la otra (`fk_parent_event_id`) es una clave externa con referencia propia.
+ Dos índices, donde uno (`idx_org_id`) es para la clave externa y el otro (`idx_event_type`) es para el tipo de evento.
Las siguientes instrucciones DDL crean estos objetos, que se incluyen automáticamente en cada partición.
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## Configuración de particiones mediante la función create\$1parent
Después de habilitar la extensión `pg_partman`, utilice la función `create_parent` para configurar las particiones dentro del esquema de mantenimiento de particiones. En este ejemplo se utiliza el ejemplo de la tabla `events` creado en [Habilitación de la extensión pg\$1partmanConfiguración del mantenimiento de particiones mediante la función run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable). Ejecute la función `create_parent` de la siguiente manera:
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
Los parámetros son los siguientes:
+ `p_parent_table` – La tabla principal particionada. Esta tabla ya debe existir y estar totalmente cualificada, incluido el esquema.
+ `p_control` – La columna en la que se basará la partición. El tipo de datos debe ser entero o basado en el tiempo.
+ `p_type`: el tipo es `'range'` o `'list'`.
+ `p_interval` – El intervalo de tiempo o intervalo de enteros para cada partición. Los valores de ejemplo incluyen `1 day`, `1 hour`, etc.
+ `p_premake` – La cantidad de particiones que se debe crear de antemano para admitir nuevas inserciones.
Para obtener una descripción completa de la función `create_parent`, consulte [Funciones de creación](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions) en la documentación de `pg_partman`.
## Configuración del mantenimiento de particiones mediante la función run\$1maintenance\$1proc
Puede ejecutar operaciones de mantenimiento de particiones para crear automáticamente nuevas particiones, desasociar particiones o eliminar particiones antiguas. El mantenimiento de particiones se basa en la función `run_maintenance_proc` de la extensión `pg_partman` y la extensión `pg_cron`, que inicia un programador interno. El programador `pg_cron` ejecuta automáticamente instrucciones SQL, funciones y procedimientos definidos en las bases de datos.
En el ejemplo siguiente se utiliza el ejemplo de la tabla `events` creado en [Habilitación de la extensión pg\$1partmanConfiguración del mantenimiento de particiones mediante la función run\$1maintenance\$1proc](#PostgreSQL_Partitions.enable) para establecer que las operaciones de mantenimiento de particiones se ejecuten automáticamente. Como requisito previo, agregue `pg_cron` al parámetro `shared_preload_libraries` en el grupo de parámetros de la instancia de base de datos.
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
A continuación, puede encontrar una explicación paso a paso del ejemplo anterior:
1. Modifique el grupo de parámetros asociado a la instancia de base de datos y agregue `pg_cron` al valor del parámetro `shared_preload_libraries`. Este cambio requiere un reinicio de la instancia de base de datos para que surta efecto. Para obtener más información, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Ejecute el comando `CREATE EXTENSION pg_cron;` con una cuenta que tenga los permisos `rds_superuser`. Esto habilita la extensión `pg_cron`. Para obtener más información, consulte [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL](PostgreSQL_pg_cron.md).
1. Ejecute el comando `UPDATE partman.part_config` para ajustar la configuración de `pg_partman` para la tabla `data_mart.events`.
1. Ejecute el comando `SET` . . . para configurar la tabla `data_mart.events`, con estas cláusulas:
1. `infinite_time_partitions = true,` – Configura la tabla para que pueda crear automáticamente nuevas particiones sin ningún límite.
1. `retention = '3 months',` – Configura la tabla para que tenga una retención máxima de tres meses.
1. `retention_keep_table=true `– Configura la tabla para que cuando venza el periodo de retención, la tabla no se elimine automáticamente. En su lugar, las particiones que son anteriores al periodo de retención solo se separan de la tabla principal.
1. Ejecute el comando `SELECT cron.schedule` . . . para hacer una llamada a la función `pg_cron`. Esta llamada define la frecuencia con la que el programador ejecuta el procedimiento de mantenimiento de `pg_partman`, `partman.run_maintenance_proc`. Para este ejemplo, el procedimiento se ejecuta cada hora.
Para obtener una descripción completa de la función `run_maintenance_proc`, consulte [Funciones de mantenimiento](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions) en la documentación de `pg_partman`.
# Uso de pgAudit para registrar la actividad de la base de datos
Las instituciones financieras, las agencias gubernamentales y muchas industrias necesitan mantener *registros de auditoría* para cumplir con los requisitos reglamentarios. Al utilizar la extensión de auditoría de PostgreSQL (PGAudit) con su Instancia de base de datos de RDS for PostgreSQL, puede capturar los registros detallados que suelen necesitar los auditores o para cumplir con los requisitos reglamentarios. Por ejemplo, puede configurar la extensión pgAudit para realizar un seguimiento de los cambios realizados en bases de datos y tablas específicas, para registrar el usuario que realizó el cambio y muchos otros detalles.
La extensión pgAudit se basa en la funcionalidad de la infraestructura de registro nativa de PostgreSQL ampliando los mensajes de registro con más detalle. En otras palabras, utiliza el mismo método para ver el registro de auditoría que para ver cualquier mensaje de registro. Para obtener más información sobre los registros de PostgreSQL, consulte [Archivos de registro de base de datos de RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
La extensión PGAudit elimina los datos confidenciales, como las contraseñas de texto no cifrado, de los registros. Si su instancia de base de datos de RDS for PostgreSQL está configurado para registrar las instrucciones del lenguaje de manipulación de datos (DML) tal como se detalla en [Activación de registro de consultas para su instancia de base de datos de RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md), puede evitar el problema de la contraseña de texto sin cifrar mediante la extensión de auditoría de PostgreSQL.
Puede configurar la auditoría en las instancias de la base de datos con un alto grado de especificidad. Puede auditar todas las bases de datos y todos los usuarios. O bien, puede optar por auditar solo determinadas bases de datos, usuarios y otros objetos. También puede excluir explícitamente a determinados usuarios y bases de datos de la auditoría. Para obtener más información, consulte [Exclusión de usuarios o bases de datos del registro de auditoría](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md).
Dada la cantidad de detalles que se pueden capturar, le recomendamos que, si usa pgAudit, controle su consumo de almacenamiento.
La extensión pgAudit es compatible con todas las Versiones de RDS para PostgreSQL: Para obtener una lista de las versiones de pgAudit compatibles con la versión de RDS para PostgreSQL, consulte [Versiones de extensión para Amazon RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) en las *Notas de la versión de Amazon RDS for PostgreSQL.*
**Topics**
+ [Configuración de la extensión pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [Auditoría de objetos de base de datos](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [Exclusión de usuarios o bases de datos del registro de auditoría](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [Referencia para la extensión pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# Configuración de la extensión pgAudit
Para configurar la extensión pgAudit en la instancia de base de datos de RDS for PostgreSQL , primero hay que añadir pgAudit a las bibliotecas compartidas en el grupo de parámetros de base de datos personalizado para su instancia de base de datos RDS for PostgreSQL. Para obtener información acerca de cómo crear el grupo de parámetros de base de datos, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md). A continuación, instale la extensión pgAudit. Por último, especifique las bases de datos y objetos que desea auditar. Los procedimientos de esta sección le muestran cómo hacerlo. Puede utilizar la Consola de administración de AWS o la AWS CLI.
Debe tener permisos como el rol `rds_superuser` para realizar todas estas tareas.
En los pasos siguientes se supone que la instancia de base de datos de RDS for PostgreSQL está asociada a un grupo de parámetros de DB.
## Consola
**Para configurar la extensión pgAudit**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija la instancia de base de datos de RDS for PostgreSQL.
1. Abra la pestaña **Configuration** (Configuración) para su Instancia de base de datos RDS para PostgreSQL. Entre los detalles de la instancia, busque el enlace del **grupo de parámetros**.
1. Elija el enlace para abrir los parámetros personalizados asociados al Instancia de base de datos RDS para PostgreSQL.
1. En el campo de búsqueda **Parametes** (Parámetros), escriba `shared_pre` para buscar el parámetro `shared_preload_libraries`.
1. Seleccione **Edit parameters** (Editar parámetros) para acceder a los valores de las propiedades.
1. Añada `pgaudit` a la lista en el campo **Values** (Valores). Utilice una coma para separar los elementos de la lista de valores.
![\[Imagen del parámetro shared_preload_libaries con pgAudit añadido.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Reinicie la instancia de base de datos de RDS for PostgreSQL para que surta efecto el cambio en el parámetro `shared_preload_libraries`.
1. Cuando la instancia esté disponible, compruebe que pgAudit se haya inicializado. Use `psql` para conectarse a la instancia de base de datos de RDS for PostgreSQL y, a continuación, ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. Con pgAudit inicializado, ahora puede crear la extensión. Debe crear la extensión después de inicializar la biblioteca, ya que la extensión `pgaudit` instala activadores de eventos para auditar las sentencias del lenguaje de definición de datos (DDL).
```
CREATE EXTENSION pgaudit;
```
1. Cierre la sesión de `psql`.
```
labdb=> \q
```
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Busque el parámetro `pgaudit.log` en la lista y configúrelo con el valor adecuado para su caso de uso. Por ejemplo, al establecer el parámetro `pgaudit.log` en `write` como se muestra en la siguiente imagen, se capturan las inserciones, las actualizaciones, las eliminaciones y algunos otros tipos de cambios en el registro.
![\[Imagen del parámetro pgaudit.log con la configuración.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/rpg_set_pgaudit-log-level.png)
También puede elegir uno de los siguientes valores para el parámetro `pgaudit.log`.
+ none: es el valor predeterminado. No se registran cambios en la base de datos.
+ all: registra todo (read, write, function, role, ddl, misc).
+ ddl: registra todas las instrucciones del lenguaje de definición de datos (DDL) que no están incluidas en la clase `ROLE`.
+ function: registra llamadas a funciones y bloques `DO`.
+ misc: registra comandos variados como, por ejemplo, `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` y `SET`.
+ read: registra `SELECT` y `COPY` cuando el origen es una relación (como una tabla) o una consulta.
+ role: registra instrucciones relacionadas con roles y privilegios, como `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` y `DROP ROLE`.
+ write: registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` y `COPY` cuando el destino es una relación (tabla).
1. Elija **Guardar cambios**.
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Elija su instancia de base de datos de RDS para PostgreSQL desde la lista de bases de datos.
## AWS CLI
**Para configurar pgAudit**
Para configurar pgAudit mediante AWS CLI, llame a la operación [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar los parámetros del registro de auditoría de su grupo de parámetros personalizado, como se muestra en el siguiente procedimiento.
1. Utilice el siguiente comando AWS CLI para añadir `pgaudit` al parámetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilice el siguiente comando AWS CLI para reiniciar la instancia de base de datos de RDS for PostgreSQL para que se inicialice la biblioteca pgaudit.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Cuando la instancia esté disponible, puede verificar si `pgaudit` se ha inicializado. Use `psql` para conectarse a la instancia de base de datos de RDS for PostgreSQL y, a continuación, ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
Con pgAudit inicializado, ahora puede crear la extensión.
```
CREATE EXTENSION pgaudit;
```
1. Cierre la sesión de `psql` para poder utilizar AWS CLI.
```
labdb=> \q
```
1. Utilice el siguiente comando AWS CLI para especificar las clases de instrucciones que desea registrar con el registro de auditoría de sesión. El ejemplo establece el parámetro `pgaudit.log` en`write`, que captura las inserciones, las actualizaciones y las eliminaciones del registro.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
También puede elegir uno de los siguientes valores para el parámetro `pgaudit.log`.
+ none: es el valor predeterminado. No se registran cambios en la base de datos.
+ all: registra todo (read, write, function, role, ddl, misc).
+ ddl: registra todas las instrucciones del lenguaje de definición de datos (DDL) que no están incluidas en la clase `ROLE`.
+ function: registra llamadas a funciones y bloques `DO`.
+ misc: registra comandos variados como, por ejemplo, `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` y `SET`.
+ read: registra `SELECT` y `COPY` cuando el origen es una relación (como una tabla) o una consulta.
+ role: registra instrucciones relacionadas con roles y privilegios, como `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` y `DROP ROLE`.
+ write: registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` y `COPY` cuando el destino es una relación (tabla).
Reinicie la instancia de base de datos de RDS for PostgreSQL mediante el siguiente comando AWS CLI.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Auditoría de objetos de base de datos
Con PGAudit configurado en su instancia de base de datos de RDS for PostgreSQL y configurado según sus requisitos, se captura información más detallada en el registro de PostgreSQL. Por ejemplo, si bien la configuración de registro predeterminada de PostgreSQL identifica la fecha y la hora en que se realizó un cambio en una tabla de base de datos, con la extensión pgAudit la entrada de registro puede incluir el esquema, el usuario que realizó el cambio y otros detalles, según cómo estén configurados los parámetros de la extensión. Puede configurar la auditoría para realizar un seguimiento de los cambios de las siguientes maneras.
+ Para cada sesión, por usuario. Para el nivel de sesión, puede capturar el texto completo del comando.
+ Para cada objeto, por usuario y por base de datos.
La capacidad de auditoría de objetos se activa cuando se crea el rol `rds_pgaudit` en el sistema y, a continuación, se agrega este rol al parámetro `pgaudit.role` del grupo de parámetros personalizados. De forma predeterminada, el parámetro `pgaudit.role` no está configurado y el único valor permitido es `rds_pgaudit`. En los siguientes pasos se asume que `pgaudit` se ha inicializado y que ha se ha creado la extensión `pgaudit` siguiendo el procedimiento descrito en [Configuración de la extensión pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).
![\[Imagen del archivo de registro de PostgreSQL después de configurar pgAudit.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/pgaudit-log-example.png)
Como se muestra en este ejemplo, la línea «LOG: AUDIT: SESSION» proporciona información sobre la tabla y su esquema, entre otros detalles.
**Para configurar la auditoría de objetos**
1. Use `psql` para conectarse a la insancia de base de tos de RDS for PostgreSQL.
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. Cree un rol de base de datos llamado `rds_pgaudit` mediante el siguiente comando.
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. Cierre la sesión de `psql`.
```
labdb=> \q
```
En los siguientes pasos, use elAWS CLI para modificar los parámetros del registro de auditoría en el grupo de parámetros personalizado.
1. Utilice el siguiente comando AWS CLI para establecer el parámetro `pgaudit.role` en `rds_pgaudit`. De forma predeterminada, este parámetro está vacío y `rds_pgaudit` es el único valor permitido.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Reinicie AWS CLIla instancia de la instancia de base de datos de RDS for PostgreSQL para que sus cambios en los parámetros surtan efecto.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Ejecute el siguiente comando para confirmar que `pgaudit.role` se establece en `rds_pgaudit`.
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
Para probar el registro de pgAudit, puede ejecutar varios comandos de ejemplo que desee auditar. Por ejemplo, podría ejecutar los siguientes comandos.
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
Los registros de base de datos contendrán una entrada similar a la siguiente.
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
Para obtener información acerca de la visualización de los registros, consulte [Supervisión de archivos de registro de Amazon RDS](USER_LogAccess.md).
Para obtener más información sobre la extensión pgAudit, consulte [pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md) en GitHub.
# Exclusión de usuarios o bases de datos del registro de auditoría
Como se explica en [Archivos de registro de base de datos de RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md), los registros de PostgreSQL consumen espacio de almacenamiento. El uso de la extensión pgAudit aumenta el volumen de datos recopilados en los registros en diversos grados, según los cambios de los que realice un seguimiento. Es posible que no necesite auditar todos los usuarios o bases de datos de su Instancia de base de datos RDS para PostgreSQL.
Para minimizar los impactos en el almacenamiento y evitar la captura innecesaria de registros de auditoría, puede excluir a los usuarios y las bases de datos de la auditoría. También puede cambiar el registro dentro de una sesión determinada. Los siguientes ejemplos muestran cola forma de hacerlo.
**nota**
La configuración de los parámetros a nivel de sesión tiene prioridad sobre la configuración del grupo de parámetros del grupo de parámetros de la base de datos personalizada para la instancia de la base de datos de RDS for PostgreSQL. Si no desea que los usuarios de la base de datos omitan los ajustes de configuración del registro de auditoría, asegúrese de cambiar sus permisos.
Supongamos que su instancia de base de datos de RDS for PostgreSQL está configurado para auditar el mismo nivel de actividad para todos los usuarios y bases de datos. A continuación, decide que no desea auditar al usuario `myuser`. Puede desactivar la auditoría de `myuser` con el siguiente comando de SQL.
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
A continuación, puede utilizar la siguiente consulta para comprobar la columna `user_specific_settings` de `pgaudit.log` para confirmar que el parámetro está establecido en `NONE`.
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
Debería ver una salida como la siguiente.
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
Puede desactivar el registro de un usuario determinado en medio de su sesión con la base de datos con el siguiente comando.
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
Utilice la siguiente consulta para comprobar la columna de configuración de pgaudit.log para una combinación específica de usuario y base de datos.
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
Se muestra una salida similar a la siguiente.
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
Tras desactivar la auditoría de `myuser`, decide que no desea realizar un seguimiento de los cambios en `mydatabase`. Puede desactivar la auditoría de esa base de datos específica mediante el siguiente comando.
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
A continuación, utilice la siguiente consulta para comprobar la columna database\$1specific\$1settings y confirmar que pgaudit.log tiene el valor NONE.
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
Debería ver una salida como la siguiente.
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
Para restablecer la configuración predeterminada de myuser, use el siguiente comando:
```
ALTER USER myuser RESET pgaudit.log;
```
Para restablecer la configuración predeterminada de una base de datos, use el siguiente comando:
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
Para restablecer el usuario y la base de datos a la configuración por defecto, utilice el siguiente comando.
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
También puede capturar eventos específicos en el registro configurando `pgaudit.log` en uno de los otros valores permitidos para el parámetro `pgaudit.log`. Para obtener más información, consulte [Lista de ajustes permitidos para el parámetro `pgaudit.log`](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings).
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# Referencia para la extensión pgAudit
Puede especificar el nivel de detalle que desea para el registro de auditoría cambiando uno o más de los parámetros que se enumeran en esta sección.
## Control del comportamiento de pgAudit
Puede controlar el registro de auditoría cambiando uno o más de los parámetros que aparecen en la tabla siguiente.
| Parámetro | Descripción |
| --- | --- |
| `pgaudit.log` | Especifica las clases de instrucciones que se registrarán mediante el registro de auditoría de sesión. Los valores permitidos incluyen ddl, function, misc, read, role, write, none, all. Para obtener más información, consulte [Lista de ajustes permitidos para el parámetro `pgaudit.log`](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings). |
| `pgaudit.log_catalog` | Cuando se activa (se establece en 1), agrega instrucciones al registro de auditoría si todas las relaciones de una instrucción se encuentran en pg\$1catalog. |
| `pgaudit.log_level` | Especifica el nivel de registro que se usará para las entradas de registro. Valores permitidos, debug5, debug4, debug3, debug2, debug1, info, notice, warning, log. |
| `pgaudit.log_parameter` | Cuando se activa (se establece en 1), los parámetros transmitidos con la instrucción se capturan en el registro de auditoría. |
| `pgaudit.log_relation` | Cuando se activa (se establece en 1), el registro de auditoría de la sesión crea una entrada de registro separada para cada relación (TABLE, VIEW, etc.) referenciada en una instrucción SELECT o DML. |
| `pgaudit.log_statement_once` | Especifica si el registro incluirá el texto de la instrucción y los parámetros con la primera entrada de registro para una combinación de instrucción o subinstrucción o con cada entrada. |
| `pgaudit.role` | Especifica el rol maestro que se usará para el registro de auditoría de objetos. La única entrada permitida es `rds_pgaudit`. |
## Lista de ajustes permitidos para el parámetro `pgaudit.log`
| Valor | Descripción |
| --- | --- |
| none | Esta es la opción predeterminada. No se registran cambios en la base de datos. |
| all | Registra todo (read, write, function, role, ddl, misc). |
| ddl | Registra todas las instrucciones del lenguaje de definición de datos (DDL) que no están incluidas en la clase `ROLE`. |
| función | Registra llamadas a funciones y bloques `DO`. |
| misc | Registra comandos variados como, por ejemplo, `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` y `SET`. |
| lectura | Registra `SELECT` y `COPY` cuando el origen es una relación (como una tabla) o una consulta. |
| rol | Registra instrucciones relacionadas con roles y privilegios, como, por ejemplo, `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` y `DROP ROLE`. |
| escritura | Registra `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` y `COPY` cuando el destino es una relación (tabla). |
Para registrar varios tipos de eventos con auditorías de sesiones, utilice una lista separada por comas. Para registrar todos los tipos de eventos, establezca `pgaudit.log` en `ALL`. Reinicie la instancia de base de datos para aplicar los cambios.
Con la auditoría de objetos, puede mejorar los registros de auditoría para que funcionen con algunas relaciones específicas. Por ejemplo, puede especificar que desea crear registros de auditoría para las operaciones `READ` en una o más tablas.
# Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL
Puede utilizar la extensión `pg_cron` de PostgreSQL para programar comandos de mantenimiento dentro de una base de datos de PostgreSQL. Para obtener más información sobre la extensión, consulte [¿Qué es pg\$1cron?](https://github.com/citusdata/pg_cron) en la documentación de pg\$1cron.
La extensión `pg_cron` es compatible con las versiones 12.5 y posteriores del motor de RDS para PostgreSQL.
Para obtener más información acerca del uso de `pg_cron`, consulte [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL para sus bases de datos de RDS para PostgreSQL o las bases de datos de Aurora PostgreSQL-Compatible Edition](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/)
**nota**
La versión de la extensión de `pg_cron` se muestra como una versión de dos dígitos, por ejemplo, 1.6, en la vista pg\$1available\$1extensions. Si bien es posible que vea versiones de tres dígitos, por ejemplo, 1.6.4 o 1.6.5, en algunos contextos, debe especificar la versión de dos dígitos al realizar una actualización de extensión.
**Topics**
+ [Configuración de la extensión pg\$1cron](#PostgreSQL_pg_cron.enable)
+ [Concesión de permisos para usuarios de base de datos para usar pg\$1cron](#PostgreSQL_pg_cron.permissions)
+ [Programación de trabajos pg\$1cron](#PostgreSQL_pg_cron.examples)
+ [Referencia para la extensión pg\$1cron](#PostgreSQL_pg_cron.reference)
## Configuración de la extensión pg\$1cron
Habilite la extensión de `pg_cron` de la siguiente manera:
1. Modifique el grupo de parámetros personalizado asociado a la instancia de base de datos de PostgreSQL agregando `pg_cron` al valor del parámetro `shared_preload_libraries`.
+ Si su instancia de base de datos de RDS para PostgreSQL utiliza el parámetro `rds.allowed_extensions` para enumerar de forma explícita las extensiones que se pueden instalar, debe añadir la extensión `pg_cron` a la lista. Solo ciertas versiones de RDS para PostgreSQL admiten el parámetro `rds.allowed_extensions`. De forma predeterminada, se permiten todas las extensiones disponibles. Para obtener más información, consulte [Restringir la instalación de extensiones de PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Reinicie la instancia de base de datos de PostgreSQL para que se apliquen los cambios en el grupo de parámetros. Para obtener más información acerca de cómo trabajar con grupos de parámetros, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Una vez reiniciada la instancia de base de datos de PostgreSQL, ejecute el siguiente comando con una cuenta que tenga permisos `rds_superuser`. Por ejemplo, si utilizó la configuración predeterminada al crear la instancia de base de datos RDS para PostgreSQL, conéctese como usuario `postgres` y cree la extensión.
```
CREATE EXTENSION pg_cron;
```
El programador `pg_cron` se establece en la base de datos de PostgreSQL predeterminada que se denomina `postgres`. Los objetos `pg_cron` se crean en esta base de datos `postgres` y todas las acciones de programación se ejecutan en esta base de datos.
1. Puede utilizar la configuración predeterminada o programar trabajos que ejecutar en otras bases de datos en la instancia de base de datos de PostgreSQL. Para programar trabajos de otras bases de datos en la instancia de base de datos de PostgreSQL, consulte el ejemplo en [Programación de un trabajo cron para una base de datos que no sea la predeterminada](#PostgreSQL_pg_cron.otherDB).
## Concesión de permisos para usuarios de base de datos para usar pg\$1cron
La instalación de la extensión `pg_cron` requiere privilegios de `rds_superuser`. Sin embargo, los permisos para usar `pg_cron` se pueden conceder (los concede un miembro del grupo/rol `rds_superuser`) a otros usuarios de la base de datos para que puedan programar sus propios trabajos. Es recomendable que conceda permisos al esquema `cron` solo según sea necesario si mejora las operaciones en su entorno de producción.
Para conceder permiso a un usuario de base de datos en el esquema `cron`, ejecute el siguiente comando:
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
Esto da permiso *db-user* para acceder al esquema de `cron` para programar trabajos cron para los objetos a los que tienen permiso de acceso. Si el usuario de la base de datos no tiene permisos, se produce un error en el trabajo tras publicar el mensaje de error en el `postgresql.log`, como se muestra a continuación:
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
En otras palabras, asegúrese de que los usuarios de bases de datos a los que se les conceden permisos en el esquema de `cron` también tengan permisos sobre los objetos (tablas, esquemas, etc.) que tienen pensado programar.
Los detalles del trabajo cron y su éxito o fracaso también se capturan en la tabla `cron.job_run_details`. Para obtener más información, consulte [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables).
## Programación de trabajos pg\$1cron
En las secciones que siguen se muestra cómo programar varias tareas de administración con trabajos `pg_cron`.
**nota**
Al crear trabajos `pg_cron`, compruebe que el valor `max_worker_processes` sea mayor que el número de `cron.max_running_jobs`. Se producirá un error en el trabajo `pg_cron` si se queda sin procesos de trabajo en segundo plano. El número predeterminado de trabajos `pg_cron` es `5`. Para obtener más información, consulte [Parámetros para administrar la extensión pg\$1cron](#PostgreSQL_pg_cron.parameters).
**Topics**
+ [Limpieza de tablas](#PostgreSQL_pg_cron.vacuum)
+ [Depuración de la tabla del historial pg\$1cron](#PostgreSQL_pg_cron.job_run_details)
+ [Registrar errores únicamente en el archivo postgresql.log](#PostgreSQL_pg_cron.log_run)
+ [Programación de un trabajo cron para una base de datos que no sea la predeterminada](#PostgreSQL_pg_cron.otherDB)
### Limpieza de tablas
En la mayoría de los casos, autovacuum maneja el mantenimiento de limpieza. Sin embargo, se recomienda programar una limpieza de una tabla específica en el momento que lo desee.
Véase también, [Uso de autovacuum de PostgreSQL en Amazon RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
A continuación, se muestra un ejemplo del uso de la función `cron.schedule` para configurar un trabajo para usar `VACUUM FREEZE` en una tabla específica todos los días a las 22:00 (GMT).
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
Una vez ejecutado el ejemplo anterior, puede comprobar del siguiente modo el historial de la `cron.job_run_details` tabla.
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
A continuación, se presenta una consulta de la tabla `cron.job_run_details` para ver los trabajos fallidos.
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
Para obtener más información, consulte [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables).
### Depuración de la tabla del historial pg\$1cron
La tabla `cron.job_run_details` contiene un historial de los trabajos cron que con el tiempo pueden volverse muy grandes. Se recomienda programar un trabajo que depure esta tabla. Por ejemplo, mantener entradas de una semana podría ser suficiente para solucionar problemas.
En el siguiente ejemplo se utiliza la función [cron.schedule](#PostgreSQL_pg_cron.schedule) para programar un trabajo que se ejecuta todos los días a la medianoche para depurar la tabla `cron.job_run_details`. El trabajo mantiene solo los últimos siete días. Utilice su cuenta de `rds_superuser` para programar el trabajo de la siguiente manera:
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
Para obtener más información, consulte [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables).
### Registrar errores únicamente en el archivo postgresql.log
Para evitar escribir en la tabla `cron.job_run_details`, modifique el grupo de parámetros asociado a la instancia de base de datos de PostgreSQL y establezca el parámetro `cron.log_run` en Off (Desactivado). La extensión `pg_cron` ya no escribe en la tabla y captura errores solo en el archivo `postgresql.log`. Para obtener más información, consulte [Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Utilice el siguiente comando para comprobar el valor del parámetro `cron.log_run`.
```
postgres=> SHOW cron.log_run;
```
Para obtener más información, consulte [Parámetros para administrar la extensión pg\$1cron](#PostgreSQL_pg_cron.parameters).
### Programación de un trabajo cron para una base de datos que no sea la predeterminada
Todos los metadatos de `pg_cron` se mantienen en la base de datos predeterminada de PostgreSQL que se denomina `postgres`. Dado que los trabajadores en segundo plano se utilizan para ejecutar los trabajos cron de mantenimiento, puede programar un trabajo en cualquiera de sus bases de datos dentro de la instancia de base de datos de PostgreSQL:
**nota**
Solo los usuarios con el rol `rds_superuser` o los privilegios `rds_superuser` pueden mostrar todos los trabajos cron en la base de datos. Los demás usuarios solo pueden ver sus propios trabajos en la tabla `cron.job`.
1. En la base de datos cron, programe el trabajo como lo hace normalmente mediante el uso de [cron.schedule](#PostgreSQL_pg_cron.schedule).
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. Como usuario con el rol `rds_superuser`, actualice la columna de base de datos para el trabajo que acaba de crear a fin de que se ejecute en otra base de datos dentro de la instancia de base de datos de PostgreSQL.
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. Verifique consultando la tabla `cron.job`.
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**nota**
En algunas situaciones, puede agregar un trabajo cron que desea ejecutar en otra base de datos. En tales casos, el trabajo podría intentar ejecutarse en la base de datos predeterminada (`postgres`) antes de actualizar la columna de la base de datos correcta. Si el nombre de usuario tiene permisos, el trabajo se ejecuta correctamente en la base de datos predeterminada.
## Referencia para la extensión pg\$1cron
Con la extensión `pg_cron`, puede utilizar los siguientes parámetros, funciones y tablas. Para obtener más información, consulte [¿Qué es pg\$1cron? ](https://github.com/citusdata/pg_cron) en la documentación de pg\$1cron.
**Topics**
+ [Parámetros para administrar la extensión pg\$1cron](#PostgreSQL_pg_cron.parameters)
+ [Referencia de función: cron.schedule](#PostgreSQL_pg_cron.schedule)
+ [Referencia de función: cron.unschedule](#PostgreSQL_pg_cron.unschedule)
+ [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables)
### Parámetros para administrar la extensión pg\$1cron
A continuación, aparece la lista de parámetros para controlar el comportamiento de la extensión `pg_cron`.
| Parámetro | Descripción |
| --- | --- |
| cron.database\$1name | La base de datos en la que se conservan los metadatos de `pg_cron`. |
| cron.host | El nombre de host que se va a conectar a PostgreSQL. No se puede modificar este valor. |
| cron.log\$1run | Registre todos los trabajos que se ejecutan en la tabla `job_run_details`. Los valores son `on` o `off`. Para obtener más información, consulte [Tablas para programar trabajos y capturar estado](#PostgreSQL_pg_cron.tables). |
| cron.log\$1statement | Registre todas las instrucciones cron antes de ejecutarlas. Los valores son `on` o `off`. |
| cron.max\$1running\$1jobs | La cantidad máxima de trabajos que se pueden ejecutar simultáneamente. |
| cron.use\$1background\$1workers | Utilice procesos de trabajo secundarios en lugar de sesiones de cliente. No se puede modificar este valor. |
Utilice el siguiente comando SQL para mostrar estos parámetros y sus valores:
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### Referencia de función: cron.schedule
Esta función programa un trabajo cron. El trabajo se programa inicialmente en la base de datos predeterminada `postgres`. La función devuelve un valor `bigint` que representa el identificador del trabajo. Para programar trabajos para que se ejecuten en otras bases de datos dentro de la instancia de base de datos de PostgreSQL, consulte el ejemplo en [Programación de un trabajo cron para una base de datos que no sea la predeterminada](#PostgreSQL_pg_cron.otherDB).
La función presenta dos formatos de sintaxis.
**Sintaxis**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**Parámetros**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Ejemplos**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### Referencia de función: cron.unschedule
Esta función elimina un trabajo cron. Puede especificar `job_name` o `job_id`. Una política se asegura de que usted es el propietario para quitar la programación del trabajo. La función devuelve un valor booleano que indica éxito o error.
La función tiene los siguientes formatos de sintaxis.
**Sintaxis**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**Parámetros**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Ejemplos**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### Tablas para programar trabajos y capturar estado
Las siguientes tablas se crean y utilizan para programar los trabajos cron y registrar la forma en la que se completaron.
| Tabla | Descripción |
| --- | --- |
| cron.job | Contiene los metadatos de cada trabajo programado. La mayoría de las interacciones con esta tabla se deben hacer mediante el uso de las funciones `cron.schedule` y `cron.unschedule`. No recomendamos conceder privilegios de actualización o inserción directamente a esta tabla. Al hacerlo, el usuario podría actualizar la columna `username` para que se ejecute como `rds-superuser`. |
| cron.job\$1run\$1details | Contiene información histórica sobre ejecuciones de trabajos programados anteriores. Esto resulta útil para investigar el estado, los mensajes devueltos y la hora de inicio y finalización de la ejecución del trabajo. Para evitar que esta tabla crezca indefinidamente, púrguela regularmente. Para ver un ejemplo, consulte [Depuración de la tabla del historial pg\$1cron](#PostgreSQL_pg_cron.job_run_details). |
# Uso de pglogical para sincronizar datos entre instancias
Todas las versiones de RDS para PostgreSQL disponibles actualmente admiten la extensión `pglogical`. La extensión pglogical es anterior a la función de replicación lógica funcionalmente similar que se introdujo en la versión 10 de PostgreSQL. Para obtener más información, consulte [Replicación lógica para Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
La extensión `pglogical` admite la replicación lógica entre dos o más Instancias de base de datos de RDS para PostgreSQL. También admite la replicación entre diferentes versiones de PostgreSQL y entre bases de datos que se ejecutan en instancias de base de datos de RDS para PostgreSQL y clústeres de bases de datos de Aurora PostgreSQL. La extensión `pglogical` utiliza un modelo de publicación y suscripción para replicar los cambios en las tablas y otros objetos, como secuencias, de un publicador a un suscriptor. Se basa en una ranura de replicación para garantizar que los cambios se sincronicen de un nodo publicador a un nodo suscriptor, que se define de la siguiente manera.
+ El *nodo publicador* es la instancia de base de datos de RDS para PostgreSQL, que es la fuente de datos que se van a replicar en otros nodos. El nodo publicador define las tablas que se van a replicar en un conjunto de publicaciones.
+ El *nodo suscriptor* es la instancia de base de datos de RDS para PostgreSQL que recibe las actualizaciones WAL del publicador. El suscriptor crea una suscripción para conectarse al publicador y obtener los datos WAL decodificados. Cuando el suscriptor crea la suscripción, se crea la ranura de replicación en el nodo del publicador.
A continuación, encontrará información sobre cómo configurar la extensión `pglogical`.
**Topics**
+ [Requisitos y limitaciones de la extensión pglogical](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [Configuración de la extensión pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [Configuración de la replicación lógica para la instancia de base de datos de RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [Restablecimiento de la replicación lógica después de una actualización principal](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [Administración de ranuras de replicación lógica para RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [Referencia de parámetros para la extensión pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## Requisitos y limitaciones de la extensión pglogical
Todas las versiones disponibles actualmente de RDS para PostgreSQL admiten la extensión `pglogical`.
Tanto el nodo publicador como el nodo suscriptor deben estar configurados para la replicación lógica.
Las tablas que desee replicar desde un publicador a un suscriptor deben tener los mismos nombres y el mismo esquema. Estas tablas también deben contener las mismas columnas y las columnas deben utilizar los mismos tipos de datos. Tanto las tablas de los publicadores como las de suscriptores deben tener las mismas claves principales. Se recomienda utilizar únicamente la PRIMARY KEY como restricción única.
Las tablas del nodo suscriptor pueden tener restricciones más permisivas que las del nodo publicador para las restricciones CHECK y NOT NULL.
La extensión `pglogical` proporciona funciones como la replicación bidireccional que no son compatibles con la función de replicación lógica integrada en PostgreSQL (versión 10 y posteriores). Para obtener más información, consulte [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Replicación bidireccional de PostgreSQL mediante pglogical).
# Configuración de la extensión pglogical
Para configurar la extensión `pglogical` en la instancia de base de datos de RDS para PostgreSQL , añada `pglogical` a las bibliotecas compartidas en el grupo de parámetros de base de datos personalizado para su instancia de base de datos de RDS para PostgreSQL. También debe establecer el valor del parámetro `rds.logical_replication` en `1` para activar la descodificación lógica. Por último, cree la extensión en la base de datos. Puede utilizar la Consola de administración de AWS o la AWS CLI para estas tareas.
Debe tener permisos como el rol `rds_superuser` para realizar estas tareas.
En los pasos siguientes se supone que su instancia de base de datos de RDS para PostgreSQL está asociada a un grupo de parámetros de base de datos personalizado. Para obtener información acerca de cómo crear el grupo de parámetros de base de datos, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
## Consola
**Para configurar la extensión pglogical**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija la instancia de base de datos de RDS for PostgreSQL.
1. Abra la pestaña **Configuration** (Configuración) para su Instancia de base de datos RDS para PostgreSQL. Entre los detalles de la instancia, busque el enlace del **grupo de parámetros**.
1. Elija el enlace para abrir los parámetros personalizados asociados al Instancia de base de datos RDS para PostgreSQL.
1. En el campo de búsqueda **Parametes** (Parámetros), escriba `shared_pre` para buscar el parámetro `shared_preload_libraries`.
1. Seleccione **Edit parameters** (Editar parámetros) para acceder a los valores de las propiedades.
1. Añada `pglogical` a la lista en el campo **Values** (Valores). Utilice una coma para separar los elementos de la lista de valores.
![\[Imagen del parámetro shared_preload_libraries con pglogical añadido.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. Busque el parámetro `rds.logical_replication` y configúrelo en `1` para activar la replicación lógica.
1. Reinicie la instancia de base de datos de RDS para PostgreSQL para que surtan efecto los cambios.
1. Cuando la instancia esté disponible, puede usar `psql` (o pgAdmin) para conectarse a la instancia de base de datos de RDS para PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Para comprobar que pglogical esté inicializado, ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. Compruebe la configuración que permite la descodificación lógica, de la siguiente manera.
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. Cree la extensión de la siguiente manera.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Seleccione **Save changes (Guardar cambios)**.
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Elija instancia de base de datos de RDS for PostgreSQL en la lista de bases de datos para seleccionarla y, a continuación, elija **Reboot** (Reiniciar) en el menú Actions (Acciones).
## AWS CLI
**Para configurar la extensión pglogical**
Para configurar pglogical mediante la AWS CLI, llame a la operación [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar determinados parámetros de su grupo de parámetros personalizado, tal como se muestra en el siguiente procedimiento.
1. Utilice el siguiente comando AWS CLI para añadir `pglogical` al parámetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilice el siguiente comando AWS CLI para configurar `rds.logical_replication` en `1` y activar la función de descodificación lógica para la Instancia de base de datos RDS para PostgreSQL.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilice el siguiente comando AWS CLI para reiniciar la instancia de base de datos de RDS para PostgreSQL para que se inicialice la biblioteca de pglogical.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Cuando la instancia esté disponible, use `psql` para conectarse a la instancia de base de datos de RDS para PostgreSQL.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Cree la extensión de la siguiente manera.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Reinicie la instancia de base de datos de RDS for PostgreSQL mediante el siguiente comando AWS CLI.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Configuración de la replicación lógica para la instancia de base de datos de RDS para PostgreSQL
En el siguiente procedimiento, se muestra cómo iniciar la replicación lógica entre dos instancias de base de datos de RDS para PostgreSQL. En los pasos, se asume que tanto el origen (publicador) como el destino (suscriptor) tienen la extensión `pglogical` configurada como se detalla en [Configuración de la extensión pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
**nota**
El `node_name` de un nodo de suscriptor no puede empezar por `rds`.
**Para crear el nodo publicador y definir las tablas que se van a replicar**
En estos pasos se asume que la instancia de base de datos de RDS para PostgreSQL tiene una base de datos que tiene una o más tablas que desea replicar en otro nodo. Debe volver a crear la estructura de tablas del publicador en el suscriptor, así que primero debe obtener la estructura de la tabla si es necesario. Para ello, utilice el metacomando de `psql` `\d tablename` y, a continuación, cree la misma tabla en la instancia del suscriptor. El siguiente procedimiento crea una tabla de ejemplo en el publicador (origen) con fines de demostración.
1. Utilice `psql` para conectarse a la instancia que tiene la tabla que desea usar como origen para los suscriptores.
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
Si no dispone de una tabla existente que desee replicar, puede crear una tabla de ejemplo de la siguiente manera.
1. Cree una tabla de ejemplo con la siguiente instrucción SQL.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Rellene la tabla con los datos generados mediante la siguiente instrucción SQL.
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. Compruebe que los datos existen en la tabla mediante la siguiente instrucción SQL.
```
SELECT count(*) FROM docs_lab_table;
```
1. Identifique esta instancia de base de datos de RDS para PostgreSQL como nodo publicador de la siguiente manera.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. Añada la tabla que desea replicar al conjunto de replicación predeterminado. Para obtener más información sobre los conjuntos de replicación, consulte [Replication sets](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) (Conjuntos de replicación) en la documentación de pglogical.
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
Se ha completado la configuración del nodo publicador. Ahora puede configurar el nodo suscriptor para recibir las actualizaciones del publicador.
**Para configurar el nodo suscriptor y crear una suscripción para recibir actualizaciones**
En estos pasos se asume que la instancia de base de datos de RDS para PostgreSQL se ha configurado con la extensión `pglogical`. Para obtener más información, consulte [Configuración de la extensión pglogical](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
1. Utilice `psql` para conectarse a la instancia en la que desea recibir actualizaciones del publicador.
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. En , la instancia de base de datos de RDS para PostgreSQL del suscriptor, cree la misma tabla que existe en el publicador. En este ejemplo, la tabla es `docs_lab_table`. Puede crear la tabla tal y como se indica a continuación.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Compruebe que esta tabla esté vacía.
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. Identifique esta instancia de base de datos de RDS para PostgreSQL como nodo suscriptor de la siguiente manera.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. Cree la suscripción.
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
Al completar este paso, los datos de la tabla del publicador se crean en la tabla del suscriptor. Para comprobar que ha ocurrido esto, utilice la siguiente consulta SQL.
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
A partir de este momento, los cambios realizados en la tabla del publicador se replicarán en la tabla del suscriptor.
# Restablecimiento de la replicación lógica después de una actualización principal
Para poder realizar una actualización de una versión principal de un instancia de base de datos de RDS para PostgreSQL que se haya configurado como nodo publicador para la replicación lógica, debe eliminar todas las ranuras de replicación, incluso las que no estén activas. Se recomienda desviar temporalmente las transacciones de la base de datos del nodo publicador, eliminar las ranuras de replicación, actualizar la instancia de base de datos de RDS para PostgreSQL y, a continuación, restablecer y reiniciar la replicación.
Las ranuras de replicación se alojan únicamente en el nodo publicador. El nodo suscriptor de RDS para PostgreSQL en un escenario de replicación lógica no tiene espacios que eliminar, pero no se puede actualizar a una versión principal mientras esté designado como nodo suscriptor con una suscripción al publicador. Antes de actualizar el nodo suscriptor de RDS para PostgreSQL, elimine la suscripción y el nodo. Para obtener más información, consulte [Administración de ranuras de replicación lógica para RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
## Determinación de que la replicación lógica se ha interrumpido
Puede determinar que el proceso de replicación se ha interrumpido consultando el nodo publicador o el nodo suscriptor de la siguiente manera.
**Para comprobar el nodo publicador**
+ Utilice `psql` para conectarse al nodo publicador y, a continuación, consulte la función `pg_replication_slots`. Anote el valor de la columna activa. Normalmente, esto devolverá `t` (true) y mostrará que la replicación está activa. Si la consulta devuelve `f` (false), indica que la replicación en el suscriptor se ha detenido.
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**Para comprobar el nodo suscriptor**
En el nodo suscriptor, puede comprobar el estado de la replicación de tres maneras diferentes.
+ Revise los registros de PostgreSQL en el nodo suscriptor para encontrar los mensajes de error. El registro identifica el error con mensajes que incluyen el código de salida 1, como se muestra a continuación.
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ Consulte la función `pg_replication_origin`. Conéctese a la base de datos en el nodo suscriptor mediante `psql` y consulte la función `pg_replication_origin` de la siguiente manera.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
Un conjunto de resultados vacío significa que la replicación se ha interrumpido. Debería ver una salida como la siguiente.
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ Consulte la función `pglogical.show_subscription_status` tal y como se muestra en el siguiente ejemplo.
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
Este resultado muestra que la replicación se ha interrumpido. Su estado es `down`. Normalmente, la salida muestra el estado como `replicating`.
Si el proceso de replicación lógica se ha interrumpido, puede restablecerla siguiendo estos pasos.
**Para restablecer la replicación lógica entre los nodos publicador y suscriptor**
Para restablecer la replicación, primero debe desconectar el suscriptor del nodo publicador y, a continuación, restablecer la suscripción, tal como se describe en estos pasos.
1. Conéctese al nodo suscriptor con `psql` de la siguiente manera.
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Desactive la suscripción mediante la función `pglogical.alter_subscription_disable`.
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. Obtenga el identificador del nodo publicador consultando el `pg_replication_origin` de la siguiente manera.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. Utilice la respuesta del paso anterior con el comando `pg_replication_origin_create` para asignar el identificador que podrá utilizar la suscripción cuando se restablezca.
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. Para activar la suscripción, introduzca su nombre con un estado de `true`, tal como se muestra en el ejemplo siguiente.
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
Compruebe el estado del nodo. Su estado debería ser `replicating`, tal y como se muestra en este ejemplo.
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
Compruebe el estado de la ranura de replicación del suscriptor en el nodo publicador. La columna `active` de la ranura debe devolver `t` (true), lo que indica que se ha restablecido la replicación.
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# Administración de ranuras de replicación lógica para RDS para PostgreSQL
Para poder realizar una actualización de una versión principal en instancia de base de datos de RDS para PostgreSQL que se utilice como nodo publicador en un escenario de replicación lógica, debe eliminar todas las ranuras de replicación de la instancia. El proceso de comprobación previa de la actualización de la versión principal le indica que la actualización no puede continuar hasta que se eliminen las ranuras disponibles.
Para eliminar ranuras de su instancia de base de datos de RDS para PostgreSQL, primero elimine la suscripción y, a continuación, elimine la ranura.
Para identificar las ranuras de replicación que se crearon con la extensión `pglogical`, inicie sesión en cada base de datos y obtenga el nombre de los nodos. Al consultar el nodo suscriptor, aparecen los nodos publicador y suscriptor en el resultado, tal como se muestra en este ejemplo.
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
Puede obtener los detalles de la suscripción con la siguiente consulta.
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
Ahora puede eliminar la suscripción de la siguiente manera.
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
Después de eliminar la suscripción, puede eliminar el nodo.
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
Puede comprobar que el nodo ya no existe de la siguiente manera.
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# Referencia de parámetros para la extensión pglogical
En la tabla verá los parámetros asociados a la extensión `pglogical`. Parámetros como `pglogical.conflict_log_level` y `pglogical.conflict_resolution` se utilizan para gestionar los conflictos de actualización. Pueden surgir conflictos cuando los cambios se realizan localmente en las mismas tablas que están suscritas a los cambios del publicador. Los conflictos también pueden producirse en varios escenarios, como la replicación bidireccional o cuando varios suscriptores replican desde el mismo publicador. Para obtener más información, consulte [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/) (Replicación bidireccional de PostgreSQL mediante pglogical).
| Parámetro | Descripción |
| --- | --- |
| pglogical.batch\$1inserts | Inserciones por lotes si es posible. No establecido de manera predeterminada. Se cambia a 1 para activarlo y a 0 para desactivarlo. |
| pglogical.conflict\$1log\$1level | Establece el nivel de registro utilizado para registrar los conflictos resueltos. Los valores permitidos son debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal y panic. |
| pglogical.conflict\$1resolution | Establece el método que se utilizará para resolver conflictos si es posible resolverlos. Los valores de cadena admitidos son error, apply\$1remote, keep\$1local, last\$1update\$1wins y first\$1update\$1wins. |
| pglogical.extra\$1connection\$1options | Opciones de conexión a añadir a todas las conexiones de los nodos pares. |
| pglogical.synchronous\$1commit | valor de confirmación sincrónica específico de pglogical |
| pglogical.use\$1spi | Utilice la SPI (interfaz de programación de servidores) en lugar de la API de nivel inferior para aplicar los cambios. Se establece en 1 para activarlo y en 0 para desactivarlo. Para obtener más información acerca de la SPI, consulte [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) (Interfaz de programación de servidores) en la documentación de PostgreSQL. |
# Uso de pgactive para admitir la replicación activa-activa
La extensión `pgactive` utiliza la replicación activa-activa para admitir y coordinar las operaciones de escritura en varias bases de datos de RDS para PostgreSQL. Amazon RDS para PostgreSQL admite la extensión `pgactive` en las siguientes versiones:
+ RDS para PostgreSQL, versiones 17.0 y todas las posteriores
+ RDS para PostgreSQL 16.1 y versiones 16 posteriores
+ RDS para PostgreSQL 15.2-R2 y versiones 15 posteriores
+ RDS para PostgreSQL 14.10 y versiones 14 posteriores
+ RDS para PostgreSQL 13.13 y versiones 13 posteriores
+ RDS para PostgreSQL 12.17 y versiones 12 posteriores
+ RDS para PostgreSQL 11.22
**nota**
Cuando hay operaciones de escritura en más de una base de datos en una configuración de replicación, es posible que surjan conflictos. Para obtener más información, consulte [Gestión de conflictos en la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
**Topics**
+ [Limitaciones de la extensión pgactive](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [Inicialización de la capacidad de la extensión pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [Configuración de la replicación activa-activa para las instancias de base de datos de RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [Medición del retraso de réplica entre miembros de pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [Configuración de los ajustes de parámetros para la extensión pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [Comprensión de conflictos activo-activo](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [Descripción del esquema de pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [Referencia de funciones de pgactive](pgactive-functions-reference.md)
+ [Gestión de conflictos en la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [Gestión de secuencias en la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## Limitaciones de la extensión pgactive
+ Todas las tablas requieren una clave principal; de lo contrario, no se permiten operaciones para actualizar ni eliminar. Los valores de la columna de clave principal no deberían actualizarse.
+ Las secuencias pueden tener huecos y, a veces, es posible que no sigan un orden. Las secuencias no se replican. Para obtener más información, consulte [Gestión de secuencias en la replicación activa-activa](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md).
+ Los DDL y los objetos grandes no se replican.
+ Los índices únicos secundarios pueden provocar divergencias en los datos.
+ La intercalación debe ser idéntica en todos los nodos del grupo.
+ El equilibrador de carga entre los nodos es un antipatrón.
+ Las transacciones grandes pueden provocar retardos en la replicación.
# Inicialización de la capacidad de la extensión pgactive
Para inicializar la capacidad de la extensión `pgactive` en la instancia de base de datos de RDS para PostgreSQL, defina el valor del parámetro `rds.enable_pgactive` en `1` y, a continuación, cree la extensión en la base de datos. Al hacerlo, se activan automáticamente los parámetros `rds.logical_replication` `track_commit_timestamp` y se establece el valor de `wal_level` en `logical`.
Debe tener permisos como el rol `rds_superuser` para realizar estas tareas.
Puede usar la Consola de administración de AWS o la AWS CLI para crear las instancias de base de datos de RDS para PostgreSQL necesarias. En los pasos siguientes, se supone que la instancia de base de datos de RDS para PostgreSQL está asociada a un grupo de parámetros de base de datos personalizado. Para obtener información sobre la creación de un grupo de parámetros de base de datos personalizado, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
## Consola
**Para inicializar la capacidad de la extensión pgactive**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija su instancia de base de datos de RDS para PostgreSQL.
1. Abra la pestaña **Configuración** para su instancia de base de datos de RDS para PostgreSQL. En los detalles de la instancia, busque el enlace **Grupo de parámetros de instancia de base de datos**.
1. Elija el enlace para abrir los parámetros personalizados asociados a la instancia de base de datos de RDS para PostgreSQL.
1. Busque el parámetro `rds.enable_pgactive` y configúrelo en `1` para inicializar la capacidad `pgactive`.
1. Seleccione **Save changes (Guardar cambios)**.
1. En el panel de navegación de la consola de Amazon RDS, elija **Bases de datos**.
1. Seleccione su instancia de base de datos de RDS para PostgreSQL y, a continuación, seleccione **Reinicio** en el menú **Acciones**.
1. Confirme el reinicio de la instancia de base de datos para que sus cambios se apliquen.
1. Cuando la instancia de base de datos esté disponible, podrá utilizar `psql` o cualquier otro cliente de PostgreSQL para conectarse a la instancia de base de datos de RDS para PostgreSQL.
En el siguiente ejemplo, se asume que su instancia de base de datos de RDS para PostgreSQL tiene una base de datos predeterminada llamada *postgres*.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Para comprobar que pgactive esté inicializado, ejecute el siguiente comando.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Si `pgactive` está en `shared_preload_libraries`, el comando anterior devolverá lo siguiente:
```
?column?
----------
t
```
## AWS CLI
**Para inicializar la capacidad de la extensión pgactive**
Para inicializar `pgactive` utilizando la AWS CLI, llame a la operación [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) para modificar determinados parámetros de su grupo de parámetros personalizado, tal como se muestra en el siguiente procedimiento.
1. Utilice el siguiente comando de la AWS CLI para configurar `rds.enable_pgactive` en `1` para inicializar la capacidad `pgactive` de la instancia de base de datos de RDS para PostgreSQL.
```
postgres=>aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.enable_pgactive,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Utilice el siguiente comando de la AWS CLI para reiniciar la instancia de base de datos de RDS para PostgreSQL para que se inicialice la biblioteca de `pgactive`.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Cuando la instancia esté disponible, use `psql` para conectarse a la instancia de base de datos de RDS para PostgreSQL.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. Para comprobar que pgactive esté inicializado, ejecute el siguiente comando.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Si `pgactive` está en `shared_preload_libraries`, el comando anterior devolverá lo siguiente:
```
?column?
----------
t
```
# Configuración de la replicación activa-activa para las instancias de base de datos de RDS para PostgreSQL
En el siguiente procedimiento, se muestra cómo iniciar la replicación activo-activo entre dos instancias de base de datos de RDS para PostgreSQL donde `pgactive` esté disponible. Para ejecutar el ejemplo de alta disponibilidad multirregión, debe implementar instancias de Amazon RDS para PostgreSQL en dos regiones diferentes y configurar la interconexión de VPC. Para obtener más información, consulte [Interconexión de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
**nota**
El envío de tráfico entre varias regiones puede conllevar costes adicionales.
En estos pasos, se asume que la instancia de base de datos de RDS para PostgreSQL se ha habilitado con la extensión `pgactive`. Para obtener más información, consulte [Inicialización de la capacidad de la extensión pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
**Para configurar la primera instancia de base de datos de RDS para PostgreSQL con la extensión `pgactive`**
En el siguiente ejemplo, se ilustra cómo se crea el grupo `pgactive`, junto con otros pasos necesarios para crear la extensión `pgactive` en la instancia de base de datos de RDS para PostgreSQL.
1. Utilice `psql` u otra herramienta de cliente para conectarse a su primera instancia de base de datos de RDS para PostgreSQL.
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Cree una base de datos en la instancia de RDS para PostgreSQL mediante el siguiente comando:
```
postgres=> CREATE DATABASE app;
```
1. Cambie la conexión a la nueva base de datos mediante el siguiente comando:
```
\c app
```
1. Cree y rellene una tabla de ejemplo utilizando las siguientes instrucciones SQL:
1. Cree una tabla de ejemplo con la siguiente instrucción SQL.
```
app=> CREATE SCHEMA inventory;
CREATE TABLE inventory.products (
id int PRIMARY KEY, product_name text NOT NULL,
created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP);
```
1. Rellene la tabla con algunos datos de ejemplo mediante la siguiente instrucción SQL.
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. Compruebe que los datos existen en la tabla mediante la siguiente instrucción SQL.
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. Cree la extensión `pgactive` en la base de datos existente.
```
app=> CREATE EXTENSION pgactive;
```
1. Para crear e inicializar el grupo pgactive use los siguientes comandos:
```
app=>
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
Ahora puede inicializar el grupo de replicación y agregar esta primera instancia:
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Utilice los siguientes comandos como método alternativo, aunque menos seguro, para crear e inicializar el grupo pgactive:
```
app=> SELECT pgactive.pgactive_create_group(
node_name := 'node1-app',
node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node1-app es el nombre que se asigna para identificar de forma exclusiva un nodo del grupo `pgactive`.
**nota**
Para realizar este paso correctamente en una instancia de base de datos de acceso público, debe activar el parámetro `rds.custom_dns_resolution` configurándolo en `1`.
1. Para comprobar si la instancia de base de datos está lista, utilice el siguiente comando:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Si el comando se ejecuta correctamente, verá el siguiente resultado:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**Para configurar la segunda instancia de RDS para PostgreSQL y unirla al grupo `pgactive`**
En el siguiente ejemplo, se ilustra cómo puede unir una instancia de base de datos de RDS para PostgreSQL al grupo `pgactive`, junto con otros pasos necesarios para crear la extensión `pgactive` en la instancia de base de datos.
En estos pasos se asume que otras instancias de base de datos de RDS para PostgreSQL se han configurado con la extensión `pgactive`. Para obtener más información, consulte [Inicialización de la capacidad de la extensión pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
1. Utilice `psql` para conectarse a la instancia en la que desea recibir actualizaciones del publicador.
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Cree una base de datos en la segunda instancia de base de datos de RDS para PostgreSQL mediante el siguiente comando:
```
postgres=> CREATE DATABASE app;
```
1. Cambie la conexión a la nueva base de datos mediante el siguiente comando:
```
\c app
```
1. Cree la extensión `pgactive` en la base de datos existente.
```
app=> CREATE EXTENSION pgactive;
```
1. Una la segunda instancia de base de datos de RDS para PostgreSQL al grupo `pgactive` de una forma más segura mediante los siguientes comandos:
```
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
```
SELECT pgactive.pgactive_join_group(
node_name := 'endpoint2-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint2',
join_using_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Utilice los siguientes comandos como método alternativo, aunque menos seguro, para unir la segunda instancia de base de datos de RDS para PostgreSQL al grupo `pgactive`
```
app=> SELECT pgactive.pgactive_join_group(
node_name := 'node2-app',
node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD',
join_using_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node2-app es el nombre que se asigna para identificar de forma exclusiva un nodo del grupo `pgactive`.
1. Para comprobar si la instancia de base de datos está lista, utilice el siguiente comando:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Si el comando se ejecuta correctamente, verá el siguiente resultado:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Si la primera base de datos de RDS para PostgreSQL es relativamente grande, puede ver que `pgactive.pgactive_wait_for_node_ready()`emite el informe de progreso de la operación de restauración. El resultado tiene un aspecto similar al siguiente:
```
NOTICE: restoring database 'app', 6% of 7483 MB complete
NOTICE: restoring database 'app', 42% of 7483 MB complete
NOTICE: restoring database 'app', 77% of 7483 MB complete
NOTICE: restoring database 'app', 98% of 7483 MB complete
NOTICE: successfully restored database 'app' from node node1-app in 00:04:12.274956
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
A partir de este momento, `pgactive` sincroniza los datos entre las dos instancias de base de datos.
1. Puede utilizar el siguiente comando para comprobar si la base de datos de la segunda instancia de base de datos contiene los datos:
```
app=> SELECT count(*) FROM inventory.products;
```
Si los datos se sincronizan correctamente, verá el siguiente resultado:
```
count
-------
3
```
1. Ejecute el siguiente comando para insertar nuevos valores:
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. Conéctese a la base de datos de la primera instancia de base de datos y ejecute la siguiente consulta:
```
app=> SELECT count(*) FROM inventory.products;
```
Si se inicializa la replicación activa-activa, el resultado es similar al siguiente:
```
count
-------
4
```
**Para separar y eliminar una instancia de base de datos del grupo `pgactive`**
Para separar y eliminar una instancia de base de datos del grupo `pgactive`, siga estos pasos:
1. Puede separar la segunda instancia de base de datos de la primera instancia de base de datos mediante el siguiente comando:
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. Elimine la extensión `pgactive` de la segunda instancia de base de datos mediante el siguiente comando:
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
Para eliminar la extensión a la fuerza:
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. Suelte la extensión con el siguiente comando:
```
app=> DROP EXTENSION pgactive;
```
# Medición del retraso de réplica entre miembros de pgactive
Puede utilizar la siguiente consulta para ver el retraso de réplica entre los miembros de `pgactive`. Ejecute esta consulta en todos los nodos de `pgactive` para obtener una idea completa.
```
app=> SELECT * FROM pgactive.pgactive_get_replication_lag_info();
│-[ RECORD 1 ]--------+---------------------------------------------
│node_name | node2-app
│node_sysid | 7481018224801653637
│application_name | pgactive:7481018224801653637:send
│slot_name | pgactive_16385_7481018224801653637_0_16385__
│active | t
│active_pid | 783486
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/2108150
│confirmed_flush_lsn | 0/2154690
│sent_lsn | 0/2154690
│write_lsn | 0/2154690
│flush_lsn | 0/2154690
│replay_lsn | 0/2154690
│-[ RECORD 2 ]--------+---------------------------------------------
│node_name | node1-app
│node_sysid | 7481018033434600853
│application_name | pgactive:7481018033434600853:send
│slot_name | pgactive_16385_7481018033434600853_0_16385__
│active | t
│active_pid | 783488
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/20F5AD0
│confirmed_flush_lsn | 0/214EF68
│sent_lsn | 0/214EF68
│write_lsn | 0/214EF68
│flush_lsn | 0/214EF68
│replay_lsn | 0/214EF68
```
Supervise los siguientes diagnósticos como mínimo:
active
Configure alertas cuando el valor activo sea falso, lo que indica que la ranura no está en uso actualmente (la instancia del suscriptor se ha desconectado del publicador).
pending\$1wal\$1decoding
En la replicación lógica de PostgreSQL, los archivos WAL se almacenan en formato binario. El publicador debe decodificar estos cambios de WAL y convertirlos en cambios lógicos (como operaciones de inserción, actualización o eliminación).
La métrica pending\$1wal\$1decoding muestra el número de archivos WAL que esperan que los descodifique el publicador.
Este número puede aumentar debido a estos factores:
+ Cuando el suscriptor no esté conectado, el estado activo será falso y pending\$1wal\$1decoding aumentará
+ La ranura está activa, pero el publicador no puede mantenerse al día con el volumen de cambios de WAL
pending\$1wal\$1to\$1apply
La métrica pending\$1wal\$1apply indica el número de archivos WAL que esperan aplicarse en el suscriptor.
Varios factores pueden impedir que el suscriptor aplique los cambios y potencialmente causar un escenario de disco lleno:
+ Diferencias de esquema: por ejemplo, cuando hay cambios en el flujo de WAL de una tabla llamada ejemplo, pero esa tabla no existe en el suscriptor
+ Se actualizaron los valores en las columnas de la clave principal
+ Los índices únicos secundarios pueden provocar divergencias en los datos
# Configuración de los ajustes de parámetros para la extensión pgactive
Puede utilizar la siguiente consulta para ver todos los parámetros asociados a la extensión `pgactive`.
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
Puede configurar la extensión `pgactive` mediante varios parámetros. Estos parámetros se pueden configurar mediante Consola de administración de AWS o la interfaz de la CLI de AWS.
## Parámetros de extensión de pgactive principales
La siguiente tabla proporciona una referencia para los principales parámetros de la extensión `pgactive`:
| Parámetro | Unidad | Predeterminado | Descripción |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | Registra la información completa de la tupla de la extensión `pgactive`. Es necesario reiniciar el servidor para que se apliquen los cambios. |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | Determina si la extensión `pgactive` registra los conflictos detectados en la tabla `pgactive.pgactive_conflict_history`. Para obtener más información, consulte registro de conflictos. Es necesario reiniciar el servidor para que se apliquen los cambios. |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | Determina si la extensión `pgactive` registra los conflictos detectados en el archivo de registro de PostgreSQL. Para obtener más información, consulte registro de conflictos. Es necesario reiniciar el servidor para que se apliquen los cambios. |
| pgactive.synchronous\$1commit | `boolean` | apagar | Determina el comportamiento de confirmación de los trabajadores de aplicación de pgactive. Cuando está desactivado, los trabajadores de aplicación realizan confirmaciones asíncronas, lo que mejora el rendimiento de PostgreSQL durante las operaciones de aplicación, pero retrasa las confirmaciones de reproducción hacia el nodo ascendente. Establecerlo en `off` siempre es seguro y no provocará pérdidas ni omisiones de transacciones. Esta configuración solo afecta al momento de las descargas a disco en el nodo descendente y cuándo se envían las confirmaciones al nodo ascendente. El sistema retrasa el envío de las confirmaciones de vaciado de reproducción hasta que las confirmaciones se vuelcan al disco mediante operaciones no relacionadas, como puntos de control o trabajos periódicos. Sin embargo, si el nodo ascendente tiene el nodo descendente en `synchronous_standby_names`, establecerlo en `off` hace que las confirmaciones sincrónicas en el nodo ascendente tarden más en informar del éxito al cliente. En este caso, establezca el parámetro en `on`. Incluso cuando este parámetro se establece en `on` con nodos en `synchronous_standby_names`, pueden producirse conflictos de replicación en las configuraciones activo-activo. Esto se debe a que el sistema carece de bloqueo entre nodos y de gestión global de instantáneas, lo que permite que las transacciones concurrentes en distintos nodos modifiquen la misma tupla. Además, las transacciones solo comienzan a replicarse después de confirmarse en el nodo ascendente. La habilitación de la confirmación sincrónica no transforma la extensión pgactive en un sistema siempre coherente. |
| pgactive.temp\$1dump\$1directory | `string` | – | Define la ruta de almacenamiento temporal necesaria para las operaciones de clonación de bases de datos durante la configuración inicial. En este directorio debe poder escribir el usuario de postgres y debe tener suficiente espacio de almacenamiento para contener un volcado completo de la base de datos. El sistema utiliza esta ubicación solo durante la configuración inicial de la base de datos con operaciones de copia lógica. Este parámetro no lo usa `pgactive_init_copy command`. |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | Especifica el tiempo máximo de espera para el bloqueo de DDL antes de interrumpir por la fuerza las transacciones de escritura simultáneas. El valor predeterminado es `-1`, que adopta el valor establecido en `max_standby_streaming_delay`. Este parámetro acepta unidades de tiempo. Por ejemplo, puede configurarlo en 10 s para 10 segundos. Durante este periodo de espera, el sistema intenta adquirir bloqueos de DDL mientras espera a que las transacciones de escritura en curso se confirmen o se reviertan. Para obtener más información, consulte Bloqueos de DDL. |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | Especifica cuánto tiempo espera un intento de bloqueo de DDL para obtener el bloqueo. El valor predeterminado es `-1`, que utiliza el valor especificado en lock\$1timeout. Puede configurar este parámetro mediante unidades de tiempo como 10 s para 10 segundos. Este temporizador solo controla el periodo de espera para obtener un bloqueo de DDL. Una vez que el sistema obtiene el bloqueo e inicia la operación de DDL, el temporizador se detiene. Este parámetro no limita la duración total que puede mantenerse un bloqueo de DDL ni el tiempo total de la operación de DDL. Para controlar la duración total de la operación, utilice `statement_timeout` en su lugar. Para obtener más información, consulte Bloqueos de DDL. |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | Invalida el nivel de registro de depuración predeterminado para las operaciones de bloqueo de DDL en la extensión `pgactive`. Cuando se configura, esta configuración hace que los mensajes relacionados con el bloqueo de DDL se emitan en el nivel de depuración LOG en lugar de en su nivel predeterminado. Utilice este parámetro para supervisar la actividad de bloqueo de DDL sin activar los niveles de registro detallados `DEBUG1` o `DEBUG2` en todo el servidor. Niveles de registro disponibles, en orden creciente de detalle: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Para obtener más información acerca de las opciones de supervisión, consulte Supervisión de bloqueos de DDL globales. Los cambios en esta configuración surten efecto al volver a cargar la configuración. No es necesario reiniciar el servidor. |
## Parámetros de extensión de pgactive adicionales
La siguiente tabla presenta las opciones de configuración interna y las que se utilizan con menos frecuencia disponibles para la extensión `pgactive`.
| Parámetro | Unidad | Predeterminado | Descripción |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | Establece un retraso de aplicación (en milisegundos) para las conexiones configuradas que no tienen un retraso de aplicación explícito en su entrada `pgactive.pgactive_connections`. Este retraso se establece durante la creación o la unión del nodo, y pgactive no reproducirá una transacción en los nodos del mismo nivel hasta que hayan transcurrido al menos el número especificado de milisegundos desde que se confirmó. Se utiliza principalmente para simular redes de alta latencia en entornos de prueba para facilitar la creación de conflictos. Por ejemplo, con un retraso de 500 ms en los nodos A y B, dispone de al menos 500 ms para realizar una inserción conflictiva en el nodo B tras insertar un valor en el nodo A. Requiere una recarga del servidor o un reinicio de los trabajadores de aplicación para que surta efecto. |
| pgactive.connectability\$1check\$1duration | `integer` | – | Especifica la duración (en segundos) durante la cual un trabajador de base de datos intenta establecer conexiones durante los intentos erróneos. El trabajador realiza un intento de conexión por segundo hasta que tiene éxito o alcanza este valor de tiempo de espera. Esta configuración resulta útil cuando el motor de base de datos se inicia antes de que el trabajador esté preparado para establecer conexiones. |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | Controla cómo se replican o gestionan los cambios de DDL en Amazon RDS con `pgactive` habilitado. Cuando se establece en `on`, el nodo procesa los cambios de DDL como un nodo no pgactive. Los siguientes requisitos se aplican al trabajar con este parámetro: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Puede modificar este parámetro de dos formas con privilegios de superusuario: de forma global o local (nivel de sesión). Si se cambia este parámetro de forma incorrecta, se pueden interrumpir las configuraciones de replicación. |
| pgactive.do\$1not\$1replicate | `boolean` | – | Este parámetro es solo para uso interno. Cuando se establece este parámetro en una transacción, los cambios no se replican en otros nodos del clúster de base de datos. Si se cambia este parámetro de forma incorrecta, se pueden interrumpir las configuraciones de replicación. |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | Este parámetro está destinado solo a uso especializado. Recomendamos usar este parámetro solo para solucionar problemas de replicación específicos. Utilice este parámetro cuando: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Esta configuración invalida el siguiente mensaje de error y permite que surja una divergencia de datos para permitir que la replicación continúe: `cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute` Si se cambia este parámetro de forma incorrecta, se pueden interrumpir las configuraciones de replicación. |
| pgactive.debug\$1trace\$1replay | `boolean` | – | Cuando se establece en `on`, emite un mensaje de registro para cada acción remota que se aplique posteriormente al proceso de los trabajadores. Los registros incluyen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Los registros también capturan los comandos de DDL en cola y las tablas descartadas.para> De forma predeterminada, los registros no incluyen el contenido de los campos de fila. Para incluir valores de fila en los registros, debe volver a compilarlos con los siguientes indicadores habilitados: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) La habilitación de esta configuración de registro puede afectar al rendimiento. Recomendamos habilitarla solo cuando sea necesario para solucionar problemas. Los cambios en esta configuración surten efecto al volver a cargar la configuración. No es necesario reiniciar el servidor. |
| pgactive.extra\$1apply\$1connection\$1options | | – | Puede configurar los parámetros de conexión para todas las conexiones de nodos del mismo nivel con los nodos de pgactive. Estos parámetros controlan ajustes como keepalive y los modos SSL. De forma predeterminada, pgactive utiliza los siguientes parámetros de conexión: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Para invalidar los parámetros predeterminados, utilice el siguiente comando similar: pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' Las cadenas de conexión de los nodos individuales tienen prioridad sobre estas configuraciones y sobre las opciones de conexión integradas de pgactive. Para obtener más información acerca de los formatos de cadenas de conexión, consulte [cadenas de conexión libpq](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). Recomendamos mantener habilitada la configuración predeterminada de keepalive. Desactive keepalive solo si tiene problemas al realizar grandes transacciones a través de redes poco fiables. Recomendamos mantener habilitada la configuración predeterminada de keepalive. Desactive keepalive solo si tiene problemas al realizar grandes transacciones a través de redes poco fiables. Los cambios en esta configuración surten efecto al volver a cargar la configuración. No es necesario reiniciar el servidor. |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | Especifica el número de trabajos paralelos que `pg_dump` y `pg_restore` pueden utilizar durante las uniones de nodos lógicos con la función `pgactive.pgactive_join_group`. Los cambios en esta configuración surten efecto al volver a cargar la configuración. No es necesario reiniciar el servidor. |
| pgactive.max\$1nodes | `int` | 4 | Especifica el número máximo de nodos permitidos en un grupo de extensiones de pgactive. El valor predeterminado es 4 nodos. Debe tener en cuenta lo siguiente al configurar el valor de este parámetro: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Puede configurar este parámetro de dos maneras: en el archivo de configuración, mediante el comando `ALTER SYSTEM SET` El valor predeterminado de este parámetro es `4`, lo que significa que puede haber un máximo de 4 nodos permitidos en el grupo de extensiones de `pgactive` en cualquier momento. El cambio surtirá efecto después de reiniciar el servidor. |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | Este parámetro está destinado solo a uso interno. Cuando está habilitada, la extensión `pgactive` permite la creación de la función de obtención del identificador de nodo de pgactive. |
# Comprensión de conflictos activo-activo
Cuando se utiliza pgactive en el modo activo-activo, escribir en las mismas tablas desde varios nodos puede crear conflictos de datos. Aunque algunos sistemas de agrupación en clústeres utilizan bloqueos distribuidos para evitar el acceso simultáneo, pgactive adopta un enfoque optimista que se adapta mejor a las aplicaciones distribuidas geográficamente.
Algunos sistemas de agrupación en clústeres de bases de datos impiden el acceso simultáneo a los datos mediante el uso de bloqueos distribuidos. Aunque este enfoque funciona cuando los servidores están muy cerca, no admite aplicaciones distribuidas geográficamente porque requiere una latencia extremadamente baja para lograr un buen rendimiento. En lugar de utilizar bloqueos distribuidos (un enfoque pesimista), la extensión pgactive utiliza un enfoque optimista. Esto significa que:
+ Ayuda a evitar conflictos cuando es posible.
+ Permite que se produzcan determinados tipos de conflictos.
+ Proporciona resolución de conflictos cuando se producen conflictos.
Este enfoque le proporciona más flexibilidad a la hora de crear aplicaciones distribuidas.
## Cómo se producen los conflictos
Los conflictos entre nodos surgen de secuencias de eventos que no podrían ocurrir si todas las transacciones implicadas se produjeran simultáneamente en el mismo nodo. Como los nodos solo intercambian cambios una vez confirmadas las transacciones, cada transacción es válida individualmente en el nodo en el que se ha confirmado, pero no lo sería si se ejecutara en otro nodo que haya realizado otras tareas mientras tanto. Dado que la aplicación de pgactive básicamente reproduce la transacción en los demás nodos, la operación de reproducción puede producir un error si hay un conflicto entre una transacción que se está aplicando y una transacción que se ha confirmado en el nodo receptor.
La razón por la que la mayoría de los conflictos no se producen cuando todas las transacciones se ejecutan en un único nodo es que PostgreSQL cuenta con mecanismos de comunicación entre transacciones para evitarlos, entre los que se incluyen:
+ Índices UNIQUE
+ SEQUENCE
+ Bloqueo de filas y relaciones
+ Seguimiento de dependencias SERIALIZABLE
Todos estos mecanismos son formas de comunicarse entre transacciones para evitar problemas de concurrencia no deseados
pgactive logra una baja latencia y maneja bien las particiones de la red porque no utiliza un administrador de transacciones distribuido o un administrador de bloqueos. Sin embargo, esto significa que las transacciones en diferentes nodos se ejecutan completamente aisladas unas de otras. Aunque el aislamiento suele mejorar la coherencia de la base de datos, en este caso es necesario reducir el aislamiento para evitar conflictos.
## Tipos de conflictos
Los conflictos que se pueden producir son:
**Topics**
+ [Conflictos de PRIMARY KEY o UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [Conflictos INSERT/INSERT](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [INSERT que infringen múltiples restricciones UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [Conflictos UPDATE/UPDATE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [Conflictos UPDATE en la PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [UPDATE que infringen varias restricciones UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [Conflictos UPDATE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [Conflictos INSERT/UPDATE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [Conflictos DELETE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [Conflictos de restricciones de clave externa](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [Conflictos de restricciones de exclusión](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [Conflictos de datos globales](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [Conflictos de bloqueo y anulaciones de bloqueo](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [Conflictos divergentes](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### Conflictos de PRIMARY KEY o UNIQUE
Los conflictos de filas se producen cuando varias operaciones intentan modificar la misma clave de fila de formas que no son posibles en un solo nodo. Estos conflictos representan el tipo más común de conflictos de datos.
pgactive resuelve los conflictos detectados mediante el manejo de last-update-wins o el gestor de conflictos personalizado.
Los conflictos de filas incluyen:
+ INSERT frente a INSERT
+ INSERT frente a UPDATE
+ UPDATE frente a DELETE
+ INSERT frente a DELETE
+ DELETE frente a DELETE
+ INSERT frente a DELETE
### Conflictos INSERT/INSERT
El conflicto más común se produce cuando los INSERT en dos nodos diferentes crean una tupla con los mismos valores de PRIMARY KEY (o valores de restricción UNIQUE idénticos cuando no existe ninguna PRIMARY KEY).
pgactivelink resuelve los conflictos de INSERT utilizando la marca temporal del host de origen para conservar la tupla más reciente. Puede invalidar este comportamiento predeterminado con el controlador de conflictos personalizado. Aunque este proceso no requiere ninguna acción especial del administrador, tenga en cuenta que pgactivelink descarta una de las operaciones INSERT en todos los nodos. No se produce una fusión automática de datos a menos que el controlador personalizado la implemente.
pgactivelink solo puede resolver conflictos que impliquen una única violación de restricción. Si un INSERT infringe varias restricciones UNIQUE, debe implementar estrategias adicionales de resolución de conflictos.
### INSERT que infringen múltiples restricciones UNIQUE
Un conflicto INSERT/INSERT puede infringir varias restricciones UNIQUE, incluida la PRIMARY KEY. pgactivelink solo puede gestionar conflictos que impliquen una única restricción UNIQUE. Cuando los conflictos infringen varias restricciones UNIQUE, el trabajador de aplicación produce un error y devuelve el siguiente error:
`multiple unique constraints violated by remotely INSERTed tuple.`
En versiones anteriores, esta situación generaba un error de "conflicto de unicidad divergente" en su lugar.
Para resolver estos conflictos, debe tomar medidas manuales. O bien DELETE las tuplas locales en conflicto o UPDATE las mismas para eliminar los conflictos con la nueva tupla remota. Tenga en cuenta que puede que tenga que abordar varias tuplas conflictivas. Actualmente, pgactivelink no proporciona ninguna funcionalidad integrada para ignorar, descartar o fusionar las tuplas que infringen múltiples restricciones únicas.
**nota**
Para obtener más información, consulte UPDATE que infringen varias restricciones UNIQUE.
### Conflictos UPDATE/UPDATE
Este conflicto se produce cuando dos nodos modifican simultáneamente la misma tupla sin cambiar su PRIMARY KEY. pgactivelink resuelve estos conflictos mediante la lógica last-update-wins o el controlador de conflictos personalizado, si está definido. Una PRIMARY KEY es esencial para la coincidencia de tuplas y la resolución de conflictos. En el caso de las tablas sin una PRIMARY KEY, pgactivelink rechaza las operaciones UPDATE con el siguiente error:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### Conflictos UPDATE en la PRIMARY KEY
Pgactive tiene limitaciones a la hora de gestionar las actualizaciones de PRIMARY KEY. Aunque puede realizar la operación UPDATE en una PRIMARY KEY, pgactive no puede resolver automáticamente los conflictos utilizando la lógica last-update-wins para estas operaciones. Debe asegurarse de que las actualizaciones de la PRIMARY KEY no entren en conflicto con los valores existentes. Si se producen conflictos durante las actualizaciones de PRIMARY KEY, se convierten en conflictos divergentes que requieren su intervención manual. Para obtener más información acerca de cómo manejar estas situaciones, consulte [Conflictos divergentes](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATE que infringen varias restricciones UNIQUE
pgactivelink no puede aplicar la resolución de conflictos last-update-wins cuando una UPDATE entrante infringe varias restricciones UNIQUE o valores de PRIMARY KEY. Este comportamiento es similar a las operaciones INSERT con múltiples infracciones de restricciones. Estas situaciones crean conflictos divergentes que requieren su intervención manual. Para obtener más información, consulte [Conflictos divergentes](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### Conflictos UPDATE/DELETE
Estos conflictos se producen cuando un nodo realiza una UPDATE en una fila mientras que otro nodo la DELETE simultáneamente. En este caso, se produce un conflicto UPDATE/DELETE durante la reproducción. La solución consiste en descartar cualquier UPDATE que llegue después de una DELETE, a menos que el gestor de conflictos personalizado especifique lo contrario.
pgactivelink requiere una PRIMARY KEY para hacer coincidir las tuplas y resolver los conflictos. Para las tablas sin una PRIMARY KEY, rechaza las operaciones DELETE con el siguiente error:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**nota**
pgactivelink no puede distinguir entre los conflictos de UPDATE/DELETE e INSERT/UPDATE. En ambos casos, una UPDATE afecta a una fila que no existe. Debido a la replicación asíncrona y a la falta de orden de reproducción entre los nodos, pgactivelink no puede determinar si la UPDATE es para una fila nueva (aún no se ha recibido INSERT) o para una fila eliminada. En ambos casos, pgactivelink descarta la UPDATE.
### Conflictos INSERT/UPDATE
Este conflicto se puede producir en entornos de varios nodos. Ocurre cuando un nodo INSERT una fila, un segundo nodo la UPDATE y un tercer nodo recibe la UPDATE antes que el INSERT original. De forma predeterminada, pgactivelink resuelve estos conflictos descartando la UPDATE, a menos que el desencadenador de conflictos personalizado especifique lo contrario. Tenga en cuenta que este método de resolución puede provocar incoherencias en los datos entre los nodos. Para obtener más información acerca de escenarios similares y su manejo, consulte [Conflictos UPDATE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7).
### Conflictos DELETE/DELETE
Este conflicto se produce cuando dos nodos diferentes eliminan simultáneamente la misma tupla. pgactivelink considera que estos conflictos son inofensivos porque ambas operaciones DELETE tienen el mismo resultado final. En este escenario, pgactivelink ignora de forma segura una de las operaciones DELETE sin afectar a la coherencia de datos.
### Conflictos de restricciones de clave externa
Las restricciones de FOREIGN KEY pueden provocar conflictos al aplicar transacciones remotas a los datos locales existentes. Estos conflictos suelen producirse cuando las transacciones se aplican en una secuencia diferente a su orden lógico en los nodos de origen.
De forma predeterminada, pgactive aplica los cambios con session\$1replication\$1role como `replica`, lo que evita las comprobaciones de claves externas durante la replicación. En las configuraciones activo-activo, esto puede provocar infracciones de claves externas. La mayoría de las infracciones son temporales y se resuelven una vez que la replicación se pone al día. Sin embargo, pueden producirse claves externas huérfanas porque pgactive no admite el bloqueo de filas entre nodos.
Este comportamiento es inherente a los sistemas activo-activo asíncronos tolerantes a las particiones. Por ejemplo, el nodo A puede insertar una nueva fila secundaria mientras que el nodo B elimina simultáneamente su fila principal. El sistema no puede impedir este tipo de modificación concurrente entre nodos.
Para minimizar los conflictos de claves externas, recomendamos lo siguiente:
+ Limitar las relaciones de claves externas a entidades estrechamente relacionadas.
+ Modificar las entidades relacionadas desde un solo nodo cuando sea posible.
+ Elegir entidades que rara vez requieran modificación.
+ Implementar un control de concurrencia en el nivel de aplicación para las modificaciones.
### Conflictos de restricciones de exclusión
pgactive link no admite restricciones de exclusión y restringe su creación.
**nota**
Si convierte una base de datos independiente existente en una base de datos de pgactivelink, elimine manualmente todas las restricciones de exclusión.
En un sistema asíncrono distribuido, no es posible garantizar que ningún conjunto de filas infrinja la restricción. Esto se debe a que todas las transacciones en los distintos nodos están completamente aisladas. Las restricciones de exclusión pueden provocar bloqueos de reproducción, donde la reproducción no puede avanzar de un nodo a otro debido a infracciones de las restricciones de exclusión.
Si obliga a pgactive Link a crear una restricción de exclusión o si no elimina las existentes al convertir una base de datos independiente en pgactive Link, es probable que la replicación se interrumpa. Para restaurar el progreso de la replicación, elimine o modifique las tuplas locales que entren en conflicto con una tupla remota entrante para poder aplicar la transacción remota.
### Conflictos de datos globales
Cuando se utiliza pgactivelink, se pueden producir conflictos cuando los nodos tienen diferentes datos globales de todo el sistema PostgreSQL, como los roles. Estos conflictos pueden provocar que las operaciones (principalmente DDL) se ejecuten correctamente en un nodo, pero que no se apliquen a otros nodos.
Si un usuario existe en un nodo pero no en otro, pueden producirse problemas de replicación:
+ Node1 tiene un nombre de usuario `fred`, pero este usuario no existe en Node2
+ Cuando `fred` crea una tabla en Node1, la tabla se replica con `fred` como el propietario
+ Cuando este comando de DDL se aplica al Node2, se produce un error porque el usuario `fred` no existe
+ Este error genera un ERROR en los registros de PostgreSQL en Node2 e incrementa el contador `pgactive.pgactive_stats.nr_rollbacks`
**Solución:** cree el usuario `fred` en Node2. El usuario no necesita permisos idénticos, sino que debe existir en ambos nodos.
Si existe una tabla en un nodo pero no en otro, las operaciones de modificación de datos producirán un error:
+ Node1 tiene una tabla llamada `foo` que no existe en Node2
+ Cualquier operación de DML en la tabla `foo` en el Node1 producirá un error cuando se replique en Node2
**Solución:** cree la tabla `foo` en el Node2 con la misma estructura.
**nota**
Actualmente, pgactivelink no replica los comandos CREATE USER ni las operaciones de DDL. La replicación de DDL está prevista para una versión futura.
### Conflictos de bloqueo y anulaciones de bloqueo
Como los procesos de aplicación de pgactive funcionan como sesiones de usuario normales, siguen las reglas estándar de bloqueo de filas y tablas. Esto puede provocar que los procesos de aplicación de pgactivelink esperen por bloqueos mantenidos por transacciones de usuarios o por otros procesos de aplicación.
Los siguientes tipos de bloqueos pueden afectar a los procesos de aplicación:
+ Bloqueo explícito en el nivel de tabla (LOCK TABLE...) por sesiones de usuario
+ Bloqueo explícito en el nivel de fila (SELECT ... FOR UPDATE/FOR SHARE) por sesiones de usuario
+ Bloqueo desde claves foráneas
+ Bloqueo implícito debido a UPDATE, INSERT o DELETE de filas, ya sea por actividad local o aplicación desde otros servidores
Los bloqueos pueden ocurrir entre:
+ Un proceso de aplicación de pgactivelink y una transacción de usuario
+ Dos procesos de aplicación
Cuando se producen bloqueos, el detector de bloqueos de PostgreSQL finaliza una de las transacciones problemáticas. Si se termina el proceso del trabajador de aplicación de pgactivelink, este reintenta automáticamente y normalmente tiene éxito.
**nota**
Estos problemas son temporales y generalmente no requieren la intervención del administrador. Si un proceso de aplicación está bloqueado durante un periodo prolongado por un bloqueo en una sesión de usuario inactiva, puede terminar la sesión de usuario para reanudar la replicación. Esta situación es similar a cuando un usuario mantiene un bloqueo prolongado que afecta a la sesión de otro usuario.
Para identificar los retrasos en la reproducción relacionados con el bloqueo, habilite la instalación `log_lock_waits` en PostgreSQL.
### Conflictos divergentes
Los conflictos divergentes se producen cuando los datos que deberían ser idénticos en todos los nodos difieren inesperadamente. Aunque estos conflictos no se deberían producir, no todos se pueden prevenir de forma fiable con la implementación actual.
**nota**
La modificación de PRIMARY KEY de una fila puede provocar conflictos divergentes si otro nodo cambia la clave de la misma fila antes de que todos los nodos procesen el cambio. Evite cambiar las claves principales o restrinja los cambios a un nodo designado. Para obtener más información, consulte [Conflictos UPDATE en la PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5).
Los conflictos divergentes relacionados con los datos de las filas suelen requerir la intervención del administrador. Para resolver estos conflictos, debe ajustar manualmente los datos de un nodo para que coincidan con otro mientras desactiva temporalmente la replicación mediante `pgactive.pgactive_do_not_replicate`. Estos conflictos no se deberían producir cuando se utiliza pgactive tal como se ha documentado y se evitan las configuraciones o funciones marcadas como inseguras.
Como administrador, debe resolver estos conflictos manualmente. En función del tipo de conflicto, necesitará utilizar opciones avanzadas como `pgactive.pgactive_do_not_replicate`. Use estas opciones con precaución, ya que un uso incorrecto puede empeorar la situación. Debido a la variedad de posibles conflictos, no podemos proporcionar instrucciones de resolución universales.
Los conflictos divergentes se producen cuando los datos que deberían ser idénticos en diferentes nodos difieren inesperadamente. Aunque estos conflictos no deberían producirse, no todos se pueden prevenir de forma fiable con la implementación actual.
## Evitar o tolerar los conflictos
En la mayoría de los casos, puede utilizar un diseño de aplicación adecuado para evitar conflictos o hacer que la aplicación tolere los conflictos.
Los conflictos solo se producen cuando se realizan operaciones simultáneas en varios nodos. Para evitar conflictos:
+ Escriba solo en un nodo
+ Escriba en subconjuntos de bases de datos independientes en cada nodo (por ejemplo, asigne a cada nodo un esquema independiente)
Para conflictos entre INSERT e INSERT, utilice secuencias globales para evitar conflictos por completo.
Si los conflictos no son aceptables para su caso de uso, considere implementar el bloqueo distribuido a nivel de aplicación. A menudo, el mejor enfoque es diseñar la aplicación para que funcione con los mecanismos de resolución de conflictos de pgactive en lugar de intentar prevenir todos los conflictos. Para obtener más información, consulte [Tipos de conflictos](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes).
## Registro de conflictos
pgactivelink registra los incidentes de conflicto en la tabla `pgactive.pgactive_conflict_history` para ayudarle a diagnosticar y gestionar los conflictos activo-activo. El registro de conflictos en esta tabla solo se produce cuando se establece `pgactive.log_conflicts_to_table` en verdadero. La extensión pgactive también registra los conflictos en el archivo de registro de PostgreSQL cuando log\$1min\$1messages se establece en `LOG` o `lower`, independientemente de la configuración de `pgactive.log_conflicts_to_table`.
Utilice la tabla del historial de conflictos para:
+ Medir la frecuencia con la que la aplicación crea conflictos
+ Identificar dónde se producen los conflictos
+ Mejorar la aplicación para reducir las tasas de conflictos
+ Detectar casos en los que las resoluciones de conflictos no producen los resultados deseados
+ Determinar dónde necesita desencadenantes de conflictos definidos por el usuario o cambios en el diseño de la aplicación
Para los conflictos de filas, puede registrar opcionalmente los valores de las filas. Esto se controla mediante la configuración de `pgactive.log_conflicts_to_table`. Tenga en cuenta que:
+ Esta es una opción global para toda la base de datos
+ No hay ningún control por tabla sobre el registro de valores de fila
+ No se aplican límites a los números de campo, los elementos de matriz o las longitudes de los campos
+ Puede que no sea recomendable activar esta característica si trabaja con filas de varios megabytes que podrían desencadenar conflictos
Como la tabla del historial de conflictos contiene datos de todas las tablas de la base de datos (cada una con posibles esquemas diferentes), los valores de las filas registradas se almacenan como campos JSON. El JSON se crea mediante `row_to_json`, de forma similar a llamarlo directamente desde SQL. PostgreSQL no proporciona una función `json_to_row`, por lo que necesitará código específico de tabla (en PL/pgSQL, PL/Python, PL/Perl, etc.) para reconstruir una tupla de tipo compuesto a partir del JSON registrado.
**nota**
La compatibilidad para conflictos definidos por el usuario está planificada como una característica de extensión futura.
# Descripción del esquema de pgactive
El esquema de pgactive administra la replicación activo-activo en RDS para PostgreSQL. Este esquema contiene tablas que almacenan información sobre la configuración y el estado de la replicación.
**nota**
El esquema de pgactive está en evolución y está sujeto a cambios. No modifique los datos de estas tablas directamente.
Las tablas de claves del esquema de pgactive incluyen:
+ `pgactive_nodes`: almacena información sobre los nodos del grupo de replicación activo-activo.
+ `pgactive_connections`: almacena los detalles de conexión de cada nodo.
## pgactive\$1nodes
pgactive\$1nodes almacena información sobre los nodos que participan en el grupo de replicación activo-activo.
| Columna | Tipo | Collation (Intercalación) | Nullable | Predeterminado |
| --- | --- | --- | --- | --- |
| node\$1sysid | text | – | not null | – |
| node\$1timeline | oid | – | not null | – |
| node\$1dboid | oid | – | not null | – |
| node\$1status | char | – | not null | – |
| node\$1name | text | – | not null | – |
| node\$1dsn | text | – | not null | – |
| node\$1init\$1from\$1dsn | text | – | not null | – |
| node\$1read\$1only | valor booleano | – | – | false |
| node\$1seq\$1id | smallint | – | not null | – |
**node\$1sysid**
ID único para un nodo, generado durante `pgactive_create_group` o `pgactive_join_group`
**node\$1status**
Preparación del nodo:
+ **b**: configuración inicial
+ **i**: inicio
+ **c**: recuperación
+ **o**: creación de ranuras de salida
+ **r**: listo
+ **k**: interrumpido
Esta columna no indica si un nodo está conectado o desconectado.
**node\$1name**
Nombre de nodo único proporcionado por el usuario.
**node\$1dsn**
Cadena de conexión o nombre de mapeo de usuario
**node\$1init\$1from\$1dsn**
DSN a partir del cual se creó este nodo.
## pgactive\$1connection
pgactive\$1connections almacena los detalles de conexión de cada nodo.
| Columna | Tipo | Collation (Intercalación) | Nullable | Predeterminado |
| --- | --- | --- | --- | --- |
| conn\$1sysid | text | none | not null | none |
| conn\$1timeline | oid | none | not null | none |
| conn\$1dboid | oid | none | not null | none |
| conn\$1dsn | text | none | not null | none |
| conn\$1apply\$1delay | entero | none | none | none |
| conn\$1replication\$1sets | text | none | none | none |
conn\$1sysid
Identificador de nodo del nodo al que hace referencia esta entrada.
conn\$1dsn
Igual que pgactive.pgactive\$1nodes `node_dsn`.
conn\$1apply\$1delay
Si se establece, milisegundos que hay que esperar antes de aplicar cada transacción desde el nodo remoto. Principalmente para depurar. Si es nulo, se aplica el valor predeterminado global.
## Uso de conjuntos de replicación
Los conjuntos de replicación determinan qué tablas incluir o excluir de las operaciones de replicación. De forma predeterminada, todas las tablas se replican a menos que especifique lo contrario mediante las siguientes funciones:
+ `pgactive_exclude_table_replication_set()`: excluye las tablas especificadas de la replicación
+ `pgactive_include_table_replication_set()`: incluye las tablas especificadas en la replicación
**nota**
Antes de configurar los conjuntos de replicación, tenga en cuenta lo siguiente:
Puede configurar la inclusión o exclusión de tablas solo después de ejecutar `pgactive_create_group()` pero antes de `pgactive_join_group()`.
Después de usar `pgactive_exclude_table_replication_set()`, no puede usar `pgactive_include_table_replication_set()`.
Después de usar `pgactive_include_table_replication_set()`, no puede usar `pgactive_exclude_table_replication_set()`.
El sistema gestiona las tablas recién creadas de forma diferente en función de la configuración inicial:
+ Si excluyó las tablas: todas las tablas nuevas que se creen después de `pgactive_join_group()` se incluyen automáticamente en la replicación
+ Si incluyó las tablas: todas las tablas nuevas que se creen después de `pgactive_join_group()` se excluyen automáticamente de la replicación.
Para ver la configuración del conjunto de réplicas de una tabla específica, utilice la función `pgactive.pgactive_get_table_replication_sets()`.
# Referencia de funciones de pgactive
A continuación, puede encontrar una lista de funciones de pgactive con sus parámetros, valores de devolución y notas prácticas de uso para ayudarle a utilizarlas de forma eficaz:
## get\$1last\$1applied\$1xact\$1info
Recupera la información de la última transacción aplicada a un nodo específico.
**Arguments**
+ sysid (texto): OID de línea temporal
+ dboid (OID)
**Tipo de devolución**
Hace lo siguiente:
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (marca temporal con zona horaria)
+ last\$1applied\$1xact\$1at (marca temporal con zona horaria)
**Notas de uso**
Use esta función para recuperar la información de la última transacción aplicada a un nodo específico.
## pgactive\$1apply\$1pause
Pausa el proceso de aplicación de la replicación.
**Arguments**
Ninguno
**Tipo de devolución**
booleano
**Notas de uso**
Llame a esta función para pausar el proceso de aplicación de la replicación.
## pgactive\$1apply\$1resume
Reanuda el proceso de aplicación de la replicación.
**Arguments**
Ninguno
**Tipo de devolución**
void
**Notas de uso**
Llame a esta función para reanudar el proceso de aplicación de la replicación.
## pgactive\$1is\$1apply\$1paused
Comprueba si la aplicación de la replicación está actualmente en pausa.
**Arguments**
Ninguno
**Tipo de devolución**
booleano
**Notas de uso**
Use esta función para comprobar si la aplicación de la replicación está actualmente en pausa.
## pgactive\$1create\$1group
Crea un grupo pgactive convirtiendo una base de datos independiente en el nodo inicial.
**Arguments**
+ node\$1name (texto)
+ node\$1dsn (texto)
+ apply\$1delay integer DEFAULT NULL::integer - replication\$1sets text[] DEFAULT ARRAY[‘default’::text]
**Tipo de devolución**
void
**Notas de uso**
Crea un grupo pgactive convirtiendo una base de datos independiente en el nodo inicial. La función realiza comprobaciones de integridad antes de transformar el nodo en un nodo de pgactive. Antes de usar esta función, asegúrese de que el clúster de PostgreSQL tenga suficientes `max_worker_processes` disponibles para admitir los trabajadores en segundo plano de pgactive.
## pgactive\$1detach\$1nodes
Elimina los nodos especificados del grupo pgactive.
**Arguments**
+ p\$1nodes (text[])
**Tipo de devolución**
void
**Notas de uso**
Use esta función para eliminar los nodos especificados del grupo pgactive.
## pgactive\$1exclude\$1table\$1replication\$1set
Excluye una tabla específica de la replicación.
**Arguments**
+ p\$1relation (regclass)
**Tipo de devolución**
void
**Notas de uso**
Utilice esta función para excluir una tabla específica de la replicación.
## pgactive\$1get\$1replication\$1lag\$1info
Recupera información detallada sobre el retraso de la replicación, incluidos los detalles del nodo, el estado de WAL y los valores de LSN.
**Arguments**
Ninguno
**Tipo de devolución**
SETOF record - node\$1name text - node\$1sysid text - application\$1name text - slot\$1name text - active boolean - active\$1pid integer - pending\$1wal\$1decoding bigint - Tamaño aproximado de WAL en bytes que se decodificará en el nodo emisor - pending\$1wal\$1to\$1apply bigint - Tamaño aproximado del WAL en bytes que se aplicará en el nodo receptor - restart\$1lsn pg\$1lsn - confirmed\$1flush\$1lsn pg\$1lsn - sent\$1lsn pg\$1lsn - write\$1lsn pg\$1lsn - flush\$1lsn pg\$1lsn - replay\$1lsn pg\$1lsn
**Notas de uso**
Llame a esta función para recuperar información sobre el retraso de la replicación, incluidos los detalles del nodo, el estado de WAL y los valores de LSN.
## pgactive\$1get\$1stats
Recupera las estadísticas de replicación de pgactive.
**Arguments**
Ninguno
**Tipo de devolución**
SETOF record - rep\$1node\$1id oid - rilocalid oid - riremoteid text - nr\$1commit bigint - nr\$1rollback bigint - nr\$1insert bigint - nr\$1insert\$1conflict bigint - nr\$1update bigint - nr\$1update\$1conflict bigint - nr\$1delete bigint - nr\$1delete\$1conflict bigint - nr\$1disconnect bigint
**Notas de uso**
Utilice esta función para recuperar las estadísticas de replicación de pgactive.
## pgactive\$1get\$1table\$1replication\$1sets
Obtiene la configuración del conjunto de replicación de una relación específica.
**Arguments**
+ relación (regclass)
**Tipo de devolución**
Registro SETOF
**Notas de uso**
Llame a esta función para obtener la configuración del conjunto de replicación de una relación específica.
## pgactive\$1include\$1table\$1replication\$1set
Incluye una tabla específica en la replicación.
**Arguments**
+ p\$1relation (regclass)
**Tipo de devolución**
void
**Notas de uso**
Utilice esta función para incluir una tabla específica en la replicación.
## pgactive\$1join\$1group
Agrega un nodo a un grupo pgactive existente.
**Arguments**
+ node\$1name (texto)
+ node\$1dsn (texto)
+ join\$1using\$1dsn (texto)
+ apply\$1delay (entero, opcional)
+ replication\$1sets (text[], predeterminado: ['default'])
+ bypass\$1collation\$1check (booleano, predeterminado: falso)
+ bypass\$1node\$1identifier\$1creation (booleano, predeterminado: falso)
+ bypass\$1user\$1tables\$1check (booleano, predeterminado: falso)
**Tipo de devolución**
void
**Notas de uso**
Llame a esta función para agregar un nodo a un grupo pgactive existente. Asegúrese de que el clúster de PostgreSQL tenga suficientes max\$1worker\$1processes para los trabajadores en segundo plano de pgactive.
## pgactive\$1remove
Elimina todos los componentes de pgactive del nodo local.
**Arguments**
+ force (booleano, predeterminado: falso)
**Tipo de devolución**
void
**Notas de uso**
Llame a esta función para eliminar todos los componentes de pgactive del nodo local.
## pgactive\$1snowflake\$1id\$1nextval
Genera valores de secuencia únicos específicos del nodo.
**Arguments**
+ regclass
**Tipo de devolución**
bigint
**Notas de uso**
Utilice esta función para generar valores de secuencia únicos específicos del nodo.
## pgactive\$1update\$1node\$1conninfo
Actualiza la información de conexión de un nodo de pgactive.
**Arguments**
+ node\$1name\$1to\$1update (texto)
+ node\$1dsn\$1to\$1update (texto)
**Tipo de devolución**
void
**Notas de uso**
Use esta función para actualizar la información de conexión de un nodo de pgactive.
## pgactive\$1wait\$1for\$1node\$1ready
Supervisa el progreso de las operaciones de creación o unión de grupos.
**Arguments**
+ timeout (entero, predeterminado: 0)
+ progress\$1interval (entero, predeterminado: 60)
**Tipo de devolución**
void
**Notas de uso**
Llame a esta función para supervisar el progreso de las operaciones de creación o unión de grupos.
# Gestión de conflictos en la replicación activa-activa
La extensión `pgactive` funciona por base de datos y no por clúster. Cada instancia de base de datos que utiliza `pgactive` es una instancia independiente y puede aceptar cambios de datos de cualquier fuente. Cuando se envía un cambio a una instancia de base de datos, PostgreSQL lo confirma localmente y, a continuación, utiliza `pgactive` para replicar el cambio de forma asíncrona en otras instancias de base de datos. Cuando dos instancias de base de datos de PostgreSQL actualizan el mismo registro prácticamente al mismo tiempo, puede producirse un conflicto.
La extensión `pgactive` proporciona mecanismos para la detección y la resolución automática de conflictos. Realiza un seguimiento de la marca de tiempo en que se confirmó la transacción en ambas instancias de base de datos y aplica automáticamente el cambio con la última marca de tiempo. La extensión `pgactive` también registra cuando se produce un conflicto en la tabla `pgactive.pgactive_conflict_history`.
El `pgactive.pgactive_conflict_history` seguirá creciendo. Puede definir una política de depuración. Esto se puede hacer borrando algunos registros de forma regular o definiendo un esquema de partición para esta relación (y, luego, separando, descartando o truncando las particiones de interés). Para implementar la política de depuración de forma regular, una opción es usar la extensión `pg_cron` Consulte la siguiente información con un ejemplo para la tabla de historial de `pg_cron` [Programación de mantenimiento con la extensión pg\$1cron de PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html).
# Gestión de secuencias en la replicación activa-activa
Una instancia de base de datos de RDS para PostgreSQL con la extensión `pgactive` utiliza dos mecanismos de secuencia diferentes para generar valores únicos.
**Secuencias globales**
Para usar una secuencia global, cree una secuencia local con la instrucción `CREATE SEQUENCE`. Utilice `pgactive.pgactive_snowflake_id_nextval(seqname)` en lugar de `usingnextval(seqname)` para obtener el siguiente valor único de la secuencia.
En el siguiente ejemplo se crea una secuencia global.
```
app=> CREATE TABLE gstest (
id bigint primary key,
parrot text
);
```
```
app=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
```
```
app=> ALTER TABLE gstest \
ALTER COLUMN id SET DEFAULT \
pgactive.pgactive_snowflake_id_nextval('gstest_id_seq');
```
**Secuencias particionadas**
En las secuencias divididas o particionadas, se utiliza una secuencia PostgreSQL normal en cada nodo. Cada secuencia se incrementa en la misma cantidad y comienza con diferentes desplazamientos. Por ejemplo, con el paso 100, el nodo 1 genera una secuencia como 101, 201, 301, etc., y el nodo 2 genera una secuencia como 102, 202, 302, etc. Este esquema funciona bien incluso si los nodos no pueden comunicarse durante períodos prolongados, pero requiere que el diseñador especifique un número máximo de nodos al establecer el esquema y requiere una configuración por nodo. Los errores pueden provocar fácilmente la superposición de secuencias.
Es relativamente sencillo configurar este enfoque con `pgactive` creando la secuencia deseada en un nodo de la siguiente manera:
```
CREATE TABLE some_table (generated_value bigint primary key);
```
```
app=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
```
```
app=> ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval('some_seq');
```
A continuación, llame a `setval` en cada nodo para dar un valor inicial de desplazamiento diferente, de la siguiente manera.
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```
# Reducción de la sobrecarga en tablas e índices con la extensión pg\$1repack
Puede usar la extensión `pg_repack` para eliminar el sobredimensionamiento de las tablas y los índices como alternativa a `VACUUM FULL`. Esta extensión es compatible con RDS para las versiones 9.6.3 y superiores de PostgreSQL. Para obtener más información acerca de la extensión `pg_repack` y el reempaquetado de tablas completo, consulte la [documentación del proyecto de GitHub](https://reorg.github.io/pg_repack/).
A diferencia de lo que ocurre con `VACUUM FULL`, la extensión `pg_repack` requiere un bloqueo exclusivo (AccessExclusiveLock) por un breve período de tiempo durante la operación de reconstrucción de la tabla en los siguientes casos:
+ Creación inicial de la tabla de registro: se crea una tabla de registro para registrar los cambios que se producen durante la copia inicial de los datos, como se muestra en el siguiente ejemplo:
```
postgres=>\dt+ repack.log_*
List of relations
-[ RECORD 1 ]-+----------
Schema | repack
Name | log_16490
Type | table
Owner | postgres
Persistence | permanent
Access method | heap
Size | 65 MB
Description |
```
+ Fase final de intercambio y eliminación.
Para el resto de la operación de reconstrucción, solo se necesita un bloqueo `ACCESS SHARE` en la tabla original para copiar sus filas a la nueva tabla. Esto ayuda a que las operaciones INSERT, UPDATE y DELETE continúen como de costumbre.
## Recomendaciones
Las siguientes recomendaciones se aplican al eliminar el sobredimensionamiento de las tablas e índices mediante la extensión `pg_repack`:
+ Realice el reempaquetado fuera del horario laboral o durante un período de mantenimiento para minimizar su impacto en el rendimiento de otras actividades de la base de datos.
+ Monitorice de cerca las sesiones de bloqueo durante la actividad de reconstrucción y asegúrese de que no haya ninguna actividad en la tabla original que pueda bloquear `pg_repack`, especialmente durante la fase final de intercambio y eliminación, cuando es necesario bloquear exclusivamente la tabla original. Para obtener más información, consulte [Identificar qué bloquea una consulta](https://repost.aws/knowledge-center/rds-aurora-postgresql-query-blocked).
Si ve una sesión que bloquee, puede finalizarla mediante el siguiente comando tras estudiarla detenidamente. Esto ayuda a continuar con `pg_repack` para terminar la reconstrucción:
```
SELECT pg_terminate_backend(pid);
```
+ Al aplicar los cambios acumulados de la tabla de registro `pg_repack's` en sistemas con una tasa de transacciones muy alta, es posible que el proceso de solicitud no pueda mantener la tasa de cambios. En esos casos, `pg_repack` no podría completar el proceso de aplicación. Para obtener más información, consulte [Monitorización de la nueva tabla durante el reempaquetado](#Appendix.PostgreSQL.CommonDBATasks.pg_repack.Monitoring). Si los índices están muy sobredimensionados, una solución alternativa es volver a empaquetar únicamente los índices. Esto también ayuda a que los ciclos de limpieza de índices de VACUUM finalicen más rápido.
Puede omitir la fase de limpieza de índices mediante el VACUUM manual de la versión 12 de PostgreSQL, y se omite automáticamente durante el autovacuum de emergencia de la versión 14 de PostgreSQL. Esto ayuda a que VACUUM se complete más rápido sin eliminar el sobredimensionamiento del índice y solo está diseñado para situaciones de emergencia, como evitar que el VACUUM se acumule. Para obtener más información, consulte [Evitar la sobrecarga en los índices](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html#AuroraPostgreSQL.diag-table-ind-bloat.AvoidinginIndexes) en la Guía del usuario de Amazon Aurora.
## Requisitos previos
+ La tabla debe tener una restricción de PRIMARY KEY o una UNIQUE que no sea null.
+ La versión de la extensión debe ser la misma tanto para el cliente como para el servidor.
+ Asegúrese de que la instancia de RDS tenga más `FreeStorageSpace` que el tamaño total de la tabla sin la sobrecarga. Como ejemplo, considere el tamaño total de la tabla, incluidos el TOAST y los índices, como de 2 TB, y el tamaño total de la tabla como 1 TB. El `FreeStorageSpace` requerido debe ser superior al valor devuelto por el siguiente cálculo:
`2TB (Table size)` - `1TB (Table bloat)` = `1TB`
Puede utilizar la siguiente consulta para comprobar el tamaño total de la tabla y utilizar `pgstattuple` para derivar la sobrecarga. Para obtener más información, consulte [Diagnóstico de sobrecarga de tablas e índices](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html) en la Guía del usuario de Amazon Aurora.
```
SELECT pg_size_pretty(pg_total_relation_size('table_name')) AS total_table_size;
```
Este espacio se recupera una vez finalizada la actividad.
+ Asegúrese de que la instancia de RDS tenga suficiente capacidad de procesamiento y E/S para gestionar la operación de reempaquetado. Podría considerar la posibilidad de escalar verticalmente la clase de instancia para lograr un equilibrio óptimo del rendimiento.
**Para usar la extensión `pg_repack`**
1. Instale la extensión `pg_repack` en la instancia de base de datos de RDS for PostgreSQL con el siguiente comando.
```
CREATE EXTENSION pg_repack;
```
1. Ejecute los siguientes comandos para conceder acceso de escritura a las tablas de registro temporales creadas por `pg_repack`.
```
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
```
1. Conéctese a la base de datos mediante la utilidad de cliente `pg_repack`. Utilice una cuenta que tenga privilegios `rds_superuser`. Por ejemplo, suponga que ese rol `rds_test` tiene privilegios `rds_superuser`. La siguiente sintaxis realiza `pg_repack` para tablas completas, incluidos todos los índices de tablas de la base de datos `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres
```
**nota**
Debe conectarse usando la opción -k. La opción -a no se admite.
La respuesta del cliente `pg_repack` proporciona información relativa a las tablas de la instancia de base de datos que se han vuelto a empaquetar.
```
INFO: repacking table "pgbench_tellers"
INFO: repacking table "pgbench_accounts"
INFO: repacking table "pgbench_branches"
```
1. La siguiente sintaxis vuelve a empaquetar una sola tabla `orders`, incluidos los índices de la base de datos `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders -k postgres
```
La siguiente sintaxis reempaqueta solo los índices de la tabla `orders` de la base de datos `postgres`.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres
```
## Monitorización de la nueva tabla durante el reempaquetado
+ El tamaño de la base de datos se incrementa en función del tamaño total de la tabla, menos la sobrecarga, hasta la fase de intercambio y eliminación del reempaquetado. Puede monitorizar la tasa de crecimiento del tamaño de la base de datos, calcular la velocidad de reempaquetado y estimar aproximadamente el tiempo que se tarda en completar la transferencia inicial de datos.
Como ejemplo, considere que el tamaño total de la tabla es de 2 TB, el tamaño de la base de datos es de 4 TB y la sobrecarga total de la tabla es de 1 TB. El valor del tamaño total de la base de datos devuelto por el cálculo al final de la operación de reempaquetado es el siguiente:
`2TB (Table size)` \$1 `4 TB (Database size)` - `1TB (Table bloat)` = `5TB`
Puede estimar aproximadamente la velocidad de la operación de reempaquetado muestreando la tasa de crecimiento en bytes entre dos puntos en el tiempo. Si la tasa de crecimiento es de 1 GB por minuto, la operación inicial de creación de la tabla puede tardar 1000 minutos o 16,6 horas aproximadamente en completarse. Además de la construcción inicial de la tabla, `pg_repack` también necesita aplicar los cambios acumulados. El tiempo que tarda depende del ritmo de aplicación de los cambios continuos más los acumulados.
**nota**
Puede usar la extensión `pgstattuple` para calcular la sobrecarga en la tabla. Para obtener más información, consulte [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html).
+ El número de filas de la tabla de registro `pg_repack's`, según el esquema de reempaquetado, representa el volumen de cambios pendientes de aplicarse a la nueva tabla tras la carga inicial.
Puede consultar la tabla de registro `pg_repack's` en `pg_stat_all_tables` para supervisar los cambios aplicados a la nueva tabla. `pg_stat_all_tables.n_live_tup` indica el número de registros pendientes de ser aplicados a la nueva tabla. Para obtener más información, consulte [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW).
```
postgres=>SELECT relname,n_live_tup FROM pg_stat_all_tables WHERE schemaname = 'repack' AND relname ILIKE '%log%';
-[ RECORD 1 ]---------
relname | log_16490
n_live_tup | 2000000
```
+ Puede utilizar la extensión `pg_stat_statements` para determinar el tiempo que tarda cada paso de la operación de reempaquetado. Esto es útil para prepararse para aplicar la misma operación de reempaque en un entorno de producción. Puede ajustar la cláusula `LIMIT` para ampliar aún más la salida.
```
postgres=>SELECT
SUBSTR(query, 1, 100) query,
round((round(total_exec_time::numeric, 6) / 1000 / 60),4) total_exec_time_in_minutes
FROM
pg_stat_statements
WHERE
query ILIKE '%repack%'
ORDER BY
total_exec_time DESC LIMIT 5;
query | total_exec_time_in_minutes
-----------------------------------------------------------------------+----------------------------
CREATE UNIQUE INDEX index_16493 ON repack.table_16490 USING btree (a) | 6.8627
INSERT INTO repack.table_16490 SELECT a FROM ONLY public.t1 | 6.4150
SELECT repack.repack_apply($1, $2, $3, $4, $5, $6) | 0.5395
SELECT repack.repack_drop($1, $2) | 0.0004
SELECT repack.repack_swap($1) | 0.0004
(5 rows)
```
El reempaquetado es una operación completamente fuera de lugar, por lo que la tabla original no se ve afectada y no prevemos ningún problema inesperado que requiera la recuperación de la tabla original. Si el reempaquetado falla inesperadamente, debe inspeccionar la causa del error y resolverlo.
Una vez resuelto el problema, coloque y vuelva a crear la extensión `pg_repack` en la base de datos en la que se encuentre la tabla y vuelva a intentar el paso `pg_repack`. Además, la disponibilidad de los recursos de computación y la accesibilidad simultánea de la tabla desempeñan un papel crucial a la hora de completar a tiempo la operación de reempaquetado.
# Actualización y uso de la extensión PLV8
PLV8 es una extensión de lenguaje Javascript de confianza para PostgreSQL Puede usarlo para procedimientos almacenados, desencadenadores y otro código de procedimiento que se puede llamar desde SQL. Esta extensión de lenguaje es compatible con todas las versiones actuales de PostgreSQL.
Si utiliza [PLV8](https://plv8.github.io/) y actualiza PostgreSQL a una nueva versión de PLV8, inmediatamente aprovecha la nueva extensión. Lleve a cabo los siguientes pasos para sincronizar los metadatos del catálogo con la nueva versión de PLV8. Estos pasos son opcionales, pero recomendamos que los complete para evitar advertencias de discrepancia de metadatos.
El proceso de actualización elimina todas las funciones PLV8 existentes. Por lo tanto, le recomendamos que cree una instantánea de su instancia de base de datos de RDS for PostgreSQL antes de la actualización. Para obtener más información, consulte [Creación de una instantánea de base de datos para una instancia de base de datos single-AZ para Amazon RDS](USER_CreateSnapshot.md).
**importante**
A partir de la versión 18 de PostgreSQL, Amazon RDS para PostgreSQL dejará de utilizar las extensiones `plcoffee` y `plls` de PostgreSQL. Le recomendamos que deje de usar Coffeescript y LiveScript en sus aplicaciones para asegurarse de tener una ruta de actualización para futuras actualizaciones de las versiones del motor.
**Para sincronizar los metadatos del catálogo con una nueva versión de PLV8**
1. Verifique que necesita realizar la actualización. Para ello, ejecute el siguiente comando mientras está conectado a la instancia.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
Si los resultados contienen valores de una versión instalada con un número inferior a la versión predeterminada, continúe con este procedimiento para actualizar las extensiones. Por ejemplo, el siguiente conjunto de resultados indica que debería actualizar.
```
name | default_version | installed_version | comment
--------+-----------------+-------------------+--------------------------------------------------
plls | 2.1.0 | 1.5.3 | PL/LiveScript (v8) trusted procedural language
plcoffee| 2.1.0 | 1.5.3 | PL/CoffeeScript (v8) trusted procedural language
plv8 | 2.1.0 | 1.5.3 | PL/JavaScript (v8) trusted procedural language
(3 rows)
```
1. Cree una instantánea de la instancia de base de datos de RDS for PostgreSQL si aún no lo ha hecho. Puede continuar con los pasos siguientes mientras se crea la instantánea.
1. Obtenga un recuento del número de funciones de PLV8 de su instancia de base de datos para que pueda validar que se aplican todas después de la actualización. Por ejemplo, la siguiente consulta SQL devuelve el número de funciones escritas en plv8, plcoffee y plls.
```
SELECT proname, nspname, lanname
FROM pg_proc p, pg_language l, pg_namespace n
WHERE p.prolang = l.oid
AND n.oid = p.pronamespace
AND lanname IN ('plv8','plcoffee','plls');
```
1. Use pg\$1dump para crear un archivo de volcado solo de esquema. Por ejemplo, cree un archivo en el equipo cliente en el directorio `/tmp`.
```
./pg_dump -Fc --schema-only -U master postgres >/tmp/test.dmp
```
En este ejemplo se utilizan las siguientes opciones:
+ `-Fc`: formato personalizado
+ --schema-only: vuelca solo los comandos necesarios para crear el esquema (funciones en este caso)
+ `-U`: el nombre de usuario maestro de RDS
+ `database`: el nombre de la base de datos para nuestra instancia de base de datos
Para obtener más información sobre pg\$1dump, consulte [pg\$1dump](https://www.postgresql.org/docs/current/static/app-pgdump.html ) en la documentación de PostgreSQL.
1. Extraiga la instrucción DDL "CREATE FUNCTION" que se encuentra en el archivo de volcado. El siguiente ejemplo utiliza el comando `grep` para extraer la instrucción DDL que crea las funciones y guardarlas en un archivo. Se utiliza en los pasos posteriores para volver a crear las funciones.
```
./pg_restore -l /tmp/test.dmp | grep FUNCTION > /tmp/function_list
```
Para obtener más información sobre pg\$1restore, consulte [pg\$1restore](https://www.postgresql.org/docs/current/static/app-pgrestore.html) en la documentación de PostgreSQL.
1. Borre las funciones y las extensiones. El siguiente ejemplo elimina cualquier objeto basado en PLV8. La opción cascade garantiza que se borren los dependientes.
```
DROP EXTENSION plv8 CASCADE;
```
Si su instancia de PostgreSQL contiene objetos basados en plcoffee o plls, repita este paso para dichas extensiones.
1. Cree las extensiones. El siguiente ejemplo crea las extensiones plv8, plcoffee y plls.
```
CREATE EXTENSION plv8;
CREATE EXTENSION plcoffee;
CREATE EXTENSION plls;
```
1. Cree las funciones con el archivo de volcado y el archivo "driver".
El siguiente ejemplo recrea las funciones que extrajo anteriormente.
```
./pg_restore -U master -d postgres -Fc -L /tmp/function_list /tmp/test.dmp
```
1. Verifique que todas las funciones se recrean con la siguiente consulta.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
La versión 2 de PLV8 agrega la siguiente fila adicional a su conjunto de resultados:
```
proname | nspname | lanname
---------------+------------+----------
plv8_version | pg_catalog | plv8
```
# Uso de PL/Rust para escribir funciones de PostgreSQL en lenguaje Rust
PL/Rust es una extensión del lenguaje Rust de confianza para PostgreSQL. Puede usarlo para procedimientos almacenados, funciones y otro código de procedimiento que se pueda llamar desde SQL. La extensión de lenguaje PL/Rust está disponible en las siguientes versiones:
+ RDS para PostgreSQL 17.1 y otras versiones 17 posteriores
+ RDS para PostgreSQL 16.1 y versiones 16 posteriores
+ RDS para PostgreSQL, 15.2-R2 y versiones 15 posteriores
+ RDS para PostgreSQL, 14.9 y versiones 14 posteriores
+ RDS para PostgreSQL, 13.12 y versiones 13 posteriores
Para obtener más información, consulte [PL/Rust](https://github.com/tcdi/plrust#readme) en GitHub.
**Topics**
+ [Configuración de PL/Rust](#PL_Rust-setting-up)
+ [Creación de funciones con PL/Rust](#PL_Rust-create-function)
+ [Uso de cajas con PL/Rust](#PL_Rust-crates)
+ [Limitaciones de PL/Rust](#PL_Rust-limitations)
## Configuración de PL/Rust
Para instalar la extensión plrust en la instancia de base de datos, agregue plrust al parámetro `shared_preload_libraries` en el grupo de parámetros de base de datos asociado con la instancia de base de datos. Con la extensión plrust instalada, puede crear funciones.
Para modificar el parámetro `shared_preload_libraries`, la instancia de base de datos debe asociarse al grupo de parámetros personalizado. Para obtener información sobre la creación de un grupo de parámetros de base de datos personalizado, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Puede instalar la extensión plrust mediante la Consola de administración de AWS o la AWS CLI.
En los pasos siguientes se supone que la instancia de base de datos está asociada a un grupo de parámetros de base de datos personalizado.
### Consola
**Instalar la extensión plrust en el parámetro `shared_preload_libraries`**
Realice los siguientes pasos con una cuenta que sea miembro del grupo `rds_superuser` (rol).
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija **Databases** (Bases de datos).
1. Elija el nombre de la instancia de base de datos para ver los detalles.
1. Abra la pestaña **Configuración** de la instancia de base de datos y busque el enlace del grupo de parámetros de instancias de base de datos.
1. Elija el enlace para abrir los parámetros personalizados asociados a la instancia de base de datos.
1. En el campo de búsqueda **Parámetros**, escriba `shared_pre` para buscar el parámetro `shared_preload_libraries`.
1. Seleccione **Edit parameters** (Editar parámetros) para acceder a los valores de las propiedades.
1. Añada plrust a la lista en el campo **Valores**. Utilice una coma para separar los elementos de la lista de valores.
1. Reinicie la instancia de base de datos para que los cambios en el parámetro `shared_preload_libraries` surtan efecto. El reinicio inicial puede requerir tiempo adicional para completarse.
1. Cuando la instancia esté disponible, compruebe si se ha inicializado plrust. Use `psql` para conectarse a la instancia de base de datos y ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
```
El resultado debería tener un aspecto similar al siguiente:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
### AWS CLI
**Instale la extensión plrust en el parámetro shared\$1preload\$1libraries.**
Realice los siguientes pasos con una cuenta que sea miembro del grupo `rds_superuser` (rol).
1. Use el comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) de AWS CLI para añadir plrust al parámetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=plrust,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use el comando [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) de AWS CLI para reiniciar la instancia de base de datos e inicializar la biblioteca plrust. El reinicio inicial puede requerir tiempo adicional para completarse.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Cuando la instancia esté disponible, compruebe si se ha inicializado plrust. Use `psql` para conectarse a la instancia de base de datos y ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
```
El resultado debería tener un aspecto similar al siguiente:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
## Creación de funciones con PL/Rust
PL/Rust compilará la función como biblioteca dinámica, la cargará y la ejecutará.
La siguiente función de Rust filtra los múltiplos de una matriz.
```
postgres=> CREATE LANGUAGE plrust;
CREATE EXTENSION
```
```
CREATE OR REPLACE FUNCTION filter_multiples(a BIGINT[], multiple BIGINT) RETURNS BIGINT[]
IMMUTABLE STRICT
LANGUAGE PLRUST AS
$$
Ok(Some(a.into_iter().filter(|x| x.unwrap() % multiple != 0).collect()))
$$;
WITH gen_values AS (
SELECT ARRAY(SELECT * FROM generate_series(1,100)) as arr)
SELECT filter_multiples(arr, 3)
from gen_values;
```
## Uso de cajas con PL/Rust
En RDS para PostgreSQL versiones 16.3-R2 y posteriores, 15.7-R2 y versiones 15 posteriores, 14.12-R2 y versiones 14 posteriores y 13.15-R2 y versiones 13 y posteriores, PL/Rust admite cajas adicionales:
+ `url`
+ `regex`
+ `serde`
+ `serde_json`
En RDS para PostgreSQL versiones 15.5-R2 y posteriores, 14.10-R2 y versiones 14 posteriores y 13.13-R2 y versiones 13 posteriores, PL/Rust admite dos cajas adicionales:
+ `croaring-rs`
+ `num-bigint`
A partir de las versiones 15.4, 14.9 y 13.12 de Amazon RDS para PostgreSQL, PL/Rust admite las siguientes cajas:
+ `aes`
+ `ctr`
+ `rand`
Estas cajas solo admiten las funciones predeterminadas. Es posible que las nuevas versiones de RDS para PostgreSQL contengan versiones actualizadas de las cajas y que las versiones anteriores de las cajas ya no sean compatibles.
Siga las prácticas recomendadas para realizar una actualización de una versión principal y comprobar si las funciones de PL/Rust son compatibles con la nueva versión principal. Para obtener más información, consulte el blog [Best practices for upgrading Amazon RDS to major and minor versions of PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-upgrading-amazon-rds-to-major-and-minor-versions-of-postgresql/) y [Actualización del motor de base de datos de PostgreSQL para Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html) en la Guía del usuario de Amazon RDS.
Encontrará ejemplos del uso de dependencias al crear una función de PL/Rust en [Use dependencies](https://tcdi.github.io/plrust/use-plrust.html#use-dependencies).
## Limitaciones de PL/Rust
De forma predeterminada, los usuarios de bases de datos no pueden usar PL/Rust. Para proporcionar acceso a PL/Rust, conéctese como usuario con el privilegio rds\$1superuser y ejecute el siguiente comando:
```
postgres=> GRANT USAGE ON LANGUAGE PLRUST TO user;
```
# Administración de datos espaciales con la extensión PostGIS
PostGIS es una extensión de PostgreSQL para almacenar y administrar información espacial. Para obtener más información sobre PostGIS, consulte [PostGIS.net](https://postgis.net/).
A partir de la versión 10.5, PostgreSQL admite la biblioteca libprotobuf 1.3.0 utilizada por PostGIS para trabajar con datos de teselas vectoriales de Mapbox.
La configuración de la extensión PostGIS requiere privilegios de `rds_superuser`. Le recomendamos que cree un usuario (rol) para administrar instalar la extensión PostGIS y los datos espaciales. La extensión PostGIS y sus componentes relacionados añaden miles de funciones a PostgreSQL. Considere la posibilidad de crear la extensión PostGIS en su propio esquema si eso tiene sentido para su caso de uso. En el ejemplo siguiente, se muestra cómo instalar la extensión en su propia base de datos, pero esto no es obligatorio.
**Topics**
+ [Paso 1: cree un usuario (rol) para administrar la extensión PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [Paso 2: cargue las extensiones PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [Paso 3: transferir la propiedad de los esquemas de extensión](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [Paso 4: transferir la propiedad de las tablas de PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [Paso 5: pruebe las extensiones](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [Paso 6: Actualice la extensión de PostGIS](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [Versiones de extensión de PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [Actualización de PostGIS 2 a PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## Paso 1: cree un usuario (rol) para administrar la extensión PostGIS
En primer lugar, conéctese a una instancia de base de datos de RDS para PostgreSQL como usuario con privilegios `rds_superuser`. Si mantuvo el nombre predeterminado al configurar la instancia, conéctese como `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Cree un rol independiente (usuario) para administrar la extensión PostGIS.
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
Conceda los privilegios `rds_superuser` de este rol para permitir que el rol instale la extensión.
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
Cree una base de datos para utilizarla para sus artefactos de PostGIS. Este paso es opcional. O puede crear un esquema en la base de datos de usuarios para las extensiones de PostGIS, pero esto tampoco es obligatorio.
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
Conceda todos los privilegios `gis_admin` en la base de datos `lab_gis`.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
Salga de la sesión y vuelva a conectarse a una instancia de base de datos de RDS para PostgreSQL como `gis_admin`.
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
Continúe configurando la extensión tal y como se detalla en los pasos siguientes.
## Paso 2: cargue las extensiones PostGIS
La extensión de PostGIS incluye varias extensiones relacionadas que funcionan juntas para proporcionar funcionalidad geoespacial. Dependiendo de su caso de uso, es posible que no necesite todas las extensiones creadas en este paso.
Utilice instrucciones `CREATE EXTENSION` para cargar las extensiones de PostGIS.
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
Para verificar los resultados, puede ejecutar la consulta SQL que se muestra en el siguiente ejemplo, que enumera las extensiones y sus propietarios.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## Paso 3: transferir la propiedad de los esquemas de extensión
Use las declaraciones de ALTER SCHEMA para transferir la propiedad de los esquemas al rol `gis_admin`.
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
Si desea confirmar el cambio de propiedad, ejecute la siguiente consulta SQL. O bien, puede utilizar el metacomando `\dn` de la línea de comandos psql.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## Paso 4: transferir la propiedad de las tablas de PostGIS
**nota**
No cambie la propiedad de las funciones de PostGIS. Para que PostGIS funcione correctamente y reciba actualizaciones, estas funciones deben retener la propiedad original. Para obtener más información sobre los permisos de PostGIS, consulte [PostgreSQL Security](https://postgis.net/workshops/postgis-intro/security.html).
Use la siguiente función para transferir la propiedad de las tablas de PostGIS al rol `gis_admin`. Ejecute la siguiente declaración desde el símbolo del sistema psql para crear la función.
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
A continuación, ejecute la siguiente consulta para ejecutar la función `exec` que, a su vez, ejecuta las instrucciones y altera los permisos.
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## Paso 5: pruebe las extensiones
Para evitar tener que especificar el nombre del esquema, añada el esquema `tiger` a la ruta de búsqueda usando el siguiente comando.
```
SET search_path=public,tiger;
SET
```
Pruebe el esquema `tiger` usando la siguiente instrucción SELECT.
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
Para obtener más información sobre esta extensión, consulte [Tiger Geocoder](https://postgis.net/docs/Extras.html#Tiger_Geocoder) en la documentación de PostGIS.
Pruebe el acceso al esquema `topology` usando la siguiente instrucción `SELECT`. Esto llama a la función `createtopology` para registrar un nuevo objeto de topología (my\$1new\$1topo) con el identificador de referencia espacial especificado (26986) y la tolerancia predeterminada (0,5). Para obtener más información, visite [CreateTopology](https://postgis.net/docs/CreateTopology.html) en la documentación de PostgreSQL.
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## Paso 6: Actualice la extensión de PostGIS
Cada nueva versión de PostgreSQL admite una o más versiones de la extensión de PostGIS compatibles con esa versión. La actualización del motor de PostgreSQL a una nueva versión no actualiza automáticamente la extensión de PostGIS. Antes de actualizar el motor de PostgreSQL, normalmente se actualiza PostGIS a la versión más reciente disponible para la versión actual de PostgreSQL. Para obtener más información, consulte [Versiones de extensión PostGIS](#CHAP_PostgreSQL.Extensions.PostGIS).
Después de actualizar el motor de PostgreSQL, vuelva a actualizar la extensión de PostGIS a la versión compatible con la versión del motor de PostgreSQL recién actualizada. Para obtener más información sobre la actualización del motor PostgreSQL, consulte [Realización de una actualización de la versión principal de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
Puede comprobar si hay disponibles actualizaciones de la versión de la extensión PostGIS en su instancia de base de datos de RDS para PostgreSQL en cualquier momento. Para ello, ejecute el siguiente comando. Esta función está disponible con PostGIS 2.5.0 y versiones posteriores.
```
SELECT postGIS_extensions_upgrade();
```
Si su aplicación no es compatible con la última versión de PostGIS, puede instalar una versión anterior de PostGIS que esté disponible en su versión principal de la siguiente manera.
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
Si desea actualizar a una versión específica de PostGIS desde una versión anterior, también puede utilizar el siguiente comando.
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
Dependiendo de la versión desde la que se actualice, es posible que tenga que volver a utilizar esta función. El resultado de la primera ejecución de la función determina si se necesita una función de actualización adicional. Por ejemplo, eso es lo que ocurre para la actualización de PostGIS 2 a PostGIS 3. Para obtener más información, consulte [Actualización de PostGIS 2 a PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3).
Si actualizó esta extensión para prepararse para una actualización de la versión principal del motor de PostgreSQL, puede continuar con otras tareas preliminares. Para obtener más información, consulte [Realización de una actualización de la versión principal de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
## Versiones de extensión PostGIS
Le recomendamos que instale las versiones de todas las extensiones, como PostGIS, como se indica en [Versiones de extensión para Amazon RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) en las *Notas de la versión de Amazon RDS para PostgreSQL* Para obtener una lista de las versiones que están disponibles en su versión, utilice el siguiente comando.
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
Puede encontrar información sobre la versión en las siguientes secciones de las *Notas de la versión de Amazon RDS para PostgreSQL*:
+ [ Extensiones de PostgreSQL versión 16 admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-16x)
+ [ Extensiones de PostgreSQL versión 15 admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-15x)
+ [ Extensiones de PostgreSQL 14 admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-14x)
+ [ Extensiones de PostgreSQL 13 admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-13x)
+ [ Extensiones de PostgreSQL 12 admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-12x)
+ [ Extensiones de PostgreSQL 11 admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-11x)
+ [ Extensiones de PostgreSQL 10 admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-101x)
+ [ Extensiones de PostgreSQL 9.6.x admitidas en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-96x)
## Actualización de PostGIS 2 a PostGIS 3
A partir de la versión 3.0, la funcionalidad de trama de PostGIS es una extensión separada, `postgis_raster`. Esta extensión tiene su propia ruta de instalación y actualización. Esto elimina del núcleo docenas de funciones, tipos de datos y otros artefactos necesarios para el procesamiento de imágenes de trama desde la extensión `postgis` principal. Esto significa que si su caso de uso no requiere procesamiento de tramas, no es necesario que instale la extensión `postgis_raster`.
En el siguiente ejemplo de actualización, el primer comando de actualización extrae la funcionalidad de trama en la extensión `postgis_raster`. Luego, se requiere un segundo comando de actualización para actualizar `postgis_raster` a la nueva versión.
**Para actualizar de PostGIS 2 a PostGIS 3**
1. Identifique la versión predeterminada de PostGIS que está disponible para la versión de PostgreSQL en su Instancia de base de datos RDS para PostgreSQL. Para ello, ejecute la siguiente consulta.
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. Identifique las versiones de PostGIS instaladas en cada base de datos en la instancia de base de datos de RDS para PostgreSQL. En otras palabras, consulte la base de datos de cada usuario de la siguiente manera.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
Esta falta de correspondencia entre la versión predeterminada (PostGIS 3.1.4) y la versión instalada (PostGIS 2.3.7) significa que debe actualizar la extensión de PostGIS.
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. Ejecute la siguiente consulta para comprobar que la funcionalidad ráster ahora está en su propio paquete.
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
El resultado muestra que aún hay una diferencia entre las versiones. Las funciones de PostGIS son de la versión 3 (postgis-3), mientras que las funciones ráster (rtpostgis) son de la versión 2 (rtpostgis-2.3). Para completar la actualización, vuelva a ejecutar el comando de actualización, como se indica a continuación.
```
postgres=> SELECT postgis_extensions_upgrade();
```
Puede ignorar los mensajes de advertencia sin problemas. Vuelva a ejecutar la siguiente consulta para comprobar que la actualización se ha completado. La actualización se completa cuando en PostGIS y en todas las extensiones relacionadas deja de aparecer una marca que indica que deben actualizarse.
```
SELECT postgis_full_version();
```
1. Utilice la siguiente consulta para ver el proceso de actualización completado y las extensiones empaquetadas por separado, y compruebe que las versiones coinciden.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
El resultado muestra que la extensión de PostGIS 2 se ha actualizado a PostGIS 3 y que ambas, `postgis`y la extensión `postgis_raster` ya separada, son de la versión 3.1.5.
Una vez completada esta actualización, si no tiene pensado usar la funcionalidad de trama, puede eliminar la extensión de la siguiente manera.
```
DROP EXTENSION postgis_raster;
```
# Uso de los contenedores de datos externos compatibles para Amazon RDS for PostgreSQL
Un FDW es un tipo específico de extensión que proporciona acceso a datos externos. Por ejemplo, la extensión `oracle_fdw` permite a su clúster de bases de datos de RDS for PostgreSQL trabajar con bases de datos Oracle. Otro ejemplo, cuando utiliza la extensión nativa de PostgreSQL `postgres_fdw`, puede acceder a los datos almacenados en instancias de bases de datos de PostgreSQL externas a su instancia de base de datos de RDS for PostgreSQL.
A continuación, puede encontrar información sobre varios contenedores de datos externos de PostgreSQL compatibles.
**Topics**
+ [Uso de la extensión log\$1fdw para acceder al registro de base de datos mediante SQL](CHAP_PostgreSQL.Extensions.log_fdw.md)
+ [Uso de la extensión postgres\$1fdw para acceder a datos externos](postgresql-commondbatasks-fdw.md)
+ [Uso de bases de datos MySQL con la extensión mysql\$1fdw](postgresql-mysql-fdw.md)
+ [Uso de una base de datos de Oracle con la extensión oracle\$1fdw](postgresql-oracle-fdw.md)
+ [Uso de bases de datos de SQL Server con la extensión mysql\$1fdw](postgresql-tds-fdw.md)
# Uso de la extensión log\$1fdw para acceder al registro de base de datos mediante SQL
La instancia de base de datos de RDS para PostgreSQL admite la extensión `log_fdw`, que se puede utilizar para el acceso al registro del motor de base de datos a través de una interfaz SQL. La extensión `log_fdw` proporciona dos funciones que facilitan la creación de tablas externas para los registros de la base de datos:
+ `list_postgres_log_files`: muestra los archivos del directorio de registro de la base de datos y el tamaño del archivo en bytes.
+ `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)`: crea una tabla externa para el archivo especificado en la base de datos actual.
Todas las funciones creadas por `log_fdw` pertenecen a `rds_superuser`. Los miembros del rol `rds_superuser` pueden conceder acceso a estas funciones a otros usuarios de la base de datos.
De forma predeterminada, Amazon RDS genera los archivos de registro en formato `stderr` (error estándar), como se especifica en el parámetro `log_destination`. Solo hay dos opciones para este parámetro: `stderr` y `csvlog` (valores separados por comas, CSV). Si se añade la opción `csvlog` al parámetro, Amazon RDS generará tanto el registro `stderr` como el registro `csvlog`. Esto puede afectar a la capacidad de almacenamiento del clúster de base de datos, por lo que debe tener en cuenta los demás parámetros que afectan a la gestión de jlos registros. Para obtener más información, consulte [Configuración del destino del registro (`stderr`, `csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format).
Uno de los beneficios de generar registros `csvlog` es que la extensión `log_fdw` permite crear tablas externas con los datos perfectamente divididos en varias columnas. Para ello, la instancia debe asociarse a un grupo de parámetros de base de datos personalizado para que usted pueda cambiar la configuración de `log_destination`. Para obtener información acerca de cómo hacerlo, consulte [Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
En el ejemplo siguiente se presupone que el parámetro `log_destination` incluye `cvslog`.
**Para utilizar la extensión log\$1fdw**
1. Instale la extensión de `log_fdw`.
```
postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION
```
1. Cree el servidor de registros como contenedor de datos externo.
```
postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER
```
1. Seleccione todos los elementos de una lista de archivos de registro.
```
postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;
```
A continuación, se muestra una respuesta de ejemplo.
```
file_name | file_size_bytes
------------------------------+-----------------
postgresql.log.2023-08-09-22.csv | 1111
postgresql.log.2023-08-09-23.csv | 1172
postgresql.log.2023-08-10-00.csv | 1744
postgresql.log.2023-08-10-01.csv | 1102
(4 rows)
```
1. Crear una tabla con una sola columna log\$1entry para el archivo seleccionado.
```
postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
'log_server', 'postgresql.log.2023-08-09-22.csv');
```
La respuesta no proporciona más detalles que el hecho de que la tabla ya existe.
```
-----------------------------------
(1 row)
```
1. Seleccione una muestra del archivo de registro. El siguiente código recupera la hora del registro y la descripción del mensaje de error.
```
postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;
```
A continuación, se muestra una respuesta de ejemplo.
```
log_time | message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)
```
# Uso de la extensión postgres\$1fdw para acceder a datos externos
Puede acceder a los datos en una tabla en un servidor de base de datos remoto con la extensión [postgres\$1fdw](https://www.postgresql.org/docs/current/static/postgres-fdw.html). Si establece una conexión remota desde su instancia de base de datos de PostgreSQL, el acceso también está disponible para su réplica de lectura.
**Para utilizar postgres\$1fdw para acceder a un servidor de base de datos remoto**
1. Instale la extensión postgres\$1fdw.
```
CREATE EXTENSION postgres_fdw;
```
1. Cree el servidor de datos externo utilizando CREATE SERVER.
```
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
```
1. Cree un mapeo de usuario para identificar la función que utilizar en el servidor remoto.
**importante**
Para redactar la contraseña para que no aparezca en los registros, configure `log_statement=none` en el nivel de sesión. Si se establece en el nivel de parámetro, no se redacta la contraseña.
```
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'foreign_user', password 'password');
```
1. Cree una tabla que se mapee a la tabla del servidor remoto.
```
CREATE FOREIGN TABLE foreign_table (
id integer NOT NULL,
data text)
SERVER foreign_server
OPTIONS (schema_name 'some_schema', table_name 'some_table');
```
# Uso de bases de datos MySQL con la extensión mysql\$1fdw
Para tener acceso desde una instancia de base de datos de RDS para PostgresSQL a una base de datos compatible con MySQL, puede instalar y utilizar la extensión `mysql_fdw`. Este contenedor de datos externo le permite trabajar con RDS for MySQL, Aurora MySQL, MariaDB y otras bases de datos compatibles con MySQL. La conexión desde la instancia de base de datos de RDS para PostgreSQL a la base de datos MySQL se cifra tanto como sea posible, depeniendo de la configuración del cliente y del servidor. No obstante, puede aplicar cifrado si lo desea. Para obtener más información, consulte [Uso de cifrado en tránsito con la extensión](#postgresql-mysql-fdw.encryption-in-transit).
La extensión `mysql_fdw` es complatible con las versiones de Amazon RDS para PostgreSQL 14.2, 13.6 y posteriores. Es compatible con selecciones, inserciones, actualizaciones y eliminaciones de una base de datos de RDS for PostgreSQL en tablas de una instancia de base de datos compatible con MySQL.
**Topics**
+ [Configuración de una base de datos de RDS para PostgreSQL para utilizar la extensión mysql\$1fdw](#postgresql-mysql-fdw.setting-up)
+ [Ejemplo: Acceso a una base de datos de RDS para MySQL desde RDS para PostgreSQL](#postgresql-mysql-fdw.using-mysql_fdw)
+ [Uso de cifrado en tránsito con la extensión](#postgresql-mysql-fdw.encryption-in-transit)
## Configuración de una base de datos de RDS para PostgreSQL para utilizar la extensión mysql\$1fdw
Para configurar la extensión `mysql_fdw` en la instancia de base de datos de RDS para PostgreSQL es necesario cargar la extensión en la instancia y, a continuación, crear el punto de conexión a la instancia de base de datos de MySQL. Para esa tarea debe disponer de los siguientes detalles sobre la instancia de base de datos MySQL:
+ Nombre de host o del punto de conexión. Con una instancia de base de datos de RDS para MySQL el punto de conexión puede encontrarse a través de la consola. Elija la pestaña Conectividad y seguridad y busque en la sección “Punto de enlace y puerto”.
+ Número de puerto. El número de puerto predeterminado para MySQL es 3306.
+ Nombre de la base de datos. El identificador de la base de datos.
También tiene que proporcionar acceso en el grupo de seguridad o en la lista de control de acceso (ACL) para el puerto MySQL, 3306. Tanto la instancia de base de datos de RDS para PostgreSQL como la de RDS para MySQL necesitan acceso al puerto 3306. Si el acceso no está configurado correctamente, al intentar conectarse a una tabla compatible con MySQL aparecerá un mensaje de error similar al siguiente:
```
ERROR: failed to connect to MySQL: Can't connect to MySQL server on 'hostname.aws-region.rds.amazonaws.com:3306' (110)
```
En el procedimiento que sigue, usted (como cuenta de `rds_superuser`) crea el servidor externo. A continuación, concede acceso al servidor externo a usuarios específicos. A continuación, estos usuarios crean sus propias asignaciones a las cuentas de usuario de MySQL adecuadas para trabajar con la instancia de base de datos MySQL.
**Para utilizar mysql\$1fdw para acceder a un servidor de base de datos MySQL**
1. Conéctese a la instancia de base de datos PostgreSQL a través de una cuenta que tenga el rol de `rds_superuser`. Si al crear la instancia de base de datos de RDS para PostgreSQL aceptó los valores predeterminados, el nombre de usuario será `postgres` y se podrá conectar mediante la herramienta de línea de comandos `psql` de este modo:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres –-password
```
1. Instale la extensión `mysql_fdw` de la siguiente manera:
```
postgres=> CREATE EXTENSION mysql_fdw;
CREATE EXTENSION
```
Una vez instalada la extensión en la instancia de base de datos de RDS para PostgreSQL, configure el servidor externo que proporciona la conexión a una base de datos MySQL.
**Para crear el servidor externo**
Realice estas tareas en la instancia de base de datos RDS para PostgreSQL. Para seguir estos pasos se entiende que está conectado como usuario con privilegios `rds_superuser`, como `postgres`.
1. Cree un servidor externo en la instancia de base de datos RDS for PostgreSQL:
```
postgres=> CREATE SERVER mysql-db FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'db-name.111122223333.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Conceda a los usuarios que corresponsa acceso al servidor externo. Deben ser usuarios que no sean administradores, es decir, usuarios que no tengan el rol `rds_superuser`.
```
postgres=> GRANT USAGE ON FOREIGN SERVER mysql-db to user1;
GRANT
```
Los usuarios de PostgreSQL crean y administran sus propias conexiones a la base de datos MySQL a través del servidor externo.
## Ejemplo: Acceso a una base de datos de RDS para MySQL desde RDS para PostgreSQL
Supongamos que tiene una tabla simple en una instancia de base de datos de PostgreSQL. Sus usuarios de RDS para PostgreSQL quieren consultar los elementos `SELECT`, `INSERT`, `UPDATE` y `DELETE` en esa tabla. Supongamos que la exstensión `mysql_fdw` se creó en la instancia de base de datos de RDS for PostgreSQL, como se detalla en el procedimiento anterior. Después de conectarse a la instancia de base de datos de RDS for PostgreSQL como usuario con privilegios `rds_superuser`, podrá continuar con los pasos que se describen a continuación.
1. Cree un servidor externo en la instancia de base de datos de RDS para PostgreSQL:
```
test=> CREATE SERVER mysqldb FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'your-DB.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Conceda permiso de uso a un usuario que no tiene permisos `rds_superuser`, por ejemplo `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER mysqldb TO user1;
GRANT
```
1. Conéctese como*user1* y, a continuación, cree una asignación para el usuario de MySQL:
```
test=> CREATE USER MAPPING FOR user1 SERVER mysqldb OPTIONS (username 'myuser', password 'mypassword');
CREATE USER MAPPING
```
1. Cree una tabla externa vinculada a la tabla MySQL:
```
test=> CREATE FOREIGN TABLE mytab (a int, b text) SERVER mysqldb OPTIONS (dbname 'test', table_name '');
CREATE FOREIGN TABLE
```
1. Ejecute una consulta simple en la tabla externa:
```
test=> SELECT * FROM mytab;
a | b
---+-------
1 | apple
(1 row)
```
1. Puede añadir, modificar y quitar datos de la tabla MySQL. Por ejemplo:
```
test=> INSERT INTO mytab values (2, 'mango');
INSERT 0 1
```
Ejecute la consulta `SELECT` de nuevo para ver los resultados:
```
test=> SELECT * FROM mytab ORDER BY 1;
a | b
---+-------
1 | apple
2 | mango
(2 rows)
```
## Uso de cifrado en tránsito con la extensión
De forma predeterminada, la conexión a MySQL desde RDS para PostgreSQL utiliza cifrado en tránsito (TLS/SSL). No obstante, la conexión vuelve a ser no cifrada cuando la configuración del cliente y del servidor difieren. Puede aplicar el cifrado para todas las conexiones salientes especificando la opción `REQUIRE SSL` en las cuentas de usuario de RDS for MySQL. Este mismo método también funciona para las cuentas de usuario de MariaDB y Aurora MySQL.
Para cuentas de usuario MySQL configuradas en `REQUIRE SSL`, el intento de conexión falla si no se puede establecer una conexión segura.
Para aplicar el cifrado de cuentas de usuario de bases de datos MySQL existentes, puede utilizar el comando `ALTER USER`. La sintaxis varía en función de la versión de MySQL, como se muestra en la siguiente tabla. Para obtener más información, consulte [ALTER USER](https://dev.mysql.com/doc/refman/8.0/en/alter-user.html) en el *manual de referencia de MySQL*.
| MySQL 5.7, MySQL 8.0 | MySQL 5.6 |
| --- | --- |
| `ALTER USER 'user'@'%' REQUIRE SSL;` | `GRANT USAGE ON *.* to 'user'@'%' REQUIRE SSL;` |
Para obtener más información acerca de la extensión `mysql_fdw`, consulte la documentación sobre [mysql\$1fdw](https://github.com/EnterpriseDB/mysql_fdw).
# Uso de una base de datos de Oracle con la extensión oracle\$1fdw
Para acceder a una base de datos de Oracle desde su instancia de base de datos de RDS for PostgreSQL puede instalar y utilizar la extensión `oracle_fdw`. Esta extensión es un contenedor de datos externos para bases de datos Oracle. Para obtener más información sobre la extensión, consulte la documentación de [oracle\$1fdw](https://github.com/laurenz/oracle_fdw).
La extensión `oracle_fdw` es compatible con las versiones 12.7, 13.3 y las versiones posteriores de RDS for PostgreSQL.
**Topics**
+ [Activación de la extensión oracle\$1fdw](#postgresql-oracle-fdw.enabling)
+ [Ejemplo: Usar un servidor externo vinculado a una Amazon RDS for Oracle Database](#postgresql-oracle-fdw.example)
+ [Trabajo con cifrado en tránsito](#postgresql-oracle-fdw.encryption)
+ [Comprensión y permisos de la vista pg\$1user\$1mappings](#postgresql-oracle-fdw.permissions)
## Activación de la extensión oracle\$1fdw
Para utilizar la extensión oracle\$1fdw, lleve a cabo el siguiente procedimiento.
**Para habilitar la extensión oracle\$1fdw**
+ Ejecute el siguiente comando con una cuenta que tenga los permisos `rds_superuser`.
```
CREATE EXTENSION oracle_fdw;
```
## Ejemplo: Usar un servidor externo vinculado a una Amazon RDS for Oracle Database
El siguiente ejemplo muestra el uso de un servidor externo vinculado a una base de datos de Amazon RDS for Oracle.
**Crear un servidor externo vinculado a una base de datos de RDS for Oracle**
1. Tenga en cuenta lo siguiente en la instancia de base de datos de RDS for Oracle:
+ punto de enlace
+ Puerto
+ Nombre de base de datos
1. Cree un servidor externo.
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. Otorgue uso a un usuario que no tenga permisos `rds_superuser`, por ejemplo `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. Conéctese como `user1` y cree una asignación a un usuario de Oracle.
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Cree una tabla externa vinculada a una tabla de Oracle.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Consulte la tabla externa.
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
Si la consulta informa el siguiente error, verifique el grupo de seguridad y la lista de control de acceso (ACL) para asegurarse de que ambas instancias puedan comunicarse.
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## Trabajo con cifrado en tránsito
El cifrado de PostgreSQL a Oracle en tránsito se basa en una combinación de parámetros de configuración de cliente y servidor. Para obtener un ejemplo que utiliza Oracle 21c, consulte [About the Values for Negotiating Encryption and Integrity](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5) en la documentación de Oracle. El cliente utilizado para oracle\$1fdw en Amazon RDS está configurado con `ACCEPTED`, lo que significa que el cifrado depende de la configuración del servidor de base de datos de Oracle y utiliza la biblioteca de seguridad de Oracle (libnnz) para cifrado.
Si su base de datos está en RDS for Oracle, consulte [Oracle Native Network Encryption](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html) para configurar el cifrado.
## Comprensión y permisos de la vista pg\$1user\$1mappings
El catálogo de PostgreSQL `pg_user_mapping` almacena la asignación desde un usuario RDS for PostgreSQL en el usuario de un servidor de datos externo (remoto). El acceso al catálogo está restringido, pero usted utiliza la vista `pg_user_mappings` para ver las asignaciones. A continuación, se muestra un ejemplo sobre cómo se aplican los permisos en una base de datos de Oracle de ejemplo, aunque esta información es válida también en general para cualquier contenedor de datos externo.
En el siguiente resultado, puede encontrar roles y permisos asignados a tres usuarios de ejemplo diferentes. Usuarios de `rdssu1` y `rdssu2` son miembros del rol `rds_superuser`, y el usuario `user1` no lo es. En el ejemplo se usa el metacomando `\du` de `psql` para enumerar los roles existentes.
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
Todos los usuarios, incluidos los usuarios con privilegios `rds_superuser`, pueden ver sus propias asignaciones de usuarios (`umoptions`) en la tabla `pg_user_mappings`. Como se muestra en el siguiente ejemplo, cuando `rdssu1` intenta obtener todas las asignaciones de usuario, se genera un a pesar de los privilegios `rds_superuser` de `rdssu1`:
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
A continuación, se muestran algunos ejemplos:
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
Debido a las diferencias en la implementación de `information_schema._pg_user_mappings` y `pg_catalog.pg_user_mappings`, un `rds_superuser` que se crea manualmente requiere permisos adicionales para ver las contraseñas en `pg_catalog.pg_user_mappings`.
No requieren otros permisos para un `rds_superuser` para ver las contraseñas en `information_schema._pg_user_mappings`.
Los usuarios que no tienen el rol `rds_superuser` pueden ver contraseñas en `pg_user_mappings` solo en las condiciones que se describen a continuación:
+ El usuario actual es el usuario que se está asignando y es el propietario del servidor o tiene el privilegio de `USAGE` en él.
+ El usuario actual es el propietario del servidor, y la asignación es para `PUBLIC`.
# Uso de bases de datos de SQL Server con la extensión mysql\$1fdw
Puede utilizar la extensión de PostgreSQL `tds_fdw` para acceder a bases de datos compatibles con el protocolo de flujo de datos tabular (TDS), como bases de datos Sybase y Microsoft SQL Server. Este contenedor de datos externo le permite conectarse desde suinstancia de base de datos RDS for PostgreSQL a bases de datos que utilizan el protocolo TDS, incluido Amazon RDS for Microsoft SQL Server. Para obtener más información, consulte la documentación sobre [tds-fdw/tds\$1fdw](https://github.com/tds-fdw/tds_fdw) en GitHub.
La extensión `tds_fdw` es compatible con las versiones 14.2, 13.6 y posteriores de Amazon RDS for PostgreSQL.
## Configuración de la base de datos de Aurora PostgreSQL para utilizar la extensión mysql\$1fdw
En los procedimientos que siguen encontrará un ejemplo de configuración y uso de `tds_fdw` con una instancia de base de datos RDS for PostgreSQL. Antes de poder conectarse a una base de datos SQL Server mediante `tds_fdw`, tiene que obtener los siguientes detalles de la instancia:
+ Nombre de host o del punto de conexión. Para instancias de RDS for MySQL encontrará los puntos de conexión con la consola. Elija la pestaña Conectividad y seguridad y busque en la sección “Punto de enlace y puerto”.
+ Número de puerto. El puerto 1433 es el predeterminado para Microsoft SQL Server.
+ Nombre de la base de datos. El identificador de la base de datos.
También deberá proporcionar acceso en el grupo de seguridad o en la lista de control de acceso (ACL) al puerto MySQL, 1433. Tanto el clúster de bases de datos de Aurora PostgreSQL como necesitan poder acceder al puerto 1433. Si el acceso no está configurado correctamente, cuando intente consultar Microsoft SQL Server aparecerá el siguiente mensaje de error:
```
ERROR: DB-Library error: DB #: 20009, DB Msg: Unable to connect:
Adaptive Server is unavailable or does not exist (mssql2019.aws-region.rds.amazonaws.com), OS #: 0, OS Msg: Success, Level: 9
```
**Para usar tds\$1fdw para conectarse a una base de datos de SQL Server**
1. Conéctese a su instancia de base de datos PostgreSQL con una cuenta con rol `rds_superuser`:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=test –-password
```
1. Instale la extensión `tds_fdw`.
```
test=> CREATE EXTENSION tds_fdw;
CREATE EXTENSION
```
Después de instalar la extensión en su instancia de base de datos RDS for PostgreSQL, configure el servidor externo.
**Para crear el servidor externo**
Realice estas tareas en la instancia de base de datos RDS for PostgreSQL con una cuenta que con privilegios `rds_superuser`.
1. Cree un servidor externo en la instancia de base de datos RDS for PostgreSQL:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing');
CREATE SERVER
```
Para acceder a datos no que sean ASCII en el lado de SQLServer, cree un enlace de servidor con la opción character\$1set en la instancia de base de datos de RDS para PostgreSQL:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing', character_set 'UTF-8');
CREATE SERVER
```
1. Conceda permisos a un usuario que no tenga los privilegios del rol `rds_superuser`, por ejemplo `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER sqlserverdb TO user1;
```
1. Conéctese como user1 y, a continuación, cree una asignación para el usuario de SQL Server:
```
test=> CREATE USER MAPPING FOR user1 SERVER sqlserverdb OPTIONS (username 'sqlserveruser', password 'password');
CREATE USER MAPPING
```
1. Cree una tabla externa vinculada a una tabla de SQL Server.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER sqlserverdb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Consulte la tabla externa:
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
### Uso de cifrado en tránsito para la conexión
La conexión de RDS for PostgreSQLa SQL Server utiliza cifrado en tránsito (TLS/SSL) según la configuración de la base de datos de SQL Server. Si SQL Server no está configurado para el cifrado, el RDS para el cliente PostgreSQL que realiza la solicitud a la base de datos de SQL Server vuelve a no ir cifrado.
Puede aplicar el cifrado para la conexión a RDS para instancias de base de datos de SQL Server configurando el parámetro `rds.force_ssl`. Para saber cómo, consulte [Requerir que las conexiones a la instancia de base de datos usen SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html#SQLServer.Concepts.General.SSL.Forcing). Para obtener más información sobre la configuración de SSL/TLS para RDS for SQL Server, consulte [Uso de SSL con una instancia de base de datos de Microsoft SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html).
# Uso de Extensiones de lenguaje de confianza para PostgreSQL
Extensiones de lenguaje de confianza para PostgreSQL es un kit de desarrollo de código abierto para crear extensiones de PostgreSQL. Le permite crear extensiones de PostgreSQL de alto rendimiento y ejecutarlas de forma segura en su instancia de base de datos de RDS para PostgreSQL. Al utilizar Extensiones de lenguaje de confianza (TLE) para PostgreSQL, puede crear extensiones de PostgreSQL que sigan el enfoque documentado para ampliar la funcionalidad de PostgreSQL. Para obtener más información, consulte el punto [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) (Empaquetar objetos relacionados en una extensión) en la documentación de PostgreSQL.
Una ventaja clave de TLE es que se puede utilizar en entornos que no proporcionan acceso al sistema de archivos subyacente a la instancia de PostgreSQL. Anteriormente, la instalación de una nueva extensión requería acceso al sistema de archivos. TLE elimina esta restricción. Pues proporciona un entorno de desarrollo para crear nuevas extensiones para cualquier base de datos de PostgreSQL, incluidas las que se ejecutan en los instancias de base de datos de RDS para PostgreSQL.
TLE está diseñado para evitar el acceso a recursos no seguros para las extensiones que se crean con TLE. Su entorno de ejecución limita el impacto de cualquier defecto de extensión a una única conexión de base de datos. TLE también proporciona a los administradores de bases de datos un control preciso sobre quién puede instalar las extensiones y proporciona un modelo de permisos para ejecutarlas.
TLE es compatible con las siguientes versiones de RDS para PostgreSQL:
+ Versión 18.1 y versiones posteriores a 18
+ Versión 17.1 y otras versiones 17 superiores
+ Versión 16.1 y versiones posteriores a 16
+ Versión 15.2 y versiones posteriores a 15
+ Versión 14.5 y versiones posteriores a 14
+ Versión 13.12 y versiones posteriores a 13
El entorno de desarrollo y el entorno de ejecución de Extensiones de lenguaje de confianza se empaquetan como la extensión `pg_tle` de PostgreSQL, versión 1.0.1. Admite la creación de extensiones en JavaScript, Perl, Tcl, PL/pgSQL y SQL. La extensión `pg_tle` se instala en la instancia de base de datos de RDS para PostgreSQL del mismo modo que se instalan otras extensiones de PostgreSQL. Una vez configurada `pg_tle`, los desarrolladores pueden usarla para crear nuevas extensiones de PostgreSQL, conocidas como *extensiones TLE*.
En los temas siguientes, encontrará información sobre cómo configurar Extensiones de lenguaje de confianza y cómo comenzar a crear sus propias extensiones TLE.
**Topics**
+ [Terminología](PostgreSQL_trusted_language_extension-terminology.md)
+ [Requisitos para usar Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension-requirements.md)
+ [Configuración de Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md)
+ [Información general de Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension.overview.md)
+ [Creación de extensiones TLE para RDS para PostgreSQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md)
+ [Eliminar las extensiones TLE de una base de datos](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md)
+ [Desinstalación de Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension-uninstalling-pg_tle-devkit.md)
+ [Uso de enlaces de PostgreSQL con sus extensiones TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)
+ [Uso de tipos de datos personalizados en TLE](PostgreSQL_trusted_language_extension-custom-data-type.md)
+ [Referencia de funciones para Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension-functions-reference.md)
+ [Referencia de enlaces para Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md)
# Terminología
Para entender mejor Extensiones de lenguaje de confianza, consulta el siguiente glosario para ver los términos utilizados en este tema.
**Extensiones de lenguaje de confianza para PostgreSQL**
*Extensiones de lenguaje de confianza para PostgreSQL* es el nombre oficial del kit de desarrollo de código abierto que se incluye como extensión `pg_tle`. Está disponible para su uso en cualquier sistema PostgreSQL. Para obtener más información, consulte [aws/pg\$1tle](https://github.com/aws/pg_tle) en GitHub.
**Extensiones de lenguaje de confianza**
*Extensiones de lenguaje de confianza* es la versión abreviada de Extensiones de lenguaje de confianza para PostgreSQL. En esta documentación se utilizan el nombre abreviado y sus siglas (TLE).
**lenguaje de confianza**
Un *lenguaje de confianza* es un lenguaje de programación o de scripting que tiene atributos de seguridad específicos. Por ejemplo, los lenguajes de confianza suelen restringir el acceso al sistema de archivos y limitan el uso de las propiedades de red especificadas. El kit de desarrollo TLE está diseñado para ser compatible con lenguajes de confianza. PostgreSQL admite varios lenguajes diferentes que se utilizan para crear extensiones fiables o no fiables. Para ver un ejemplo, consulte el punto [Trusted and Untrusted PL/Perl](https://www.postgresql.org/docs/current/plperl-trusted.html) (PL/Perl fiable y no fiable) en la documentación de PostgreSQL. Al crear una extensión con Extensiones de lenguaje de confianza, la extensión utiliza mecanismos de lenguaje de confianza de forma inherente.
**Extensión TLE**
Una *extensión TLE* es una extensión de PostgreSQL que se ha creado mediante el kit de desarrollo de Extensiones de lenguaje de confianza (TLE).
# Requisitos para usar Extensiones de lenguaje de confianza para PostgreSQL
Estos son los requisitos para configurar y usar el kit de desarrollo TLE.
+ ** Versiones de RDS para PostgreSQL**: las extensiones de lenguaje de confianza se admiten en RDS para PostgreSQL versiones 13.12 y versiones 13 posteriores, 14.5 y versiones 14 posteriores, y 15.2 y versiones posteriores únicamente.
+ Si necesita actualizar su instancia de RDS para PostgreSQL, consulte [Actualizaciones del motor de base de datos de RDS para PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.md).
+ Si aún no tiene un clúster de base de datos de Aurora que ejecute PostgreSQL, puede crear una. Para obtener más información, consulte Instancia de base de datos de RDS para PostgreSQL, consulte [Creación de una instancia de base de datos de PostgreSQL y conexión a ella](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md).
+ **Requiere privilegios de `rds_superuser`**: para instalar y configurar la extensión `pg_tle`, el rol de usuario de la base de datos debe tener permisos del rol `rds_superuser`. De forma predeterminada, este rol se otorga al usuario `postgres` que crea el Instancia de base de datos RDS para PostgreSQL.
+ **Requiere un grupo de parámetros de base de datos personalizado**: su instancia de base de datos de RDS para PostgreSQL debe configurarse con un grupo de parámetros de base de datos personalizado.
+ Si su instancia de base de datos de RDS para PostgreSQL no está configurado con un grupo de parámetros de base de datos personalizado, debe crear uno y asociarlo su instancia de base de datos de RDS para PostgreSQL. Para obtener un breve resumen de los pasos, consulte [Creación y aplicación de un grupo de parámetros de base de datos personalizado](#PostgreSQL_trusted_language_extension-requirements-create-custom-params).
+ Si su instancia de base de datos de RDS para PostgreSQL ya se ha configurado con un grupo de parámetros de base de datos personalizado, puede configurar Extensiones de lenguaje de confianza. Para obtener más información, consulte [Configuración de Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
## Creación y aplicación de un grupo de parámetros de base de datos personalizado
Siga los siguientes pasos para crear un grupo de parámetros de base de datos personalizado y configure su instancia de base de datos de RDS para PostgreSQL para utilizarlo.
### Consola
**Para crear un grupo de parámetros de base de datos personalizado y utilizarlo con su instancia de base de datos de RDS para PostgreSQL**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Elija Parameter groups (Grupos de parámetros) en el menú de Amazon RDS.
1. Elija **Create parameter group**.
1. En la página **Parameter group details** (Detalles del grupo de parámetros), escriba la siguiente información.
+ En **Parameter group family** (Familia de grupo de parámetros), elija postgres14.
+ En **Type (Tipo)**, elija DB Parameter Group (Grupo de parámetros de bases de datos).
+ En **Group name** (Nombre de grupo), asigne al grupo de parámetros un nombre significativo en el contexto de sus operaciones.
+ En **Description** (Descripción), introduzca una descripción útil para que los demás miembros de su equipo puedan encontrarla fácilmente.
1. Seleccione **Crear**. El grupo de parámetros de base de datos personalizado se crea en su Región de AWS. Ahora puede modificar su instancia de base de datos de RDS para PostgreSQL para usarlo. Para ello, siga los siguientes pasos.
1. Seleccione **Databases** (Bases de datos) en el menú de Amazon RDS.
1. Elija la instancia de base de datos de RDS para PostgreSQL que desea usar con TLE de entre las enumeradas y, a continuación, elija **Modify** (Modificar).
1. En la En la página Modify DB cluster settings (Modificar la configuración del clúster de base de datos), busque **Database options** (Opciones de la base de datos) y elija su grupo de parámetros de base de datos personalizado en el selector.
1. Elija **Continue** (Continuar) para guardar el cambio.
1. Elija **Apply immediately** (Aplicar inmediatamente) para poder seguir configurando la instancia de base de datos de RDS para PostgreSQL para utilizar TLE.
Para continuar con la configuración del sistema para Extensiones de lenguaje de confianza, consulte [Configuración de Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
Para obtener más información sobre cómo trabajar con Grupos de parámetros de base de datos, consulte [Grupos de parámetros de base de datos para instancias de Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
### AWS CLI
Puede evitar especificar el argumento `--region` al utilizar los comandos de la CLI al configurar su AWS CLI con su Región de AWS predeterminada. Para obtener más información, consulte [Fundamentos de configuración](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de AWS Command Line Interface*.
**Para crear un grupo de parámetros de base de datos personalizado y utilizarlo con su instancia de base de datos de RDS para PostgreSQL**
1. Utilice el comando [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) de la AWS CLI para crear un grupo de parámetros de base de datos personalizado basado en postgres14 para su Región de AWS.
Para Linux, macOS o Unix:
```
aws rds create-db-parameter-group \
--region aws-region \
--db-parameter-group-name custom-params-for-pg-tle \
--db-parameter-group-family postgres14 \
--description "My custom DB parameter group for Trusted Language Extensions"
```
Para Windows:
```
aws rds create-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name custom-params-for-pg-tle ^
--db-parameter-group-family postgres14 ^
--description "My custom DB parameter group for Trusted Language Extensions"
```
Su grupo de parámetros de base de datos personalizado está disponible en su Región de AWS, por lo que puede modificar instancia de base de datos de RDS para PostgreSQL para utilizarla.
1. Utilice el comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) de la AWS CLI para aplicar su grupo de parámetros de base de datos personalizado a su instancia de base de datos de RDS para PostgreSQL. Este comando reinicia inmediatamente la instancia activa.
Para Linux, macOS o Unix:
```
aws rds modify-db-instance \
--region aws-region \
--db-instance-identifier your-instance-name \
--db-parameter-group-name custom-params-for-pg-tle \
--apply-immediately
```
Para Windows:
```
aws rds modify-db-instance ^
--region aws-region ^
--db-instance-identifier your-instance-name ^
--db-parameter-group-name custom-params-for-pg-tle ^
--apply-immediately
```
Para continuar con la configuración del sistema para Extensiones de lenguaje de confianza, consulte [Configuración de Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
# Configuración de Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL
En los pasos siguientes se supone que su instancia de base de datos de RDS para PostgreSQL está asociada a un grupo de parámetros de base de datos personalizado. Puede utilizar la Consola de administración de AWS o la AWS CLI para estos pasos.
Al configurar Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL, las instala en una base de datos específica para que las usen los usuarios de la base de datos que tienen permisos en esa base de datos.
## Consola
**Para configurar Extensiones de lenguaje de confianza**
Realice los siguientes pasos con una cuenta que sea miembro del grupo (rol) `rds_superuser`.
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija la instancia de base de datos de RDS for PostgreSQL.
1. Abra la pestaña **Configuration** (Configuración) para su Instancia de base de datos RDS para PostgreSQL. Entre los detalles de la instancia, busque el enlace del **grupo de parámetros**.
1. Elija el enlace para abrir los parámetros personalizados asociados al Instancia de base de datos RDS para PostgreSQL.
1. En el campo de búsqueda **Parametes** (Parámetros), escriba `shared_pre` para buscar el parámetro `shared_preload_libraries`.
1. Seleccione **Edit parameters** (Editar parámetros) para acceder a los valores de las propiedades.
1. Añada `pg_tle` a la lista en el campo **Values** (Valores). Utilice una coma para separar los elementos de la lista de valores.
![\[Imagen del parámetro shared_preload_libraries con pg_tle añadido.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pg_tle.png)
1. Reinicie la instancia de base de datos de RDS for PostgreSQL para que surta efecto el cambio en el parámetro `shared_preload_libraries`.
1. Cuando la instancia esté disponible, verifique si se ha inicializado `pg_tle`. Use `psql` para conectarse a la instancia de base de datos de RDS for PostgreSQL y, a continuación, ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
1. Con la extensión `pg_tle` inicializada, ahora ya puede crear la extensión.
```
CREATE EXTENSION pg_tle;
```
Para comprobar que la extensión esté instalada, use el metacomando `psql`.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
```
1. Asigne el rol `pgtle_admin` al nombre de usuario principal que creó para la instancia de base de datos de RDS para PostgreSQL al configurarla. Si ha aceptado el valor predeterminado, es `postgres`.
```
labdb=> GRANT pgtle_admin TO postgres;
GRANT ROLE
```
Puede comprobar si se ha realizado la concesión con el metacomando `psql`, tal como se muestra en el siguiente ejemplo. Solo los roles `pgtle_admin` y `postgres` se muestran en el resultado. Para obtener más información, consulte [Descripción del rol rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
```
labdb=> \du
List of roles
Role name | Attributes | Member of
-----------------+---------------------------------+-----------------------------------
pgtle_admin | Cannot login | {}
postgres | Create role, Create DB +| {rds_superuser,pgtle_admin}
| Password valid until infinity |...
```
1. Cierre la sesión de `psql` con el metacomando `\q`.
```
\q
```
Para empezar a crear extensiones TLE, consulte [Ejemplo: creación de una extensión de lenguaje de confianza mediante SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
## AWS CLI
Puede evitar especificar el argumento `--region` al utilizar los comandos de la CLI al configurar su AWS CLI con su Región de AWS predeterminada. Para obtener más información, consulte [Fundamentos de configuración](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de AWS Command Line Interface*.
**Para configurar Extensiones de lenguaje de confianza**
1. Use el comando [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) de AWS CLI para añadir `pg_tle` al parámetro `shared_preload_libraries`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pg_tle,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use el comando [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) de AWS CLI para reiniciar la instancia de base de datos de RDS para PostgreSQL e inicialice la biblioteca de `pg_tle`.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Cuando la instancia esté disponible, puede verificar si `pg_tle` se ha inicializado. Use `psql` para conectarse a la instancia de base de datos de RDS for PostgreSQL y, a continuación, ejecute el siguiente comando.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
Con `pg_tle` inicializado, ahora ya puede crear la extensión.
```
CREATE EXTENSION pg_tle;
```
1. Asigne el rol `pgtle_admin` al nombre de usuario principal que creó para la instancia de base de datos de RDS para PostgreSQL al configurarla. Si ha aceptado el valor predeterminado, es `postgres`.
```
GRANT pgtle_admin TO postgres;
GRANT ROLE
```
1. Cierre la sesión de `psql` de la siguiente manera.
```
labdb=> \q
```
Para empezar a crear extensiones TLE, consulte [Ejemplo: creación de una extensión de lenguaje de confianza mediante SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
# Información general de Extensiones de lenguaje de confianza para PostgreSQL
Extensiones de lenguaje de confianza para PostgreSQL es una extensión de PostgreSQL que se instala en la instancia de base de datos de RDS para PostgreSQL de la misma manera que se configuran otras extensiones de PostgreSQL. En la siguiente imagen de un ejemplo de base de datos de la herramienta de cliente pgAdmin, puede ver algunos de los componentes que componen la extensión `pg_tle`.
![\[Imagen que muestra algunos de los componentes que conforman el kit de desarrollo TLE.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/apg-pg_tle-installed-view-in-pgAdmin.png)
Puede ver los siguientes detalles.
1. El kit de desarrollo de Extensiones de lenguaje de confianza (TLE) está empaquetado como la extensión `pg_tle`. De este modo, `pg_tle` se añade a las extensiones disponibles para la base de datos en la que se instala.
1. TLE tiene su propio esquema: `pgtle`. Este esquema contiene funciones auxiliares (3) para instalar y administrar las extensiones que cree.
1. TLE proporciona más de una docena de funciones auxiliares para instalar, registrar y administrar las extensiones. Para obtener más información sobre estas funciones, consulte [Referencia de funciones para Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension-functions-reference.md).
Otros componentes de la extensión `pg_tle` incluyen lo siguiente:
+ **El rol `pgtle_admin`**: el rol `pgtle_admin` se crea al instalar la extensión `pg_tle`. Este rol es privilegiado y debe tratarse como tal. Le recomendamos encarecidamente que siga el principio de *privilegio mínimo* al conceder el rol `pgtle_admin` a los usuarios de la base de datos. En otras palabras, conceda el rol `pgtle_admin` solo a los usuarios de bases de datos que estén autorizados a crear, instalar y administrar nuevas extensiones TLE, como `postgres`.
+ **La tabla `pgtle.feature_info`**: la tabla `pgtle.feature_info` es una tabla protegida que contiene información sobre los TLE, los enlaces, los procedimientos y las funciones personalizados almacenados que utilizan. Si tiene privilegios `pgtle_admin`, utilice las siguientes funciones de Extensiones de lenguaje de confianza para añadir y actualizar la información de la tabla.
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
# Creación de extensiones TLE para RDS para PostgreSQL
Puede instalar cualquier extensión que cree con TLE en cualquier instancia de base de datos de RDS para PostgreSQL que tenga la extensión `pg_tle` instalada. La extensión `pg_tle` se limita a la base de datos PostgreSQL en la que está instalada. Las extensiones que cree con TLE están incluidas en la misma base de datos.
Utilice las distintas funciones de `pgtle` para instalar el código que conforma la extensión TLE. Todas las siguientes funciones de Extensiones de lenguaje de confianza requieren el rol `pgtle_admin`.
+ [pgtle.install\$1extension](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path)
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(name)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension(nombre, versión)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
## Ejemplo: creación de una extensión de lenguaje de confianza mediante SQL
El siguiente ejemplo muestra cómo crear una extensión TLE denominada `pg_distance` que contenga algunas funciones SQL para calcular distancias mediante diferentes fórmulas. En la lista, puede encontrar la función para calcular la distancia Manhattan y la función para calcular la distancia euclidiana. Para obtener más información sobre la diferencia entre estas fórmulas, consulte [Geometría del taxista](https://en.wikipedia.org/wiki/Taxicab_geometry) y [Geometría euclidiana](https://en.wikipedia.org/wiki/Euclidean_geometry) en la Wikipedia.
Puede utilizar este ejemplo en su instancia de base de datos de RDS para PostgreSQL si tiene la extensión `pg_tle` configurada como se detalla en [Configuración de Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
**nota**
Debe tener los privilegios del rol `pgtle_admin` para seguir este procedimiento.
**Para crear la extensión TLE de ejemplo**
En los pasos siguientes se utiliza un ejemplo de base de datos denominado `labdb`. Esta base de datos es propiedad del usuario `postgres` principal. El rol `postgres` también tiene los permisos del rol `pgtle_admin`.
1. Use `psql` para conectarse a la Instancia de base de datos RDS para PostgreSQL.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Cree una extensión TLE denominada `pg_distance` copiando el siguiente código y pegándolo en la consola de sesión de `psql`.
```
SELECT pgtle.install_extension
(
'pg_distance',
'0.1',
'Distance functions for two points',
$_pg_tle_$
CREATE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL;
CREATE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL;
CREATE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL;
$_pg_tle_$
);
```
Debería ver un resultado como el siguiente.
```
install_extension
---------------
t
(1 row)
```
Los artefactos que componen la extensión `pg_distance` ahora ya están instalados en su base de datos. Estos artefactos incluyen el archivo de control y el código de la extensión, que son elementos que deben estar presentes para poder crear la extensión mediante el comando `CREATE EXTENSION`. En otras palabras, aún debe crear la extensión para que sus funciones estén disponibles para los usuarios de la base de datos.
1. Para crear la extensión, utilice el comando `CREATE EXTENSION` como lo haría con cualquier otra extensión. Al igual que con otras extensiones, el usuario de la base de datos debe tener los permisos `CREATE` en la base de datos.
```
CREATE EXTENSION pg_distance;
```
1. Para probar la extensión TLE `pg_distance`, puede utilizarla para calcular la [distancia Manhattan](https://en.wikipedia.org/wiki/Taxicab_geometry) entre cuatro puntos.
```
labdb=> SELECT manhattan_dist(1, 1, 5, 5);
8
```
Para calcular la [distancia euclidiana](https://en.wikipedia.org/wiki/Euclidean_geometry) entre el mismo conjunto de puntos, puede utilizar lo siguiente.
```
labdb=> SELECT euclidean_dist(1, 1, 5, 5);
5.656854249492381
```
La extensión `pg_distance` carga las funciones de la base de datos y las pone a disposición de cualquier usuario con permisos en la base de datos.
## Modificación de su extensión TLE
Para mejorar el rendimiento de las consultas para las funciones incluidas en esta extensión TLE, añada los dos atributos de PostgreSQL siguientes a sus especificaciones.
+ `IMMUTABLE`: el atributo `IMMUTABLE` garantiza que el optimizador de consultas pueda utilizar optimizaciones para mejorar los tiempos de respuesta de las consultas. Para obtener más información, consulte [Function Volatility Categories](https://www.postgresql.org/docs/current/xfunc-volatility.html) (Categorías de volatilidad de función) en la documentación de PostgreSQL.
+ `PARALLEL SAFE`: el atributo `PARALLEL SAFE` es otro atributo que permite a PostgreSQL ejecutar la función en modo paralelo. Para obtener más información, consulte [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) en la documentación de PostgreSQL.
En el siguiente ejemplo, puede ver cómo se usa la función `pgtle.install_update_path` para agregar estos atributos a cada función a fin de crear una versión `0.2` de la extensión TLE `pg_distance`. Para obtener más información acerca de esta función, consulte [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path). Debe tener el rol `pgtle_admin` para realizar esta tarea.
**Para actualizar una extensión TLE existente y especificar la versión predeterminada**
1. Conecte con la instancia de base de datos de RDS para PostgreSQL con `psql` u otra herramienta de cliente como pgAdmin.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Modifique una extensión TLE existente copiando el siguiente código y pegándolo en la consola de sesión de `psql`.
```
SELECT pgtle.install_update_path
(
'pg_distance',
'0.1',
'0.2',
$_pg_tle_$
CREATE OR REPLACE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
$_pg_tle_$
);
```
Verá una respuesta similar a la siguiente.
```
install_update_path
---------------------
t
(1 row)
```
Puede hacer que esta versión de la extensión sea la versión predeterminada para que los usuarios de la base de datos no tengan que especificar una versión al crear o actualizar la extensión en su base de datos.
1. Para especificar que la versión modificada (versión 0.2) de la extensión TLE es la versión predeterminada, utilice la función `pgtle.set_default_version` tal como se muestra en el siguiente ejemplo.
```
SELECT pgtle.set_default_version('pg_distance', '0.2');
```
Para obtener más información acerca de esta función, consulte [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version).
1. Con el código en su lugar, puede actualizar la extensión TLE instalada de la forma habitual, mediante el comando `ALTER EXTENSION ... UPDATE`, tal como se muestra aquí:
```
ALTER EXTENSION pg_distance UPDATE;
```
# Eliminar las extensiones TLE de una base de datos
Puede eliminar sus extensiones TLE mediante el comando `DROP EXTENSION` de la misma manera que lo hace con otras extensiones de PostgreSQL. Al eliminar la extensión, no se eliminan los archivos de instalación que la componen, lo que permite a los usuarios volver a crearla. Para eliminar la extensión y sus archivos de instalación, realice el siguiente proceso de dos pasos.
**Para eliminar la extensión TLE y eliminar sus archivos de instalación**
1. Use `psql` u otra herramienta de cliente para conectarse a la instancia de base de datos de RDS para PostgreSQL.
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Elimine la extensión tal como haría con cualquier extensión de PostgreSQL.
```
DROP EXTENSION your-TLE-extension
```
Por ejemplo, si crea la extensión `pg_distance` tal como se indica en [Ejemplo: creación de una extensión de lenguaje de confianza mediante SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example), puede eliminarla de la siguiente manera.
```
DROP EXTENSION pg_distance;
```
Verá un resultado que confirma que se ha eliminado la extensión, de la siguiente manera.
```
DROP EXTENSION
```
En este punto, la extensión ya no está activa en la base de datos. Sin embargo, sus archivos de instalación y su archivo de control siguen disponibles en la base de datos, por lo que los usuarios de la base de datos pueden volver a crear la extensión si lo desean.
+ Si desea dejar los archivos de extensión intactos para que los usuarios de la base de datos puedan crear su extensión TLE, puede detenerse aquí.
+ Si desea eliminar todos los archivos que conforman la extensión, proceda con el siguiente paso.
1. Para eliminar todos los archivos de instalación de la extensión, utilice la función `pgtle.uninstall_extension`. Esta función elimina todos los archivos de código y control de la extensión.
```
SELECT pgtle.uninstall_extension('your-tle-extension-name');
```
Por ejemplo, para eliminar todos los archivos de instalación `pg_distance`, utilice el siguiente comando.
```
SELECT pgtle.uninstall_extension('pg_distance');
uninstall_extension
---------------------
t
(1 row)
```
# Desinstalación de Extensiones de lenguaje de confianza para PostgreSQL
Si ya no quiere crear sus propias extensiones TLE con TLE, puede eliminar la extensión `pg_tle` y eliminar todos los artefactos. Esta acción incluye eliminar cualquier extensión TLE de la base de datos y el esquema `pgtle`.
**Para eliminar la extensión `pg_tle` y su esquema de una base de datos**
1. Use `psql` u otra herramienta de cliente para conectarse a la instancia de base de datos de RDS para PostgreSQL.
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Elimine la extensión `pg_tle` de la base de datos. Si la base de datos está ejecutando sus propias extensiones TLE, también debe eliminar esas extensiones. Para ello, puede utilizar la palabra clave `CASCADE`, tal como se muestra a continuación.
```
DROP EXTENSION pg_tle CASCADE;
```
Si la extensión `pg_tle` no sigue activa en la base de datos, no es necesario que utilice la palabra clave `CASCADE`.
1. Elimine el esquema `pgtle`. Esta acción elimina todas las funciones de administración de la base de datos.
```
DROP SCHEMA pgtle CASCADE;
```
El comando devuelve lo siguiente cuando se completa el proceso.
```
DROP SCHEMA
```
Se eliminan la extensión `pg_tle`, su esquema y sus funciones, así como todos los artefactos. Para crear nuevas extensiones con TLE, vuelva a realizar el proceso de configuración. Para obtener más información, consulte [Configuración de Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
# Uso de enlaces de PostgreSQL con sus extensiones TLE
Un *enlace* es un mecanismo de devolución de llamada disponible en PostgreSQL que permite a los desarrolladores llamar a funciones personalizadas u otras rutinas durante las operaciones normales de la base de datos. El kit de desarrollo de TLE admite enlaces de PostgreSQL para que pueda integrar funciones personalizadas con el comportamiento de PostgreSQL en el tiempo de ejecución. Por ejemplo, puede utilizar un enlace para asociar el proceso de autenticación a su propio código personalizado o para modificar el proceso de planificación y ejecución de consultas según sus necesidades específicas.
Sus extensiones TLE pueden utilizar enlaces. Si un enlace tiene un alcance global, se aplica a todas las bases de datos. Por lo tanto, si su extensión TLE usa un enlace global, debe crear su extensión TLE en todas las bases de datos a las que puedan acceder sus usuarios.
Cuando usa la extensión `pg_tle` para crear sus propias Extensiones de lenguaje de confianza, puede usar los enlaces disponibles de una API de SQL para crear las funciones de su extensión. Debe registrar cualquier enlace con `pg_tle`. Para algunos enlaces, es posible que también tenga que establecer varios parámetros de configuración. Por ejemplo, el enlace de retención `passcode` se puede configurar como activado, desactivado u obligatorio. Para obtener más información sobre los requisitos específicos de los enlaces `pg_tle` disponibles, consulte [Referencia de enlaces para Extensiones de lenguaje de confianza para PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md).
## Ejemplo: Crear una extensión que utilice un enlace de PostgreSQL
El ejemplo descrito en esta sección utiliza un enlace de PostgreSQL para comprobar la contraseña proporcionada durante operaciones SQL específicas e impide que los usuarios de la base de datos establezcan sus contraseñas iguales a las que figuran en la tabla `password_check.bad_passwords`. La tabla contiene las diez opciones de contraseñas más utilizadas, pero fáciles de descifrar.
Para configurar este ejemplo en su instancia de base de datos de RDS para PostgreSQL, ya tiene que tener Extensiones de lenguaje de confianza instalado. Para obtener más información, consulte [Configuración de Extensiones de lenguaje de confianza en su instancia de base de datos de RDS para PostgreSQL](PostgreSQL_trusted_language_extension-setting-up.md).
**Para configurar el ejemplo del enlace de verificación de contraseñas**
1. Use `psql` para conectarse a la Instancia de base de datos RDS para PostgreSQL.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Copie el código de la [Lista de códigos del enlace password\$1check](#PostgreSQL_trusted_language_extension-example-hook_code_listing) y péguelo en su base de datos.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
Cuando la extensión se haya cargado en la base de datos, verá un resultado como el siguiente.
```
install_extension
-------------------
t
(1 row)
```
1. Mientras siga conectado a la base de datos, ya podrá crear la extensión.
```
CREATE EXTENSION my_password_check_rules;
```
1. Puede confirmar que la extensión se ha creado en la base de datos mediante el siguiente metacomando `psql`.
```
\dx
List of installed extensions
Name | Version | Schema | Description
-------------------------+---------+------------+-------------------------------------------------------------
my_password_check_rules | 1.0 | public | Prevent use of any of the top-ten most common bad passwords
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
1. Abra otra sesión de terminal para trabajar con la AWS CLI. Debe modificar su grupo de parámetros de base de datos personalizado para activar el enlace de verificación de contraseñas. Para ello, utilice el comando [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) de la CLI tal como se muestra en el siguiente ejemplo.
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Cuando el parámetro se haya activado correctamente, verá un resultado como el siguiente.
```
(
"DBParameterGroupName": "docs-lab-parameters-for-tle"
}
```
Puede que el cambio en la configuración del grupo de parámetros tarde unos minutos en aplicarse. Sin embargo, este parámetro es dinámico, por lo que no es necesario reiniciar la instancia de base de datos de RDS para PostgreSQL para que la configuración surta efecto.
1. Abra la sesión `psql` y consulte la base de datos para comprobar que el enlace password\$1check esté activado.
```
labdb=> SHOW pgtle.enable_password_check;
pgtle.enable_password_check
-----------------------------
on
(1 row)
```
El enlace password-check ahora está activo. Puede probarlo creando un rol nuevo y utilizando una de las contraseñas incorrectas, tal como se muestra en el siguiente ejemplo.
```
CREATE ROLE test_role PASSWORD 'password';
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 21 at RAISE
SQL statement "SELECT password_check.passcheck_hook(
$1::pg_catalog.text,
$2::pg_catalog.text,
$3::pgtle.password_types,
$4::pg_catalog.timestamptz,
$5::pg_catalog.bool)"
```
El resultado se ha modificado para que se pueda leer.
El siguiente ejemplo muestra que el comportamiento `\password` del metacomando interactivo `pgsql` también se ve afectado por el enlace password\$1check.
```
postgres=> SET password_encryption TO 'md5';
SET
postgres=> \password
Enter new password for user "postgres":*****
Enter it again:*****
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 12 at RAISE
SQL statement "SELECT password_check.passcheck_hook($1::pg_catalog.text, $2::pg_catalog.text, $3::pgtle.password_types, $4::pg_catalog.timestamptz, $5::pg_catalog.bool)"
```
Puede eliminar esta extensión TLE y desinstalar sus archivos de código fuente si lo desea. Para obtener más información, consulte [Eliminar las extensiones TLE de una base de datosEliminar las extensiones TLE de una base de datos](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md).
### Lista de códigos del enlace password\$1check
El código de ejemplo que se muestra aquí define la especificación de la extensión TLE `my_password_check_rules`. Al copiar este código y pegarlo en la base de datos, el código de la extensión `my_password_check_rules` se carga en la base de datos y el enlace `password_check` queda registrado para que lo utilice la extensión.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
# Uso de tipos de datos personalizados en TLE
PostgreSQL admite comandos para registrar nuevos tipos base (también conocidos como tipos escalares) para gestionar con eficiencia estructuras de datos complejas en su base de datos. Un tipo base le permite personalizar la forma en que se almacenan los datos internamente y cómo convertirlos a una representación textual externa y desde ella. Estos tipos de datos personalizados son útiles a la hora de ampliar PostgreSQL para que admita dominios funcionales en los que un tipo integrado, como un número o un texto, no puede proporcionar una semántica de búsqueda suficiente.
RDS para PostgreSQL le permite crear tipos de datos personalizados en su extensión de lenguaje de confianza y definir funciones que admitan operaciones de SQL e indexación para estos nuevos tipos de datos. Los tipos de datos personalizados están disponibles para las siguientes versiones:
+ RDS para PostgreSQL, versión 15.4 y versiones 15 posteriores
+ RDS para PostgreSQL, versión 14.9 y versiones 14 posteriores
+ RDS para PostgreSQL, versión 13.12 y versiones 13 posteriores
Para obtener más información, consulte [Trusted Language Base types](https://github.com/aws/pg_tle/blob/main/docs/09_datatypes.md).
# Referencia de funciones para Extensiones de lenguaje de confianza para PostgreSQL
Consulte la siguiente documentación de referencia sobre las funciones disponibles en Extensiones de lengua de confianza para PostgreSQL. Utilice estas funciones para instalar, registrar, actualizar y administrar sus *extensiones TLE*, es decir, las extensiones de PostgreSQL que desarrolla con el kit de desarrollo de Extensiones de lenguaje de confianza.
**Topics**
+ [pgtle.available\$1extensions](#pgtle.available_extensions)
+ [pgtle.available\$1extension\$1versions](#pgtle.available_extension_versions)
+ [pgtle.extension\$1update\$1paths](#pgtle.extension_update_paths)
+ [pgtle.install\$1extension](#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](#pgtle.install_update_path)
+ [pgtle.register\$1feature](#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(name)](#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension(nombre, versión)](#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](#pgtle.unregister_feature_if_exists)
## pgtle.available\$1extensions
La función `pgtle.available_extensions` es una función de devolución de conjuntos. Devuelve todas las extensiones TLE disponibles en la base de datos. Cada fila devuelta contiene información sobre una sola extensión TLE.
### Prototipo de función
```
pgtle.available_extensions()
```
### Rol
Ninguna.
### Argumentos
Ninguna.
### Salida
+ `name`: nombre de la extensión TLE.
+ `default_version`: versión de la extensión TLE que se utilizará cuando se llame a `CREATE EXTENSION` sin especificar una versión.
+ `description`: descripción más detallada acerca de la extensión TLE.
### Ejemplo de uso
```
SELECT * FROM pgtle.available_extensions();
```
## pgtle.available\$1extension\$1versions
La función `available_extension_versions` es una función de devolución de conjuntos. Esta función devuelve una lista de todas las extensiones de TLE disponibles y sus versiones. Cada fila contiene información sobre una versión específica de la extensión TLE dada, incluso si requiere un rol específico.
### Prototipo de función
```
pgtle.available_extension_versions()
```
### Rol
Ninguna.
### Argumentos
Ninguna.
### Salida
+ `name`: nombre de la extensión TLE.
+ `version`: versión de la extensión TLE.
+ `superuser`: este valor es siempre `false` para sus extensiones TLE. Los permisos necesarios para crear la extensión TLE o actualizarla son los mismos que para crear otros objetos en la base de datos dada.
+ `trusted`: este valor es siempre `false` para una extensión TLE.
+ `relocatable`: este valor es siempre `false` para una extensión TLE.
+ `schema`: especifica el nombre del esquema en el que está instalada la extensión TLE.
+ `requires`: matriz que contiene los nombres de otras extensiones que necesita esta extensión TLE.
+ `description`: descripción detallada de la extensión TLE.
Para obtener más información acerca de los valores de salida, vea [Packaging Related Objects into an Extension > Extension Files](https://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) (Empaquetar objetos relacionados en una extensión > Archivos de extensión) en la documentación de PostgreSQL.
### Ejemplo de uso
```
SELECT * FROM pgtle.available_extension_versions();
```
## pgtle.extension\$1update\$1paths
La función `extension_update_paths` es una función de devolución de conjuntos. Devuelve una lista de todas las rutas de actualización posibles para una extensión TLE. Cada fila incluye las actualizaciones a un nivel superior o inferior disponibles para esa extensión TLE.
### Prototipo de función
```
pgtle.extension_update_paths(name)
```
### Rol
Ninguna.
### Argumentos
`name`: nombre de la extensión TLE desde la que se obtienen las rutas de actualización.
### Salida
+ `source`: versión de origen de una actualización.
+ `target`: versión de destino de una actualización.
+ `path`: ruta de actualización utilizada para actualizar una extensión TLE de una versión `source` a otra `target`, por ejemplo, `0.1--0.2`.
### Ejemplo de uso
```
SELECT * FROM pgtle.extension_update_paths('your-TLE');
```
## pgtle.install\$1extension
La función `install_extension` le permite instalar los artefactos que componen la extensión TLE en la base de datos, después de lo cual se puede crear mediante el comando `CREATE EXTENSION`.
### Prototipo de función
```
pgtle.install_extension(name text, version text, description text, ext text, requires text[] DEFAULT NULL::text[])
```
### Rol
Ninguna.
### Argumentos
+ `name`: nombre de la extensión TLE. Este valor se utiliza cuando se llama a `CREATE EXTENSION`.
+ `version`: versión de la extensión TLE.
+ `description`: descripción detallada acerca de la extensión TLE. Esta descripción se muestra en el campo `comment` de `pgtle.available_extensions()`.
+ `ext`: contenido de la extensión TLE. Este valor contiene objetos como funciones.
+ `requires`: parámetro opcional que especifica las dependencias de esta extensión TLE. La extensión `pg_tle` se añade automáticamente como una dependencia.
Muchos de estos argumentos son los mismos que se incluyen en un archivo de control de extensiones para instalar una extensión de PostgreSQL en el sistema de archivos de una instancia de PostgreSQL. Para obtener más información acerca de las extensiones de PostgreSQL, vea [Extension Files](http://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) (Archivos de extensión) en [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) (Empaquetar objetos relacionados en una extensión) en la documentación de PostgreSQL.
### Salida
Esta función devuelve `OK` en caso de éxito y `NULL` en caso de error.
+ `OK`: la extensión TLE se ha instalado correctamente en la base de datos.
+ `NULL`: la extensión TLE no se ha instalado correctamente en la base de datos.
### Ejemplo de uso
```
SELECT pgtle.install_extension(
'pg_tle_test',
'0.1',
'My first pg_tle extension',
$_pgtle_$
CREATE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 42;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.install\$1update\$1path
La función `install_update_path` proporciona una ruta de actualización entre dos versiones diferentes de una extensión TLE. Esta función permite a los usuarios de la extensión TLE actualizar su versión mediante la sintaxis `ALTER EXTENSION ... UPDATE`.
### Prototipo de función
```
pgtle.install_update_path(name text, fromvers text, tovers text, ext text)
```
### Rol
`pgtle_admin`
### Argumentos
+ `name`: nombre de la extensión TLE. Este valor se utiliza cuando se llama a `CREATE EXTENSION`.
+ `fromvers`: versión de origen de la extensión TLE utilizada para la actualización.
+ `tovers`: versión de destino de la extensión TLE utilizada para la actualización.
+ `ext`: contenido de la actualización. Este valor contiene objetos como funciones.
### Salida
Ninguna.
### Ejemplo de uso
```
SELECT pgtle.install_update_path('pg_tle_test', '0.1', '0.2',
$_pgtle_$
CREATE OR REPLACE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 21;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.register\$1feature
La función `register_feature` añade la característica interna de PostgreSQL especificada a la tabla `pgtle.feature_info`. Los enlaces de PostgreSQL son un ejemplo de una característica interna de PostgreSQL. El kit de desarrollo de Extensiones de lenguaje de confianza admite el uso de enlaces de PostgreSQL. Actualmente, esta función admite la siguiente característica.
+ `passcheck`: registra el enlace de comprobación de contraseñas con su procedimiento o función que personaliza el comportamiento de comprobación de contraseñas de PostgreSQL.
### Prototipo de función
```
pgtle.register_feature(proc regproc, feature pg_tle_feature)
```
### Rol
`pgtle_admin`
### Argumentos
+ `proc`: nombre de un procedimiento o función almacenados que se utilizarán en la característica.
+ `feature`: nombre de una característica `pg_tle` (como `passcheck`) para registrarla con la función.
### Salida
Ninguna.
### Ejemplo de uso
```
SELECT pgtle.register_feature('pw_hook', 'passcheck');
```
## pgtle.register\$1feature\$1if\$1not\$1exists
La función `pgtle.register_feature_if_not_exists` añade la función de PostgreSQL especificada a la tabla `pgtle.feature_info` e identifica la extensión TLE u otro procedimiento o función que utilice la característica. Para obtener más información sobre los enlaces y las extensiones de lenguaje de confianza, consulte[Uso de enlaces de PostgreSQL con sus extensiones TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md).
### Prototipo de función
```
pgtle.register_feature_if_not_exists(proc regproc, feature pg_tle_feature)
```
### Rol
`pgtle_admin`
### Argumentos
+ `proc`: nombre de una función procedimiento almacenado que contiene la lógica (código) que se utilizará como una característica de la extensión TLE. Por ejemplo, el código `pw_hook`.
+ `feature`: nombre de una la característica de PostgreSQL para registrarla para la función TLE. Actualmente, la única característica disponible es el enlace `passcheck`. Para obtener más información, consulte [Enlace de comprobación de contraseñas (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Salida
Devuelve `true` después de registrar la característica para la extensión especificada. Devuelve `false` si la característica ya está registrada.
### Ejemplo de uso
```
SELECT pgtle.register_feature_if_not_exists('pw_hook', 'passcheck');
```
## pgtle.set\$1default\$1version
La función `set_default_version` le permite especificar un `default_version` para su extensión TLE. Puede utilizar esta función para definir una ruta de actualización y designar la versión como la predeterminada para la extensión TLE. Cuando los usuarios de la base de datos especifican la extensión TLE en los comandos `CREATE EXTENSION` y `ALTER EXTENSION ... UPDATE`, esa versión de la extensión TLE se crea en la base de datos para ese usuario.
Esta función devuelve `true` en caso de realizarse correctamente. Si la extensión TLE especificada en el argumento `name` no existe, la función devuelve un error. Del mismo modo, si el `version` de la extensión TLE no existe, devuelve un error.
### Prototipo de función
```
pgtle.set_default_version(name text, version text)
```
### Rol
`pgtle_admin`
### Argumentos
+ `name`: nombre de la extensión TLE. Este valor se utiliza cuando se llama a `CREATE EXTENSION`.
+ `version`: versión de la extensión TLE para establecer la predeterminada.
### Salida
+ `true`: cuando la configuración de la versión predeterminada se realiza correctamente, la función devuelve `true`.
+ `ERROR`: devuelve un mensaje de error si no existe una extensión TLE con el nombre o la versión especificados.
### Ejemplo de uso
```
SELECT * FROM pgtle.set_default_version('my-extension', '1.1');
```
## pgtle.uninstall\$1extension(name)
La función `uninstall_extension` elimina todas las versiones de una extensión TLE de una base de datos. Esta función evita futuras llamadas de `CREATE EXTENSION` para evitar instalar la extensión TLE. Si la extensión TLE no existe en la base de datos, se genera un error.
La función `uninstall_extension` no elimina una extensión TLE que esté activa actualmente en la base de datos. Para eliminar una extensión TLE que está activa actualmente, debes llamar explícitamente a `DROP EXTENSION` para eliminarla.
### Prototipo de función
```
pgtle.uninstall_extension(extname text)
```
### Rol
`pgtle_admin`
### Argumentos
+ `extname`: nombre de la extensión TLE que se va a desinstalar. Este nombre es el mismo que se usó con `CREATE EXTENSION` para cargar la extensión TLE para usarla en una base de datos determinada.
### Salida
Ninguna.
### Ejemplo de uso
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test');
```
## pgtle.uninstall\$1extension(nombre, versión)
La función `uninstall_extension(name, version)` elimina la versión especificada de la extensión TLE de la base de datos. Esta función impide a `CREATE EXTENSION` y `ALTER EXTENSION` instalar o actualizar una extensión TLE a la versión especificada. Esta función también elimina todas las rutas de actualización posibles de la extensión TLE especificada. Esta función no desinstala la extensión TLE si actualmente está activa en la base de datos. Debe llamar explícitamente a `DROP EXTENSION` para eliminar la extensión TLE. Para desinstalar todas las versiones de una extensión TLE, consulte [pgtle.uninstall\$1extension(name)](#pgtle.uninstall_extension-name).
### Prototipo de función
```
pgtle.uninstall_extension(extname text, version text)
```
### Rol
`pgtle_admin`
### Argumentos
+ `extname`: nombre de la extensión TLE. Este valor se utiliza cuando se llama a `CREATE EXTENSION`.
+ `version`: versión de la extensión TLE que se va a desinstalar de la base de datos.
### Salida
Ninguna.
### Ejemplo de uso
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test', '0.2');
```
## pgtle.uninstall\$1extension\$1if\$1exists
La función `uninstall_extension_if_exists` elimina todas las versiones de una extensión TLE de una base de datos determinada. Si la extensión TLE no existe, la función la devuelve en silencio (no se genera ningún mensaje de error). Si la extensión especificada está activa actualmente en una base de datos, esta función no la elimina. Debe llamar explícitamente a `DROP EXTENSION` para eliminar la extensión TLE antes de utilizar esta función para desinstalar sus artefactos.
### Prototipo de función
```
pgtle.uninstall_extension_if_exists(extname text)
```
### Rol
`pgtle_admin`
### Argumentos
+ `extname`: nombre de la extensión TLE. Este valor se utiliza cuando se llama a `CREATE EXTENSION`.
### Salida
La función `uninstall_extension_if_exists` de vuelve `true` después de desinstalar la extensión especificada. Si la extensión especificada no existe, la función devuelve `false`.
+ `true`: devuelve `true` después de desinstalar la extensión TLE.
+ `false`: devuelve `false` cuando la extensión TLE no existe en la base de datos.
### Ejemplo de uso
```
SELECT * FROM pgtle.uninstall_extension_if_exists('pg_tle_test');
```
## pgtle.uninstall\$1update\$1path
La función `uninstall_update_path` elimina la ruta de actualización específica de una extensión TLE. Esto impide que `ALTER EXTENSION ... UPDATE TO` se utilice como ruta de actualización.
Si una de las versiones de esta ruta de actualización utiliza actualmente la extensión TLE, permanecerá en la base de datos.
Si la ruta de actualización especificada no existe, esta función genera un error.
### Prototipo de función
```
pgtle.uninstall_update_path(extname text, fromvers text, tovers text)
```
### Rol
`pgtle_admin`
### Argumentos
+ `extname`: nombre de la extensión TLE. Este valor se utiliza cuando se llama a `CREATE EXTENSION`.
+ `fromvers`: versión de origen de la extensión TLE utilizada en la ruta de actualización.
+ `tovers`: versión de destino de la extensión TLE utilizada en la ruta de actualización.
### Salida
Ninguna.
### Ejemplo de uso
```
SELECT * FROM pgtle.uninstall_update_path('pg_tle_test', '0.1', '0.2');
```
## pgtle.uninstall\$1update\$1path\$1if\$1exists
La función `uninstall_update_path_if_exists` es similar a `uninstall_update_path` en el sentido de que elimina la ruta de actualización especificada de una extensión TLE. Sin embargo, si la ruta de actualización no existe, esta función no generará ningún mensaje de error. En su lugar, la función devuelve `false`.
### Prototipo de función
```
pgtle.uninstall_update_path_if_exists(extname text, fromvers text, tovers text)
```
### Rol
`pgtle_admin`
### Argumentos
+ `extname`: nombre de la extensión TLE. Este valor se utiliza cuando se llama a `CREATE EXTENSION`.
+ `fromvers`: versión de origen de la extensión TLE utilizada en la ruta de actualización.
+ `tovers`: versión de destino de la extensión TLE utilizada en la ruta de actualización.
### Salida
+ `true`: la función ha actualizado correctamente la ruta de la extensión TLE.
+ `false`: la función no ha podido actualizar la ruta de la extensión TLE.
### Ejemplo de uso
```
SELECT * FROM pgtle.uninstall_update_path_if_exists('pg_tle_test', '0.1', '0.2');
```
## pgtle.unregister\$1feature
La función `unregister_feature` proporciona una forma de eliminar las funciones que se han registrado para usar características `pg_tle`, como los enlaces. Para obtener información sobre el registro de una característica, consulte [pgtle.register\$1feature](#pgtle.register_feature).
### Prototipo de función
```
pgtle.unregister_feature(proc regproc, feature pg_tle_features)
```
### Rol
`pgtle_admin`
### Argumentos
+ `proc`: nombre de una función almacenada para registrarse en una característica de `pg_tle`.
+ `feature`: nombre de la característica `pg_tle` para registrarla con la función. Por ejemplo, `passcheck` es una característica que se puede registrar para que la utilicen las extensiones de lenguaje de confianza que desarrolle. Para obtener más información, consulte [Enlace de comprobación de contraseñas (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Salida
Ninguna.
### Ejemplo de uso
```
SELECT * FROM pgtle.unregister_feature('pw_hook', 'passcheck');
```
## pgtle.unregister\$1feature\$1if\$1exists
La función `unregister_feature` proporciona una forma de eliminar las funciones que se registraron para usar funciones `pg_tle`, como los enlaces. Para obtener más información, consulte [Uso de enlaces de PostgreSQL con sus extensiones TLE](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md). Devuelve `true` después de anular satisfactoriamente el registro de la función. Devuelve `false` si la función no se ha registrado.
Para obtener información sobre el registro de funciones `pg_tle` para sus extensiones TLE, consulte [pgtle.register\$1feature](#pgtle.register_feature).
### Prototipo de función
```
pgtle.unregister_feature_if_exists('proc regproc', 'feature pg_tle_features')
```
### Rol
`pgtle_admin`
### Argumentos
+ `proc`: nombre de la función almacenada que se registró para incluir una función `pg_tle`.
+ `feature`: nombre de la función `pg_tle` que se registró con la extensión de lenguaje de confianza.
### Salida
Devuelve `true` o `false`, de la siguiente manera.
+ `true`: la función ha cancelado satisfactoriamente el registro de la función de la extensión.
+ `false`: la función no ha podido anular el registro de la función de la extensión TLE.
### Ejemplo de uso
```
SELECT * FROM pgtle.unregister_feature_if_exists('pw_hook', 'passcheck');
```
# Referencia de enlaces para Extensiones de lenguaje de confianza para PostgreSQL
Extensiones de lenguaje de confianza para PostgreSQL admite los enlaces de PostgreSQL. Un *enlace* es un mecanismo interno de devolución de llamada disponible para los desarrolladores para ampliar la funcionalidad principal de PostgreSQL. Mediante el uso de enlaces, los desarrolladores pueden implementar sus propias funciones o procedimientos para utilizarlos durante diversas operaciones de bases de datos, modificando así el comportamiento de PostgreSQL de alguna manera. Por ejemplo, puede utilizar un enlace `passcheck` para personalizar la forma en que PostgreSQL gestiona las contraseñas proporcionadas al crear o cambiar las contraseñas de los usuarios (roles).
Consulte la siguiente documentación para obtener información sobre el enlace de passcheck disponible para sus extensiones TLE. Para obtener más información sobre los enlaces disponibles, incluido el enlace de autenticación del cliente, consulte [Trusted Language Extensions hooks](https://github.com/aws/pg_tle/blob/main/docs/04_hooks.md).
## Enlace de comprobación de contraseñas (passcheck)
El enlace `passcheck` se utiliza para personalizar el comportamiento de PostgreSQL durante el proceso de comprobación de contraseñas para los siguientes comandos SQL y el metacomando `psql`.
+ `CREATE ROLE username ...PASSWORD`: para obtener más información, consulte [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) en la documentación de PostgreSQL.
+ `ALTER ROLE username...PASSWORD`: para obtener más información, consulte [ALTER ROLE](https://www.postgresql.org/docs/current/sql-alterrole.html) en la documentación de PostgreSQL.
+ `\password username`: este metacomando `psql` interactivo cambia de forma segura la contraseña del usuario especificado mediante un hash de la contraseña antes de utilizar la sintaxis `ALTER ROLE ... PASSWORD` de forma transparente. El metacomando es un contenedor seguro para el comando `ALTER ROLE ... PASSWORD`, por lo que el enlace se aplica al comportamiento del metacomando `psql`.
Para ver un ejemplo, consulta [Lista de códigos del enlace password\$1check](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md#PostgreSQL_trusted_language_extension-example-hook_code_listing).
**Contents**
+ [Prototipo de función](#passcheck_hook-prototype)
+ [Argumentos](#passcheck_hook-arguments)
+ [Configuración](#passcheck_hook-configuration)
+ [Notas de uso](#passcheck_hook-usage)
### Prototipo de función
```
passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
```
### Argumentos
La función de enlace `passcheck` acepta los argumentos siguientes:
+ `username`: el nombre (como texto) del rol (nombre de usuario) que establece una contraseña.
+ `password`: la contraseña en texto sin formato o con hash. La contraseña introducida debe coincidir con el tipo especificado en `password_type`.
+ `password_type`: especifique el formato `pgtle.password_type` de la contraseña. Este formato puede ser uno de los siguientes:
+ `PASSWORD_TYPE_PLAINTEXT`: una contraseña sin formato.
+ `PASSWORD_TYPE_MD5`: una contraseña que se ha cifrado con hash mediante el algoritmo MD5 (resumen de mensaje 5).
+ `PASSWORD_TYPE_SCRAM_SHA_256`: una contraseña que se ha cifrado con hash mediante el algoritmo SCRAM-SHA-256.
+ `valid_until`: especifica el momento en que la contraseña deja de ser válida. Este argumento es opcional. Si utiliza este argumento, especifique la hora como valor `timestamptz`.
+ `valid_null`: si este valor booleano está establecido en `true`, la opción `valid_until` se establece en `NULL`.
### Configuración
La función `pgtle.enable_password_check` controla si el enlace de passcheck está activo. El enlace de passcheck tiene tres ajustes posibles.
+ `off`: desactiva el enlace de comprobación de contraseñas `passcheck`. Este es el valor predeterminado.
+ `on`: activa el enlace de comprobación de contraseñas `passcode` para cotejarlas con la tabla.
+ `require`: requiere que se defina un enlace de comprobación de contraseñas.
### Notas de uso
Para activar o desactivar el enlace `passcheck`, debe modificar el grupo de parámetros de base de datos personalizado de su instancia de base de datos de RDS para PostgreSQL.
Para Linux, macOS o Unix:
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Para Windows:
```
aws rds modify-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name your-custom-parameter-group ^
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```