Comment résoudre les problèmes de stockage local dans mes instances de base de données Aurora compatible avec PostgreSQL ?

Brève description

Il existe deux types de stockage pour Amazon Aurora : stockage pour les données persistantes, telles que le volume de cluster partagé et stockage local pour chaque instance de base de données.

La taille de stockage local est liée à la classe d'instance. Vous ne pouvez modifier la taille de stockage que si vous passez à une classe d'instance de base de données de plus grande taille. Pour stocker les journaux d'erreurs et les fichiers temporaires, Aurora compatible avec PostgreSQL utilise le stockage local. Pour les instances autres que celles de la classe T, le système écrit les journaux sur un volume dédié que le système nettoie automatiquement.

Pour surveiller l'espace de stockage local associé à l'instance ou au nœud de base de données Aurora, utilisez la métrique Amazon CloudWatch FreeLocalStorage. Cette métrique indique la quantité de stockage disponible pour les tables temporaires dans chaque instance de base de données.

Résolution

Il ne reste plus d'espace de stockage local

Le message d’erreur « could not write block ###### of temporary file: No space left on device » s’affiche lorsqu'il ne reste plus d'espace de stockage temporaire. Cette erreur peut survenir pour les opérations suivantes :

• Modifier les tables volumineuses
• Ajouter des index sur des tables volumineuses
• Exécutez de grandes requêtes SELECT avec des clauses JOIN, GROUP BY ou ORDER BY complexes.

Vérifier la taille du fichier temporaire

Pour identifier les détails du fichier temporaire, activez le paramètre log_temp_files dans l'instance de base de données Aurora compatible avec PostgreSQL. Puis, comparez les fichiers temporaires à la métrique FreeLocalStorage.

Le paramètre log_temp_files journalise chaque fichier temporaire dont la taille est supérieure au nombre de kilo-octets spécifié. La valeur 0 journalise toutes les informations relatives aux fichiers temporaires. Une valeur positive journalise uniquement les fichiers dont la taille est supérieure ou égale au nombre de kilo-octets spécifié. La valeur par défaut est -1, ce qui désactive la journalisation des fichiers temporaires. Lorsque vous activez le paramètre log_temp_files, cela peut entraîner une journalisation excessive sur l'instance de base de données Aurora compatible avec PostgreSQL.

Il est recommandé de vérifier la taille des fichiers journaux Aurora compatible avec PostgreSQL avant d'activer log_temp_files. Si les fichiers journaux consomment l'espace maximum de 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 3 jours.

Pour vérifier la taille du fichier temporaire, exécutez plusieurs fois la commande suivante :

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

Remarque : Utilisez la sortie qui a changé après les exécutions suivantes.

Dans la colonne temp_files, tous les fichiers temporaires sont comptabilisés quelle que soit la date à laquelle vous les avez créés. Les colonnes temp_files et temp_bytes dans la vue pg_stat_database collectent des statistiques pour la valeur cumulée. Pour réinitialiser la valeur, utilisez la fonction pg_stat_reset() ou redémarrez l'instance de base de données. Pour plus d'informations, consultez la page Fonctions statistiques supplémentaires sur le site Web de PostgreSQL.

Si vous utilisez Aurora compatible avec PostgreSQL version 10 ou ultérieure, vous pouvez surveiller temp_bytes and temp_files avec Performance Insights. Performance Insights fournit des compteurs natifs pour les métriques internes de votre moteur de base de données et les événements d'attente. Vous pouvez également activer Performance Insights et utiliser Database Insights pour surveiller les journaux de base de données.

Pour allouer plus de mémoire aux processus qui effectuent l'opération, vous pouvez augmenter les paramètres maintenance_work_mem et work_mem. Cette méthode utilise plus de mémoire pour l'opération et moins de stockage temporaire sur disque. Pour plus d'informations sur ces paramètres, consultez les pages maintenance_work_mem et work_mem sur le site Web de PostgreSQL.

Il est recommandé de définir les valeurs de maintenance_work_mem et work_mem au niveau d'une requête ou d'une session. Dans ce cas, vos instances de base de données ne manquent pas de mémoire. Pour plus d'informations, consultez la référence Amazon Aurora PostgreSQL.

Vérifier la taille de la table temporaire

Exécutez la requête suivante :

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 surveiller de près votre application et de voir les transactions qui créent des tables temporaires. Vous pouvez ensuite gérer l'utilisation de la capacité de stockage locale disponible. Vous pouvez également modifier la classe d'instance de votre instance de base de données Aurora afin que celle-ci dispose d'un espace de stockage local plus important.

Fichiers journaux (applicables uniquement aux types de classes d'instance aux performances instables) qui utilisent le stockage local

Une journalisation excessive peut entraîner l'épuisement de l'espace de stockage local de votre instance de base de données pour les types de classes d'instance à capacité extensible uniquement, tels que db.t2, db.t3 et db.t4g. Des exemples de paramètres de journalisation qui peuvent consommer l'espace de stockage local sont présentés ci-dessous. La consommation peut être due à une journalisation excessive ou à la conservation du journal des erreurs pendant une longue période.

Pour identifier le paramètre à l'origine d’une journalisation excessive, analysez les journaux PostgreSQL pour identifier les journaux les plus volumineux. Puis, identifiez le paramètre responsable de la majorité des entrées de ces journaux. Vous pouvez ensuite modifier le paramètre à l'origine d’une journalisation excessive.

Exemple de sortie :

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 vous exécutez à plusieurs reprises une requête qui échoue avec une erreur, PostgreSQL consigne les erreurs dans le journal des erreurs de PostgreSQL par défaut. Pour éviter que les journaux d'erreurs n'utilisent un espace de stockage excessif, examinez les erreurs qu'ils contiennent, puis corrigez la requête qui a échoué. Vous pouvez également réduire la valeur par défaut de 3 jours pour rds.log_retention afin de récupérer l'espace utilisé par les journaux des erreurs.

Il est recommandé de remplacer votre classe d'instance par une classe d'instance de plus grande taille afin d'éviter une journalisation excessive. De cette façon, votre instance de base de données Aurora dispose d'un espace de stockage local plus important.

Informations connexes

Bonnes pratiques relatives à Amazon Aurora PostgreSQL