Come impedire che un container di database aumenti di dimensioni dopo la pulizia dei dati
Un container di database può continuare a crescere dopo la pulizia dei dati perché righe eliminate, log delle transazioni, indici e log del container seguono regole diverse per il recupero dello spazio.
Non dare per scontato che il volume del database stia crescendo solo perché aumenta l’impronta totale del container sul disco. Misura separatamente la directory dei dati del database, le directory WAL o binlog, il file di log Docker, il livello scrivibile e i percorsi di backup o temporanei. Determina poi se lo spazio eliminato dal database è riutilizzabile internamente ma non viene restituito all’host, se è effettivamente necessaria una riscrittura o se sta ancora crescendo un file completamente diverso.
Misura quale percorso continua a crescere
Registra le dimensioni del volume denominato o della directory del database montata tramite bind mount, del livello scrivibile del container, del log del container sul lato host, della directory dei log delle transazioni del database e di eventuali directory di dump o temporanee, prima e dopo un ciclo di pulizia.
Una guida alla risoluzione dei problemi relativi allo spazio su disco di PostgreSQL parte dallo stesso principio: individua dove viene utilizzato lo spazio prima di scegliere un’operazione di recupero.
Se cresce solo il log Docker, la pulizia del database è irrilevante. Se il file dei dati rimane grande ma smette di aumentare dopo la pulizia, il motore potrebbe già riutilizzare le pagine liberate, anche se il file system dell’host non mostra alcuna riduzione.
Distingui lo spazio riutilizzabile del database dallo spazio restituito al disco
Molti database transazionali non rimuovono immediatamente i blocchi al centro di una tabella dopo l’eliminazione delle righe. Contrassegnano o recuperano le pagine interne affinché gli inserimenti successivi possano riutilizzare quello spazio, mentre il file sottostante mantiene le stesse dimensioni.
PostgreSQL ne è un esempio chiaro: il normale comando VACUUM riutilizza lo spazio internamente, ma di solito non restituisce al sistema operativo quelle porzioni intermedie del file.
Controlla se il file continua a crescere durante i nuovi inserimenti dopo la pulizia. Una dimensione stabile del file con una riduzione della frammentazione interna è diversa da una crescita incontrollata e, di norma, non giustifica una riscrittura d’emergenza.
Usa il metodo di recupero del motore del database, non una pulizia Docker generica
Quando l’obiettivo è restituire capacità all’host, identifica prima il motore e il formato di archiviazione. PostgreSQL, MySQL o MariaDB e SQLite non utilizzano un unico comando intercambiabile per ridurre le dimensioni, e alcune operazioni di recupero riscrivono file di grandi dimensioni o bloccano le tabelle.
Un articolo sull’archiviazione MySQL spiega come OPTIMIZE possa ricostruire le tabelle InnoDB, invece di considerare un comando DELETE come prova che l’host debba recuperare immediatamente quei byte.
Esegui il backup del database e verifica la disponibilità di spazio di lavoro prima di qualsiasi operazione che comporti una riscrittura. Un file system di un home server quasi pieno è il momento peggiore per avviare un comando che richiede una seconda copia di una tabella di grandi dimensioni.
Controlla separatamente WAL, binlog e conservazione della replica
I log delle transazioni possono crescere anche dopo l’eliminazione delle vecchie righe dell’applicazione. Un processo di archiviazione non riuscito, uno slot di replica obsoleto, una replica in ritardo, una transazione lunga o un requisito di conservazione dei backup possono mantenere sul disco segmenti di log storici.
Una recente nota sul ripristino di PostgreSQL mostra come la conservazione del WAL possa consumare spazio di archiviazione indipendentemente dai dati delle tabelle che un utente ha appena ripulito.
Non eliminare manualmente i file WAL o binlog dal file system. Risolvi la causa della conservazione tramite il motore del database, quindi verifica che il normale riciclo riprenda.
Limita i log Docker e controlla il livello scrivibile
Un container di database può sembrare crescere perché stdout o stderr viene acquisito in un log Docker senza limiti, oppure perché un’esportazione temporanea, una cache o un file del database è stato scritto nel livello del container invece che nel volume persistente previsto.
Un caso relativo a Docker in ambiente self-hosted segnala che i log dei container possono crescere indefinitamente quando la rotazione non è configurata.
Ricollega ogni file di grandi dimensioni sull’host al relativo percorso nel container prima di eliminare qualsiasi elemento. Configura la rotazione dei log per prevenire la crescita futura e sposta lo stato del database in un volume esplicito invece di affidarti al livello scrivibile ed effimero.
Verifica che la pulizia crei un margine di sicurezza sostenibile
Dopo il passaggio di recupero scelto, esegui il normale carico di scrittura per un periodo rappresentativo e confronta lo spazio libero sull’host, le dimensioni dei file del database, le dimensioni dei log delle transazioni, i log Docker e le metriche interne relative allo spazio libero o alla frammentazione.
Una guida alla riduzione dello spazio di archiviazione di PostgreSQL sottolinea che la riduzione richiede una manutenzione mirata, invece di presumere che ogni eliminazione debba ridurre immediatamente le dimensioni del file nel sistema operativo.
La correzione è completa quando la crescita prevista del database viene riutilizzata o limitata e l’host non perde più capacità inspiegabilmente dopo ogni ciclo di pulizia. La guida ZimaSpace correlata ai backup coerenti dei container di database definisce il punto di ripristino prima di qualsiasi operazione che riscriva i file del database.
Domande frequenti
Perché l’eliminazione di milioni di righe a volte libera pochissimo spazio sul disco dell’host?
Il motore potrebbe contrassegnare quelle pagine come riutilizzabili all’interno del file del database invece di troncare il file stesso. Questo può impedire una crescita futura senza modificare le dimensioni del file visibili sull’host.
Devo eseguire una riscrittura completa ogni volta che il container diventa grande?
No. Le operazioni che comportano una riscrittura possono richiedere blocchi, spazio temporaneo e una notevole quantità di I/O. Usale solo quando è necessario restituire spazio all’host e hai compreso i rischi specifici del motore.
Docker prune può recuperare lo spazio di un volume del database?
Non in modo sicuro quando il volume fa ancora parte dello stato persistente del database. Prima di eseguire il pruning, identifica se lo spazio appartiene ai log, alle immagini, ai container arrestati o ai dati attivi del database.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
