¿Cómo puedo solucionar los problemas de almacenamiento local en instancias de bases de datos de Aurora compatibles 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.

La clase de instancia determina el tamaño del almacenamiento local. 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 local disponible en cada instancia de base de datos.

Resolución

Resolución del error "No space left on device"

Se muestra 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:

• Modificar tablas grandes.
• Añadir índices en tablas grandes o realizar un REINDEX.
• Realizar consultas SELECT de gran tamaño con las cláusulas JOIN complejas, GROUP BY u ORDER BY.
• Ejecutar VACUUM FULL o pg_repack.

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 que 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, puedes 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 ha cambiado después de las ejecuciones posteriores.

Las columnas temp_files y temp_bytes de la vista pg_stat_database recopilan estadísticas del valor acumulado de todos los archivos temporales, independientemente de cuándo los hayas creado. 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 maintenance_work_mem y work_mem en el sitio web de PostgreSQL.

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 la clase de instancia para tu instancia de Aurora, con el fin de que la instancia de base de datos tenga más almacenamiento local disponible.

Comprobación de los archivos de registro de los tipos de clases de instancia de rendimiento ampliable

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 ampliable, 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 deberse a un registro excesivo o a que el sistema retiene el registro de errores durante mucho tiempo.

Para identificar el parámetro que provoca un registro excesivo, sigue estos pasos:

1. Analiza los registros de PostgreSQL para encontrar los registros más grandes.
2. Identifica qué parámetro es responsable de la mayoría de las entradas de esos registros.
3. Modifica el parámetro que provoca un registro excesivo.

Parámetros 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

De forma predeterminada, cuando ejecutas repetidamente una consulta que produce un error, PostgreSQL registra los errores en el registro de errores de PostgreSQL. Para evitar un uso excesivo del almacenamiento, revisa los errores del registro y, a continuación, corrige la consulta fallida. Como alternativa, reduce 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. Esto proporciona más almacenamiento local disponible para la instancia de base de datos de Aurora.

Información relacionada

Prácticas recomendadas con Amazon Aurora PostgreSQL