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

6 minutos de lectura
0

Tengo problemas con el almacenamiento local en mis instancias de bases de datos Edition compatibles con Amazon Aurora PostgreSQL.

Descripción breve

Las instancias de base de datos que se encuentran en los clústeres de Amazon Aurora tienen dos tipos de almacenamiento:

  • Almacenamiento utilizado para datos persistentes (volumen de clúster compartido). Para obtener más información, consulte Qué contiene el volumen del clúster.
  • Almacenamiento local para cada instancia de Aurora del clúster, según la clase de instancia. Este tamaño de almacenamiento está vinculado a la clase de instancia y solo se puede cambiar moviéndose a una clase de instancia de base de datos más grande. Aurora, compatible con PostgreSQL, utiliza el almacenamiento local para almacenar registros de errores y archivos temporales. Para obtener más información, consulte Límites de almacenamiento temporal para Aurora PostgreSQL.

Resolución

Puede supervisar el espacio de almacenamiento local asociado a la instancia o el nodo de base de datos de Aurora mediante la métrica de Amazon CloudWatch para FreeLocalStorage. Esta métrica informa de la cantidad de almacenamiento disponible en cada instancia de base de datos para tablas y registros temporales. Para obtener más información, consulte Supervisión de las métricas de Amazon Aurora con Amazon CloudWatch.

Si el almacenamiento local de Aurora está lleno, siga estos pasos para solucionar los problemas en función del error que reciba.

Las tablas o los archivos temporales utilizan el espacio de almacenamiento local

«ERROR: no se ha podido escribir el bloque XXXXXXXX del archivo temporal: No queda espacio en el dispositivo.»

Este error se produce cuando se agota el almacenamiento temporal en la instancia de base de datos. Esto puede deberse a varias causas, incluidas las operaciones que:

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

Utilice estos métodos para comprobar el tamaño de las tablas temporales y los archivos temporales:

1.    Para los archivos temporales, active el parámetro log_temp_files en la instancia de base de datos compatible con Aurora PostgreSQL. Este parámetro registra el uso de archivos temporales que superan el número de kilobytes especificado. Una vez activado este parámetro, se crea una entrada de registro para cada archivo temporal cuando se elimina el archivo. 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. Utilice este parámetro para identificar los detalles de los archivos temporales y, a continuación, relacionarlos con la métrica FreeLocalStorage.

Nota: La activación del parámetro log_temp_files puede provocar un registro excesivo en la instancia de base de datos compatible con Aurora PostgreSQL. Por este motivo, se recomienda comprobar el tamaño de los archivos de registro compatibles con Aurora PostgreSQL antes de activar log_temp_files. Si los archivos de registro consumen el espacio máximo del almacenamiento local, reduzca el valor de rds.log_retention para recuperar espacio. El valor predeterminado de rds.log_retention es de tres días.

También puede revisar los archivos temporales mediante el delta de las ejecuciones posteriores de este comando:

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

Nota: En la columna temp_files, se cuentan todos los archivos temporales, independientemente de cuándo se haya creado el archivo temporal (por ejemplo, mediante clasificación o hashing). Las columnas temp_files y temp_bytes de la vista pg_stat_database recopilan estadísticas del valor acumulado. Este valor se puede restablecer mediante la función pg_stat_reset() o reiniciando la instancia de base de datos. Para obtener más información, consulte la documentación de PostgreSQL para ver las Funciones de estadísticas adicionales.

Si utiliza Aurora PostgreSQL 10 o una versión posterior, puede supervisar temp_bytes y temp_files mediante Información de rendimiento. Esto también se aplica a Amazon Relational Database Service (Amazon RDS) para PostgreSQL. La Información de rendimiento proporciona contadores nativos para las métricas internas del motor de base de datos, además de los eventos de espera. Para obtener más información, consulte Contadores nativos de Amazon RDS para PostgreSQL.

También puede aumentar maintenance_work_mem y work_mem para asignar más memoria a los procesos que realizan la operación. Esto utiliza más memoria para la operación, lo que puede utilizar menos espacio de almacenamiento temporal en disco. Para obtener más información sobre estos parámetros, consulte 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 para evitar quedarse sin memoria. Para obtener más información, consulte la referencia de Amazon Aurora PostgreSQL.

2.    Para tablas temporales, ejecute una consulta como esta:

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, puede administrar el uso de la capacidad de almacenamiento local disponible. También puede pasar a una clase de instancia superior para su instancia de Aurora, con el fin de que la instancia tenga más almacenamiento local disponible.

Almacenamiento local utilizado por los archivos de registro

El registro excesivo también puede provocar que la instancia de base de datos se quede sin almacenamiento local. Estos son algunos ejemplos de parámetros de registro que pueden consumir el espacio de almacenamiento local. El consumo puede deberse a un registro excesivo o a la retención del registro de errores durante mucho tiempo.

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

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

Si ejecuta repetidamente una consulta que produce un error, PostgreSQL registrará los errores en el registro de errores de PostgreSQL de forma predeterminada. Revise los errores registrados y, a continuación, corrija la consulta fallida para evitar que los registros utilicen un almacenamiento excesivo. También puede reducir el valor predeterminado de rds.log_retention (tres días) para recuperar el espacio utilizado en los registros de errores.

Si se requiere un registro excesivo y se está limitando el almacenamiento local disponible debido a los archivos de registro, considere la posibilidad de cambiar a una clase de instancia superior. Esto significa que la instancia de base de datos de Aurora tiene más almacenamiento local disponible.


Información relacionada

Prácticas recomendadas con Amazon Aurora PostgreSQL

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año