Administración de Amazon Aurora PostgreSQL
La siguiente sección trata sobre la administración del rendimiento y el escalado de un clúster de bases de datos de Amazon Aurora PostgreSQL. También incluye información sobre otras tareas de mantenimiento.
Temas
- Escalado de las instancias de base de datos Aurora PostgreSQL
- Número máximo de conexiones a una instancia de base de datos Aurora PostgreSQL
- Límites de almacenamiento temporal de Aurora PostgreSQL
- Páginas enormes para Aurora PostgreSQL
- Pruebas de Amazon Aurora PostgreSQL mediante consultas de inserción de errores
- Visualización del estado del volumen para un clúster de bases de datos de Aurora PostgreSQL
- Especificación del disco RAM para stats_temp_directory
- Administración de archivos temporales con PostgreSQL
Escalado de las instancias de base de datos Aurora PostgreSQL
Puede escalar las instancias de base de datos Aurora PostgreSQL de dos formas, mediante el escalado de instancia y mediante el escalado de lectura. Para obtener más información acerca del escalado de lectura, consulte Escalado de lectura.
Para escalar el clúster de bases de datos de Aurora PostgreSQL, modifique la clase de instancia de base de datos para cada instancia de base de datos del clúster de bases de datos. Aurora PostgreSQL admite varias clases de instancia de base de datos optimizadas para Aurora. No utilice las clases de instancia db.t2 o db.t3 con clústeres de Aurora que tengan más de 40 terabytes (TB).
nota
Recomendamos que las clases de instancia de base de datos T se utilicen solo para los servidores de desarrollo y de pruebas, o para otros servidores que no se utilicen para la producción. Para obtener más detalles sobre las clases de instancia T, consulte Tipos de clase de instancia de base de datos.
El escalado no es instantáneo. Puede llevar 15 minutos o más completar el cambio a una clase de instancia de base de datos diferente. Si utiliza este enfoque para modificar la clase de instancia de base de datos, aplique el cambio durante el siguiente periodo de mantenimiento programado (en lugar de hacerlo de inmediato) para evitar afectar a los usuarios.
Como alternativa a modificar la clase de instancia de base de datos directamente, puede minimizar el tiempo de inactividad por medio de las características de alta disponibilidad de Amazon Aurora. En primer lugar, agregue una réplica de Aurora al clúster. Cuando cree la réplica, elija el tamaño de clase de la instancia de base de datos que desea utilizar para el clúster. Cuando la réplica de Aurora se sincroniza con el clúster, se realiza la conmutación por error a la réplica recién agregada. Para obtener más información, consulte Réplicas de Aurora y Conmutación por error rápida con Amazon Aurora PostgreSQL.
Para ver especificaciones detalladas de las clases de instancia de base de datos admitidas en Aurora PostgreSQL, consulte Motores de base de datos compatibles para clases de instancia de base de datos.
Número máximo de conexiones a una instancia de base de datos Aurora PostgreSQL
Un clúster de base de datos de Aurora PostgreSQL asigna recursos en función de la clase de instancia de base de datos y la memoria disponible. Cada conexión al clúster de base de datos consume cantidades incrementales de estos recursos, como memoria y CPU. La memoria consumida por conexión varía según el tipo de consulta, el recuento y si se utilizan tablas temporales. Incluso una conexión inactiva consume memoria y CPU. Esto se debe a que, cuando las consultas se ejecutan en una conexión, se asigna más memoria a cada consulta y esta no se libera por completo, ni siquiera cuando el procesamiento se detiene. Por lo tanto, le recomendamos que se asegure de que sus aplicaciones no mantienen las conexiones inactivas, ya que malgastan recursos y afectan negativamente al rendimiento. Para obtener más información, consulte Resources consumed by idle PostgreSQL connections
El número máximo de conexiones permitidas por una instancia de base de datos de Aurora PostgreSQL está determinado por el valor del parámetro max_connections especificado en el grupo de parámetros para esa instancia de base de datos. La configuración ideal para el parámetro max_connections es una que admita todas las conexiones de clientes que su aplicación necesita, sin un exceso de conexiones no usadas, más al menos 3 conexiones más para soportar la automatización de AWS. Antes de modificar la configuración del parámetro max_connections, le recomendamos que considere las siguientes acciones:
-
Si el valor de
max_connectionses muy bajo, la instancia de base de datos de Aurora PostgreSQL podría no tener suficientes conexiones disponibles cuando los clientes intenten conectarse. Si esto sucede, intenta conectarse mediante mensajes de generación de errores depsqlcomo los siguientes:psql: FATAL: remaining connection slots are reserved for non-replication superuser connections -
Si el valor de
max_connectionsexcede el número de conexiones que realmente se necesitan, las conexiones no utilizadas pueden hacer que el rendimiento se degrade.
El valor predeterminado de max_connections se obtiene de la siguiente función LEAST de Aurora PostgreSQL:
LEAST({DBInstanceClassMemory/9531392},5000).
Si desea cambiar el valor de max_connections, necesita crear un grupo de parámetros de clúster de base de datos personalizado para cambiarlo valor allí. Después de aplicar el grupo de parámetros de base de datos personalizado al clúster, asegúrese de reiniciar la instancia principal para que se aplique el nuevo valor. Para obtener más información, consulte Parámetros de Amazon Aurora PostgreSQL. y Creación de un grupo de parámetros de clúster de base de datos.
sugerencia
Si sus aplicaciones abren y cierran conexiones con frecuencia, o mantienen abierto un gran número de conexiones de larga duración, le recomendamos que utilice Amazon RDS Proxy. El RDS Proxy es un proxy de base de datos totalmente administrado y de alta disponibilidad que utiliza agrupación de conexiones para compartir conexiones de base de datos de forma segura y eficiente. Para obtener más información acerca de RDS Proxy, consulteUso de Amazon RDS Proxy para Aurora.
Para obtener más información acerca de cómo las instancias de Aurora Serverless v2 manejan este parámetro, consulte Número máximo de conexiones para Aurora Serverless v2.
Límites de almacenamiento temporal de Aurora PostgreSQL
Aurora PostgreSQL almacena tablas e índices en el subsistema de almacenamiento de Aurora. Aurora PostgreSQL utiliza almacenamiento temporal independiente para archivos temporales no persistentes. Esto incluye archivos que se utilizan para fines tales como ordenar conjuntos de datos grandes durante el procesamiento de consultas o para operaciones de creación de índices. Para obtener más información, consulte el artículo How can I troubleshoot local storage issues in Aurora PostgreSQL-Compatible instances?
Estos volúmenes de almacenamiento local están respaldados por Amazon Elastic Block Store y pueden ampliarse utilizando una clase de instancia de base de datos mayor. Para obtener más información acerca del almacenamiento, consulte Almacenamiento y fiabilidad de Amazon Aurora. También puede aumentar el almacenamiento local de objetos temporales mediante un tipo de instancia habilitado para NVMe y objetos temporales habilitados para las lecturas optimizadas de Aurora. Para obtener más información, consulte Mejora del rendimiento de las consultas de Aurora PostgreSQL con lecturas optimizadas de Aurora .
nota
Puede ver los eventos storage-optimization al escalar las instancias de base de datos, por ejemplo, de db.r5.2xlarge a db.r5.4xlarge.
En la siguiente tabla se muestra la cantidad máxima de almacenamiento temporal disponible para cada clase de instancia de base de datos de Aurora PostgreSQL. Para obtener más información sobre la compatibilidad de la clase de instancia de la base de datos con Aurora, consulte Clases de instancia de base de datos de Aurora.
| Clase de instancia de base de datos | Almacenamiento temporal máximo disponible (GiB) |
|---|---|
| db.x2g.16xlarge | 1829 |
| db.x2g.12xlarge | 1606 |
| db.x2g.8xlarge | 1071 |
| db.x2g.4xlarge | 535 |
| db.x2g.2xlarge | 268 |
| db.x2g.xlarge | 134 |
| db.x2g.large | 67 |
| db.r7g.16xlarge | 1008 |
| db.r7g.12xlarge | 756 |
| db.r7g.8xlarge | 504 |
| db.r7g.4xlarge | 252 |
| db.r7g.2xlarge | 126 |
| db.r7g.xlarge | 63 |
| db.r7g.large | 32 |
| db.r6g.16xlarge | 1008 |
| db.r6g.12xlarge | 756 |
| db.r6g.8xlarge | 504 |
| db.r6g.4xlarge | 252 |
| db.r6g.2xlarge | 126 |
| db.r6g.xlarge | 63 |
| db.r6g.large | 32 |
| db.r6i.32xlarge | 1829 |
| db.r6i.24xlarge | 1500 |
| db.r6i.16xlarge | 1008 |
| db.r6g.12xlarge | 748 |
| db.r6i.8xlarge | 504 |
| db.r6i.4xlarge | 249 |
| db.r6i.2xlarge | 124 |
| db.r6i.xlarge | 62 |
| db.r6i.large | 31 |
| db.r5.24xlarge | 1500 |
| db.r5.16xlarge | 1008 |
| db.r5.12xlarge | 748 |
| db.r5.8xlarge | 504 |
| db.r5.4xlarge | 249 |
| db.r5.2xlarge | 124 |
| db.r5.xlarge | 62 |
| db.r5.large | 31 |
| db.r4.16xlarge | 960 |
| db.r4.8xlarge | 480 |
| db.r4.4xlarge | 240 |
| db.r4.2xlarge | 120 |
| db.r4.xlarge | 60 |
| db.r4.large | 30 |
| db.t4g.large | 16.5 |
| db.t4g.medium | 8.13 |
| db.t3.large | 16 |
| db.t3.medium | 7.5 |
nota
Los tipos de instancias compatibles con NVMe pueden aumentar el espacio temporal disponible hasta el tamaño total de NVMe. Para obtener más información, consulte Mejora del rendimiento de las consultas de Aurora PostgreSQL con lecturas optimizadas de Aurora .
Puede supervisar el almacenamiento temporal disponible para una instancia de base de datos con la métrica de CloudWatch FreeLocalStorage, que se describe en Métricas de Amazon CloudWatch para Amazon Aurora. (Esto no se aplica a Aurora Serverless v2.)
Para algunas cargas de trabajo, puede reducir la cantidad de almacenamiento temporal asignando más memoria a los procesos que están realizando la operación. Para aumentar la memoria disponible de una operación, se aumentan los valores de los parámetros work_mem
Páginas enormes para Aurora 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 Aurora PostgreSQL disponibles actualmente.
El parámetro Huge_pages se activa de forma predeterminada para todas las clases de instancia de base de datos que no sean las siguientes: t3.medium, db.t3.large, db.t4g.medium y db.t4g.large. No puede cambiar el valor del parámetro huge_pages ni desactivar esta característica en las clases de instancias compatibles de Aurora PostgreSQL.
