Så stoppar du en databaskontainer från att växa efter datarensning

En databaskontainer kan fortsätta växa efter att data har rensats eftersom borttagna rader, transaktionsloggar, index och containerloggar följer olika regler för frigörande av utrymme.

Anta inte att databasvolymen växer bara för att containerns totala diskutrymme ökar. Mät databassökvägen för data, WAL- eller binloggkataloger, Docker-loggfilen, det skrivbara lagret samt säkerhetskopierings- och temporära sökvägar separat. Fastställ sedan om borttaget databasutrymme kan återanvändas internt men inte återföras till värden, om en omskrivning faktiskt krävs eller om en helt annan fil fortfarande växer.

Mät vilken sökväg som fortfarande växer

Notera storleken på den namngivna volymen eller den bindmonterade databaskatalogen, containerns skrivbara lager, värdens containerlogg, databasmappens transaktionsloggar samt eventuella dump- eller temporära kataloger före och efter en rensningscykel.

En guide för felsökning av diskutrymme i PostgreSQL börjar med samma princip: ta reda på var utrymmet finns innan du väljer en åtgärd för att frigöra det.

Om endast Docker-loggen växer är databasrensning irrelevant. Om datafilen förblir stor men slutar öka efter rensningen kan motorn redan återanvända frigjorda sidor, även om värdens filsystem inte visar någon minskning.

Skilj mellan återanvändbart databasutrymme och återlämnat diskutrymme

Många transaktionsdatabaser tar inte omedelbart bort filblock från mitten av en tabell när rader har raderats. I stället markeras eller återvinns interna sidor så att senare infogningar kan återanvända utrymmet, medan den underliggande filen behåller samma storlek.

PostgreSQL är ett tydligt exempel: vanlig VACUUM återanvänder utrymme internt men återlämnar vanligtvis inte dessa områden i mitten av filen till operativsystemet.

Kontrollera om filen fortsätter att växa när nya infogningar görs efter rensningen. En stabil filstorlek med minskande intern bloat skiljer sig från okontrollerad tillväxt och motiverar vanligtvis inte en akut omskrivning.

Använd databasmotorns metod för att frigöra utrymme, inte en generell Docker-rensning

När målet är att återföra kapacitet till värden ska du först identifiera motorn och lagringsformatet. PostgreSQL, MySQL eller MariaDB och SQLite använder inte ett gemensamt krympkommando, och vissa åtgärder för att frigöra utrymme skriver om stora filer eller låser tabeller.

En artikel om MySQL-lagring förklarar hur OPTIMIZE kan bygga om InnoDB-tabeller, i stället för att behandla en DELETE som ett bevis på att värden omedelbart ska få tillbaka byte.

Säkerhetskopiera databasen och bekräfta att det finns tillräckligt med ledigt arbetsutrymme före alla omskrivningsintensiva åtgärder. Ett nästan fullt filsystem på en hemserver är den sämsta tidpunkten att starta ett kommando som behöver en andra kopia av en stor tabell.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Kontrollera WAL, binloggar och kvarhållning för replikering separat

Transaktionsloggar kan växa även efter att gamla programrader har raderats. Ett misslyckat arkiveringsjobb, en inaktuell replikeringsslot, en eftersläpande replik, en långvarig transaktion eller ett krav på att behålla säkerhetskopior kan göra att historiska loggsegment ligger kvar på disken.

En aktuell återställningsanteckning för PostgreSQL visar hur WAL-kvarhållning kan förbruka lagringsutrymme oberoende av tabelldata som en användare nyss har rensat.

Ta inte bort WAL- eller binloggfiler direkt från filsystemet. Åtgärda orsaken till kvarhållningen via databasmotorn och kontrollera sedan att normal återvinning återupptas.

Begränsa Docker-loggar och kontrollera det skrivbara lagret

En databaskontainer kan verka växa eftersom stdout eller stderr fångas i en obegränsad Docker-logg eller eftersom en temporär export, cache eller databasfil har skrivits till containerlagret i stället för den avsedda permanenta volymen.

Ett självhostat Docker-fall visar att containerloggar kan växa utan gräns när rotation inte har konfigurerats.

Spåra varje stor fil på värden tillbaka till dess containersökväg innan du tar bort något. Konfigurera loggrotation för framtida tillväxt och flytta databastillståndet till en explicit volym i stället för att förlita dig på det temporära skrivbara lagret.

Kontrollera att rensningen skapar hållbart utrymme

Efter den valda åtgärden för att frigöra utrymme ska du köra den normala skrivbelastningen under en representativ period och jämföra ledigt utrymme på värden, databasfilens storlek, transaktionsloggens storlek, Docker-loggarna samt interna mått för ledigt utrymme eller bloat.

En guide för att minska PostgreSQL-databasens storlek betonar att krympning kräver riktat underhåll i stället för att anta att varje radering omedelbart ska minska operativsystemets filstorlek.

Åtgärden är klar när förväntad databastillväxt återanvänds eller begränsas och värden inte längre förlorar oförklarlig kapacitet efter varje rensningscykel. Den relaterade ZimaSpace-guiden om konsekventa säkerhetskopior av databaskontainrar anger återställningsgränsen innan någon åtgärd som skriver om databasfiler utförs.

Vanliga frågor

Varför frigör radering av miljontals rader ibland nästan inget diskutrymme på värden?

Motorn kan markera sidorna som återanvändbara i databasfilen i stället för att kapa själva filen. Det kan förhindra framtida tillväxt utan att ändra den filstorlek som värden ser.

Bör jag göra en fullständig omskrivning varje gång containern blir stor?

Nej. Omskrivningsintensiva åtgärder kan kräva lås, temporärt utrymme och betydande I/O. Använd dem endast när det är nödvändigt att återföra utrymme till värden och när de motorspecifika riskerna är kända.

Kan Docker prune frigöra en databasvolym?

Inte på ett säkert sätt när volymen fortfarande ingår i databasens permanenta tillstånd. Ta reda på om utrymmet tillhör loggar, avbildningar, stoppade containrar eller aktiva databastdata innan du rensar.