Comment puis-je résoudre les problèmes de stockage local dans les instances compatibles avec Aurora PostgreSQL ?

Brève description

Il existe deux types de stockage pour les instances de base de données qui se trouvent dans des clusters Amazon Aurora :

• Le stockage utilisé pour les données persistantes (volume de cluster partagé). Pour plus d'informations, consultez la section Contenu du volume de cluster.
• Stockage local pour chaque instance Aurora du cluster, en fonction de la classe d'instance. Cette taille de stockage est liée à la classe d'instance et ne peut être modifiée qu'en passant à une classe d'instance de base de données plus grande. La compatibilité Aurora PostgreSQL utilise le stockage local pour stocker les journaux d'erreurs et les fichiers temporaires. Pour plus d'informations, consultez la section Limites de stockage temporaires pour Aurora PostgreSQL.

Solution

Vous pouvez contrôler l'espace de stockage local associé au nœud ou à l'instance de base de données Aurora à l'aide de la métrique Amazon CloudWatch pour FreeLocalStorage. Cette métrique indique la quantité d'espace de stockage disponible pour chaque instance de base de données pour les journaux et les tables temporaires. Pour plus d'informations, consultez Surveillance des métriques Amazon Aurora avec Amazon CloudWatch.

Si votre stockage local Aurora est plein, suivez ces étapes de résolution des problèmes en fonction de l'erreur que vous recevez.

L'espace de stockage local est utilisé par des fichiers ou des tables temporaires.

« ERROR: could not write block XXXXXXXX of temporary file: No space left on device. »

Cette erreur se produit lorsque le stockage temporaire est épuisé sur l'instance de base de données. Cela peut avoir plusieurs causes, notamment des opérations qui :

• Modifier les grandes tables
• Ajouter des index sur de grands tableaux
• Effectuez de grandes requêtes SELECT avec des clauses JOINS, GROUP BY ou ORDER BY complexes.

Utilisez ces méthodes suivantes pour vérifier la taille des fichiers et des tables temporaires :

1.    Pour les fichiers temporaires, activez le paramètre log_temp_files sur l'instance de base de données compatible avec Aurora PostgreSQL. Ce paramètre journalise l'utilisation de fichiers temporaires qui dépassent le nombre de kilo-octets spécifié. Une fois ce paramètre activé, une entrée de journal est créée pour chaque fichier temporaire lorsque le fichier est supprimé. La valeur 0 enregistre toutes les informations de fichiers temporaires. Une valeur positive journalise uniquement les fichiers supérieurs ou égaux au nombre de kilo-octets spécifié. La valeur par défaut est -1, ce qui désactive la journalisation des fichiers temporaires. Utilisez ce paramètre pour identifier les détails de fichier temporaire, puis associer ces fichiers temporaires à la métrique FreeLocalStorage.

Remarque : l'activation du paramètre log_temp_files peut entraîner une journalisation excessive sur l'instance de base de données compatible avec Aurora PostgreSQL. Par conséquent, c'est une bonne pratique de vérifier la taille des fichiers journaux compatibles avec Aurora PostgreSQL avant d'activer log_temp_files. Si les fichiers journaux occupent le maximum d'espace pour le stockage local, réduisez la valeur de rds.log_retention pour récupérer de l'espace. La valeur par défaut de rds.log_retention est de trois jours.

Vous pouvez également vérifier les fichiers temporaires en utilisant le delta des exécutions de cette commande :

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

Remarque : dans la colonne temp_files, tous les fichiers temporaires sont comptés, quelle que soit leur date de création (par exemple, par tri ou hachage). Les colonnes temp_files et temp_bytes dans la vue pg_stat_database contiennent des statistiques pour la valeur cumulée. Cette valeur peut être réinitialisée à l'aide de la fonction pg_stat_reset() ou en redémarrant l'instance de base de données. Pour plus d'informations, consultez la documentation PostgreSQL dans laquelle vous trouverez des fonctions statistiques supplémentaires.

Si vous utilisez la compatibilité Aurora PostgreSQL 10 ou une version ultérieure, vous pouvez contrôler temp_bytes et temp_files à l'aide de Performance Insights. Cela s’applique également à Amazon Relational Database Service (Amazon RDS) pour PostgreSQL. En plus des événements d'attente, Performance Insights fournit également des compteurs natifs pour les métriques internes de votre moteur de base de données. Pour plus d'informations, consultez Compteurs natifs pour Amazon RDS for PostgreSQL.

Vous pouvez également augmenter maintenance_work_mem et work_mem afin d'allouer plus de mémoire aux processus qui effectuent l'opération. Davantage de mémoire est alors utilisée pour l'opération, ce qui permet d'utiliser moins de stockage temporaire sur le disque. Pour plus d'informations sur ces paramètres, consultez la documentation PostgreSQL pour maintenance_work_mem et work_mem. Il est recommandé de définir les valeurs pour maintenance_work_mem et work_mem au niveau de la requête ou de la séance afin d'éviter de manquer de mémoire. Pour plus d'informations, consultez la section Référence Amazon Aurora PostgreSQL.

2.    Pour les tables temporaires, exécutez une requête comme celle-ci :

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;

Il est recommandé de contrôler de près votre application et de voir quelles transactions créent des tables temporaires. Ce faisant, vous pouvez gérer l'utilisation de la capacité de stockage locale disponible. Vous pouvez également passer à une classe d'instance supérieure pour votre instance Aurora, afin qu'elle dispose de plus d'espace de stockage local.

Stockage local utilisé par des fichiers journaux

En cas de journalisation excessive, votre instance de base de données peut aussi manquer d'espace de stockage local. Voici quelques exemples de paramètres de journalisation pouvant consommer l'espace de stockage local. La consommation peut être due à une journalisation excessive ou à la conservation du journal des erreurs pendant une longue période.

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

Pour identifier quel paramètre provoque une journalisation excessive, analysez les journaux PostgreSQL pour trouver les journaux les plus volumineux. Ensuite, identifiez le paramètre responsable de la majorité des entrées dans ces journaux. Vous pourrez alors modifier le paramètre à l'origine de la journalisation excessive.

Si vous exécutez à plusieurs reprises une requête qui échoue avec une erreur, PostgreSQL enregistre les erreurs dans le journal des erreurs PostgreSQL par défaut. Consultez les erreurs consignées, puis corrigez la requête défaillante pour empêcher les journaux d'utiliser trop d'espace de stockage. Vous pouvez également réduire la valeur par défaut pour rds.log_retention (trois jours) afin de récupérer de l'espace utilisé par le journal des erreurs.

Si une journalisation excessive est requise et que vous restreignez l'espace de stockage local disponible en raison des fichiers journaux, envisagez de passer à une classe d'instance supérieure. Cela signifie que votre instance de base de données Aurora dispose d'une plus grande capacité de stockage local.

---

Informations connexes

Best practices with Amazon Aurora PostgreSQL