¿Cómo puedo solucionar los problemas de almacenamiento local en instancias de Aurora compatible con PostgreSQL?

Descripción corta

Hay dos tipos de almacenamiento para Amazon Aurora: Almacenamiento de datos persistentes, como el volumen de clúster compartido, y almacenamiento local para cada instancia de base de datos.

El tamaño del almacenamiento local está vinculado a la clase de instancia. Solo puedes cambiar el tamaño de almacenamiento si pasas a una clase de instancia de base de datos más grande. Para almacenar registros de errores y archivos temporales, Aurora compatible con PostgreSQL utiliza el almacenamiento local. Para los tipos de instancias que no son de clase T, el sistema escribe los registros en un volumen dedicado que el sistema limpia automáticamente.

Para supervisar el espacio de almacenamiento local asociado al nodo o la instancia de base de datos de Aurora, usa la métrica de Amazon CloudWatch FreeLocalStorage. Esta métrica indica la cantidad de almacenamiento disponible para las tablas temporales de cada instancia de base de datos.

Resolución

No queda espacio de almacenamiento local

Aparece el mensaje de error «could not write block ###### of temporary file: No space left on device» cuando no queda espacio de almacenamiento temporal. Este error puede producirse por las siguientes operaciones:

• Modifican tablas grandes
• Agregan índices en tablas grandes
• Realizan las consultas SELECT de gran tamaño con las cláusulas complejas JOINs, GROUP BY u ORDER BY.

Comprobación del tamaño del archivo temporal

Para identificar los detalles del archivo temporal, activa el parámetro log_temp_files en la instancia de base de datos de Aurora compatible con PostgreSQL. A continuación, compara los archivos temporales con la métrica FreeLocalStorage.

El parámetro log_temp_files registra cada archivo temporal que supera el número de kilobytes especificado. El valor 0 registra toda la información de los archivos temporales. Un valor positivo registra solo los archivos que son mayores o iguales al número especificado de kilobytes. El valor predeterminado es -1, que desactiva el registro temporal de archivos. Al activar el parámetro log_temp_files, puede provocar un registro excesivo en la instancia de base de datos de Aurora compatible con PostgreSQL.

Por este motivo, se recomienda comprobar el tamaño de los archivos de registro de Aurora compatible con PostgreSQL antes de activar log_temp_files. Si los archivos de registro consumen el espacio máximo del almacenamiento local, reduce el valor de rds.log_retention para recuperar espacio. El valor predeterminado de rds.log_retention es de tres días.

Para revisar el tamaño del archivo temporal, ejecuta el siguiente comando varias veces:

maxiops=> select datname, temp_files , pg_size_pretty(temp_bytes) as temp_file_size  FROM   pg_stat_database order by temp_bytes desc;

Nota: Utiliza la salida que cambiaste después de las ejecuciones posteriores.

En la columna temp_files, se cuentan todos los archivos temporales, independientemente de cuándo se haya creado el archivo temporal. Las columnas temp_files y temp_bytes de la vista pg_stat_database recopilan estadísticas del valor acumulado. Para restablecer el valor, utiliza la función pg_stat_reset() o reinicia la instancia de base de datos. Para obtener más información, consulta Additional statistics functions (Funciones estadísticas adicionales) en el sitio web de PostgreSQL.

Si utilizas Aurora compatible con PostgreSQL 10 o una versión posterior, puedes supervisar temp_bytes y temp_files con Información de rendimiento. Información de rendimiento proporciona contadores nativos para las métricas internas del motor de base de datos y los eventos de espera. También puedes activar Información de rendimiento y usar Database Insights para supervisar los registros de la base de datos.

Para asignar más memoria a los procesos que realizan la operación, puedes aumentar los parámetros maintenance_work_mem y work_mem. Este método utiliza más memoria para la operación y menos almacenamiento temporal en disco. Para obtener más información sobre estos parámetros, consulta la documentación de PostgreSQL sobre maintenance_work_mem y work_mem.

Se recomienda establecer los valores de maintenance_work_mem y work_mem a nivel de consulta o sesión. De este modo, tus instancias de base de datos no se quedan sin memoria. Para obtener más información, consulta Referencia de Amazon Aurora PostgreSQL.

Comprobación del tamaño de la tabla temporal

Ejecuta la siguiente consulta:

maxiops=> SELECT n.nspname as SchemaName  
,c.relname as RelationName  
,CASE c.relkind  
WHEN 'r' THEN 'table'  
WHEN 'v' THEN 'view'  
WHEN 'i' THEN 'index'  
WHEN 'S' THEN 'sequence'  
WHEN 's' THEN 'special'  
END as RelationType  
,pg_catalog.pg_get_userbyid(c.relowner) as RelationOwner  
,pg_size_pretty(pg_relation_size(n.nspname ||'.'|| c.relname)) as RelationSize  
FROM pg_catalog.pg_class c  
LEFT JOIN pg_catalog.pg_namespace n  
    ON n.oid = c.relnamespace  
WHERE  c.relkind IN ('r','s')  
AND  (n.nspname !~ '^pg_toast' and nspname like 'pg_temp%')  
ORDER BY pg_relation_size(n.nspname ||'.'|| c.relname) DESC;

Se recomienda supervisar de cerca la aplicación y ver qué transacciones crean tablas temporales. De este modo, puedes administrar el uso de la capacidad de almacenamiento local disponible. También puedes cambiar a la clase de instancia superior para tu instancia de Aurora, con el fin de que la instancia de base de datos tenga más almacenamiento local disponible.

Archivos de registro (aplicables solo para los tipos de clases de instancia de rendimiento ampliable) que utilizan almacenamiento local

Un registro excesivo puede provocar que la instancia de base de datos se quede sin almacenamiento local solo para los tipos de clases de instancia de rendimiento estable, como db.t2, db.t3 y db.t4g. Los siguientes son ejemplos de parámetros de registro que pueden consumir el espacio de almacenamiento local. El consumo puede producirse por un registro excesivo o la retención del registro de errores durante mucho tiempo.

Para identificar el parámetro que provoca el registro excesivo, analiza los registros de PostgreSQL para encontrar los registros más grandes. A continuación, identifica qué parámetro es responsable de la mayoría de las entradas de esos registros. Después, puedes modificar el parámetro que provoca el registro excesivo.

Resultado de ejemplo:

rds.log_retention_period  
auto_explain.log_min_duration  
log_connections  
log_disconnections  
log_lock_waits  
log_min_duration_statement  
log_statement  
log_statement_stats

Si ejecutas repetidamente una consulta que produce un error, PostgreSQL registrará los errores en el registro de errores de PostgreSQL de forma predeterminada. Para evitar que los registros de errores utilicen un almacenamiento excesivo, revisa los errores del registro y, a continuación, corrige la consulta fallida. También puedes reducir el valor predeterminado de tres días para rds.log_retention para recuperar el espacio que utilizan los registros de errores.

Se recomienda cambiar la clase de instancia por una clase de instancia más grande para evitar un registro excesivo. De esta forma, la instancia de base de datos de Aurora tiene más almacenamiento local disponible.

Información relacionada

Prácticas recomendadas con Amazon Aurora PostgreSQL