Comment empêcher un conteneur de base de données de grossir après le nettoyage des données
Un conteneur de base de données peut continuer à grossir après le nettoyage des données, car les lignes supprimées, les journaux de transactions, les index et les journaux du conteneur suivent des règles différentes de récupération de l’espace.
Ne supposez pas que le volume de la base de données augmente simplement parce que l’empreinte disque totale du conteneur s’accroît. Mesurez séparément le répertoire de données de la base, les répertoires WAL ou binlog, le fichier journal Docker, la couche inscriptible ainsi que les chemins de sauvegarde ou temporaires. Déterminez ensuite si l’espace libéré dans la base est réutilisable en interne sans être rendu à l’hôte, si une réécriture est réellement nécessaire ou si un fichier complètement différent continue de grossir.
Mesurer quel chemin continue de grossir
Notez la taille du volume nommé ou du répertoire de base de données monté par liaison, de la couche inscriptible du conteneur, du journal du conteneur côté hôte, du répertoire des journaux de transactions de la base ainsi que de tout répertoire de sauvegarde ou temporaire, avant et après un cycle de nettoyage.
Un guide de dépannage de l’espace disque PostgreSQL commence par le même principe : trouver où se trouve l’espace avant de choisir une opération de récupération.
Si seul le journal Docker augmente, le nettoyage de la base de données n’y changera rien. Si le fichier de données reste volumineux mais cesse d’augmenter après le nettoyage, le moteur réutilise peut-être déjà les pages libérées, même si le système de fichiers de l’hôte n’observe aucune réduction.
Distinguer l’espace réutilisable dans la base de l’espace rendu au disque
De nombreuses bases de données transactionnelles ne suppriment pas immédiatement les blocs de fichiers situés au milieu d’une table après la suppression de lignes. Elles marquent ou récupèrent les pages internes afin que les insertions ultérieures puissent réutiliser cet espace, tandis que le fichier sous-jacent conserve la même taille.
PostgreSQL en est un exemple clair : VACUUM réutilise l’espace en interne, mais ne rend généralement pas ces zones centrales du fichier au système d’exploitation.
Observez si le fichier continue de grossir lors de nouvelles insertions après le nettoyage. Une taille de fichier stable avec une fragmentation interne en baisse est différente d’une croissance incontrôlée et ne justifie généralement pas une réécriture d’urgence.
Utiliser la méthode de récupération du moteur de base de données, pas un nettoyage Docker générique
Lorsque l’objectif est de rendre de la capacité à l’hôte, commencez par identifier le moteur et le format de stockage. PostgreSQL, MySQL ou MariaDB, et SQLite n’utilisent pas une même commande de réduction interchangeable, et certaines opérations de récupération réécrivent de gros fichiers ou verrouillent les tables.
Un article consacré au stockage MySQL explique comment OPTIMIZE peut reconstruire les tables InnoDB, au lieu de considérer qu’un DELETE prouve que l’hôte devrait immédiatement récupérer les octets correspondants.
Sauvegardez la base de données et vérifiez l’espace de travail disponible avant toute opération nécessitant une réécriture importante. Un système de fichiers de serveur domestique presque plein est le pire moment pour lancer une commande qui nécessite une seconde copie d’une table volumineuse.
Vérifier séparément les WAL, les binlogs et la rétention de la réplication
Les journaux de transactions peuvent grossir même après la suppression d’anciennes lignes applicatives. Une tâche d’archivage échouée, un emplacement de réplication obsolète, un réplica en retard, une transaction longue ou une obligation de conserver des sauvegardes peut maintenir d’anciens segments de journaux sur le disque.
Une note récente sur la récupération PostgreSQL montre comment la rétention des WAL peut consommer de l’espace de stockage indépendamment des données de table qu’un utilisateur vient de nettoyer.
Ne supprimez pas manuellement les fichiers WAL ou binlog du système de fichiers. Corrigez la cause de la rétention via le moteur de base de données, puis vérifiez que la réutilisation normale reprend.
Limiter les journaux Docker et vérifier la couche inscriptible
Un conteneur de base de données peut sembler grossir parce que la sortie standard ou la sortie d’erreur est capturée dans un journal Docker illimité, ou parce qu’une exportation temporaire, un cache ou un fichier de base de données a été écrit dans la couche du conteneur au lieu du volume persistant prévu.
Un cas Docker auto-hébergé signale que les journaux des conteneurs peuvent croître indéfiniment lorsque la rotation n’est pas configurée.
Associez chaque fichier volumineux côté hôte à son chemin dans le conteneur avant de supprimer quoi que ce soit. Configurez la rotation des journaux pour éviter cette croissance à l’avenir et placez les données de la base dans un volume explicite plutôt que de dépendre de la couche inscriptible éphémère.
Vérifier que le nettoyage crée une marge durable
Après l’étape de récupération choisie, exécutez la charge d’écriture normale pendant une période représentative et comparez l’espace libre sur l’hôte, la taille des fichiers de la base, la taille des journaux de transactions, les journaux Docker ainsi que les métriques internes d’espace libre ou de fragmentation.
Un guide de réduction du stockage PostgreSQL souligne que la réduction nécessite une maintenance ciblée, plutôt que de supposer que chaque suppression doit immédiatement réduire la taille du fichier visible par le système d’exploitation.
La correction est terminée lorsque la croissance attendue de la base est réutilisée ou limitée et que l’hôte ne perd plus de capacité inexpliquée après chaque cycle de nettoyage. Le guide ZimaSpace associé sur les sauvegardes cohérentes des conteneurs de bases de données définit le point de restauration avant toute opération qui réécrit les fichiers de la base.
Foire aux questions
Pourquoi la suppression de millions de lignes libère-t-elle parfois presque aucun espace disque sur l’hôte ?
Le moteur peut marquer ces pages comme réutilisables dans le fichier de base de données au lieu de tronquer le fichier lui-même. Cela peut empêcher une croissance future sans modifier la taille du fichier visible sur l’hôte.
Dois-je effectuer une réécriture complète chaque fois que le conteneur devient volumineux ?
Non. Les opérations nécessitant une réécriture importante peuvent exiger des verrous, de l’espace temporaire et beaucoup d’entrées-sorties. Utilisez-les uniquement lorsqu’il est nécessaire de rendre de l’espace à l’hôte et que les risques propres au moteur sont bien compris.
La commande Docker prune peut-elle récupérer l’espace d’un volume de base de données ?
Pas sans risque lorsque le volume fait toujours partie de l’état persistant de la base. Identifiez d’abord si l’espace appartient aux journaux, aux images, aux conteneurs arrêtés ou aux données actives de la base avant d’effectuer un nettoyage.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
