Que contient le stockage d'Amazon Aurora for PostgreSQL et comment puis-je résoudre les problèmes liés au stockage local ?

Dernière mise à jour : 29/06/2020

Que contient le stockage d'Amazon Aurora PostgreSQL ? Comment puis-je résoudre les problèmes liés au stockage local ?

Brève description

Les instances de base de données qui se trouvent dans des clusters Amazon Aurora présentent deux types de stockage :

  • Stockage utilisé pour des données persistantes (stockage de cluster partagé). Pour plus d'informations, consultez la section Contenu du volume de cluster.
  • Stockage utilisé pour des données et des journaux temporaires (stockage local). Tous les fichiers de base de données (par exemple, les journaux d'erreurs, les fichiers temporaires et les tables temporaires) sont stockés dans le stockage local d'instances de base de données. Cela inclut les opérations de tri, les tables de hachage, les opérations de regroupement dont les requêtes ont besoin, le stockage occupé par les journaux d'erreurs, ainsi que les tables temporaires qui se forment.

Chaque instance de base de données Aurora contient une quantité limitée de stockage local, déterminée par la classe d'instance de base de données. En général, la quantité de stockage local correspond à deux fois la quantité de mémoire qui se trouve sur l'instance de base de données.

Résolution

Vous pouvez surveiller 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é de stockage disponible pour chaque instance de base de données pour les journaux et les tables temporaires. Pour plus d'informations, consultez la section Surveillance des métriques d'un cluster de bases de données Amazon Aurora.

Si votre stockage local Aurora est plein, reportez-vous aux messages d'erreur et aux étapes de résolution ci-dessous :

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 Aurora PostgreSQL. Ce paramètre consigne l'utilisation de fichiers temporaires qui dépassent le nombre spécifié de kilo-octets. Lorsqu'il est activé, une entrée de journal est réalisée pour chaque fichier temporaire lorsque le fichier est supprimé. La valeur 0 consigne toutes les informations du fichier temporaire, tandis qu'une valeur positive consigne uniquement les fichiers dont le nombre de kilo-octets est égal ou supérieur au nombre indiqué. 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 du fichier temporaire, puis mettre ces fichiers temporaires en relation avec 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 Aurora PostgreSQL. Pour cette raison, il est recommandé de vérifier la taille des fichiers journaux Aurora PostgreSQL avant d'activer log_temp_files. Si les fichiers journaux Aurora PostgreSQL utilisent l'espace de stockage local maximal, 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 recueillent 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 relative aux Fonctions statistiques supplémentaires.

Remarque : si vous utilisez Aurora PostgreSQL ou Amazon RDS for PostgreSQL 10 ou 11, vous pouvez surveiller temp_bytes et temp_files à l'aide de l'analyse des performances. L'analyse des performances fournit des compteurs natifs pour les métriques internes de votre moteur de base de données, en plus des événements d'attente. Pour plus d'informations, consultez la section Compteurs natifs pour Amazon RDS PostgreSQL.

Vous pouvez également augmenter la valeur des paramètres 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 relative à maintenance_work_mem et work_mem. 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 pour éviter de manquer de mémoire. Pour plus d'informations, consultez la section relative à 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 surveiller étroitement votre application pour voir quelles transactions créent des tables temporaires et pouvoir ainsi gérer l'utilisation de la capacité de stockage local disponible. Vous pouvez également passer à une classe d'instance supérieure pour votre instance Aurora, afin qu'elle dispose de plus 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 de stockage local. Les paramètres de journalisation suivants peuvent entraîner une journalisation excessive :

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 les paramètres à l'origine de la journalisation excessive, analysez les journaux PostgreSQL afin de repérer 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 de façon répétée une requête qui échoue en affichant une erreur, PostgreSQL consigne par défaut les erreurs 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 de stockage. Vous pouvez également réduire la valeur par défaut de 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 ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?