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

Dernière mise à jour : 30/09/2021

Je souhaite résoudre les problèmes de stockage local dans mes instances d'Édition compatible avec Amazon 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.

Ré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 espace de stockage local Aurora est plein, consultez les messages d'erreur et les étapes de dépannage suivants :

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 peut se produire lorsque le stockage temporaire est épuisé sur l'instance de base de données. Les opérations qui modifient des tables volumineuses, ajoutent des index sur ces dernières ou effectuent des requêtes SELECT importantes à l'aide de clauses JOIN, GROUP BY ou ORDER BY complexes, peuvent donner lieu à ces erreurs.

Vous pouvez utiliser les 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. Vous pouvez utiliser 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 compatibles avec Aurora PostgreSQL consomment l'espace maximal du stockage local, vous pouvez récupérer de l'espace en réduisant la valeur du paramètre rds.log_retention. 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 suivantes 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.

Remarque : si vous utilisez la compatibilité Aurora PostgreSQL ou Amazon RDS for PostgreSQL 10 ou une version ultérieure, vous pouvez contrôler temp_bytes et temp_files à l'aide de Performance Insights. 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 Référence Amazon Aurora PostgreSQL.

2.    Pour les tables temporaires, exécutez une requête similaire à ce qui suit :

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 par défaut dans le journal des erreurs PostgreSQL. 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.

Vous pouvez également augmenter la taille de votre instance de base de données Aurora afin qu'elle dispose de plus de stockage local.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?