Een databasecontainer laten stoppen met groeien na het opschonen van gegevens

Een databasecontainer kan blijven groeien nadat gegevens zijn opgeschoond, omdat verwijderde rijen, transactielogboeken, indexen en containerlogboeken verschillende regels voor het vrijgeven van schijfruimte volgen.

Ga er niet van uit dat het databasevolume groeit alleen omdat de totale schijfruimte van de container toeneemt. Meet de datamap van de database, de mappen met WAL- of binlogbestanden, het Docker-logbestand, de beschrijfbare laag en back-up- of tijdelijke paden afzonderlijk. Bepaal vervolgens of verwijderde databaseruimte intern opnieuw kan worden gebruikt maar niet aan de host wordt teruggegeven, of dat een herschrijving echt nodig is, of dat er nog een volledig ander bestand groeit.

Bepaal welk pad nog groeit

Noteer vóór en na één opschooncyclus de grootte van het benoemde volume of de aan de database gekoppelde map, de beschrijfbare containerlaag, het containerlogboek aan de hostzijde, de map met transactielogboeken van de database en eventuele dump- of tijdelijke mappen.

Een handleiding voor het oplossen van problemen met schijfruimte in PostgreSQL begint met hetzelfde principe: zoek uit waar de ruimte zit voordat je een methode voor het vrijmaken van ruimte kiest.

Als alleen het Docker-logboek groeit, heeft het opschonen van de database geen effect. Als het databestand groot blijft maar na het opschonen niet verder groeit, gebruikt de database-engine vrijgemaakte pagina’s mogelijk al opnieuw, ook al ziet het bestandssysteem van de host geen verkleining.

Maak onderscheid tussen herbruikbare databas ruimte en vrijgegeven schijfruimte

Veel transactionele databases verwijderen bestandsblokken in het midden van een tabel niet direct nadat rijen zijn verwijderd. Ze markeren interne pagina’s als herbruikbaar, zodat latere invoegingen die ruimte opnieuw kunnen gebruiken terwijl het onderliggende bestand even groot blijft.

PostgreSQL is een duidelijk voorbeeld: gewone VACUUM maakt ruimte intern opnieuw bruikbaar, maar geeft die middelste bestandsgebieden meestal niet terug aan het besturingssysteem.

Let erop of het bestand tijdens nieuwe invoegingen na het opschonen blijft groeien. Een stabiele bestandsgrootte met afnemende interne fragmentatie verschilt van onbeheersbare groei en rechtvaardigt meestal geen noodgedwongen herschrijving.

Gebruik de vrijgavemethode van de database-engine, niet een algemene Docker-opruiming

Als het doel is om capaciteit aan de host terug te geven, bepaal dan eerst de engine en het opslagformaat. PostgreSQL, MySQL of MariaDB en SQLite gebruiken geen uitwisselbaar commando om te verkleinen, en sommige vrijgavebewerkingen herschrijven grote bestanden of vergrendelen tabellen.

Een artikel over MySQL-opslag legt uit hoe OPTIMIZE InnoDB-tabellen kan reconstrueren, in plaats van een DELETE te beschouwen als bewijs dat de host onmiddellijk bytes zou moeten terugkrijgen.

Maak een back-up van de database en controleer of er voldoende vrije werkruimte is voordat je een bewerking uitvoert die grote bestanden herschrijft. Een bijna vol bestandssysteem op een homeserver is het slechtste moment om een opdracht te starten die een tweede kopie van een grote tabel nodig heeft.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer WAL, binlogs en replicatiebewaring afzonderlijk

Transactielogboeken kunnen groeien, zelfs nadat oude applicatierijen zijn verwijderd. Een mislukte archiveringstaak, een verouderde replicatieslot, een achterlopende replica, een lange transactie of een vereiste voor het bewaren van back-ups kan ervoor zorgen dat historische logsegmenten op schijf blijven staan.

Een recente notitie over PostgreSQL-herstel laat zien hoe WAL-bewaring opslagruimte kan verbruiken, onafhankelijk van de tabelgegevens die een gebruiker zojuist heeft opgeschoond.

Verwijder WAL- of binlogbestanden niet handmatig uit het bestandssysteem. Los de oorzaak van de bewaring op via de database-engine en controleer vervolgens of het normaal hergebruiken weer doorgaat.

Beperk Docker-logboeken en controleer de beschrijfbare laag

Het kan lijken alsof een databasecontainer groeit doordat stdout of stderr wordt vastgelegd in een onbeperkt Docker-logboek, of doordat een tijdelijke export, cache of databasebestand in de containerlaag is opgeslagen in plaats van in het bedoelde permanente volume.

Een praktijkvoorbeeld met zelfgehoste Docker laat zien dat containerlogboeken onbeperkt kunnen groeien wanneer logrotatie niet is geconfigureerd.

Koppel elk groot bestand op de host aan het bijbehorende containerpad voordat je iets verwijdert. Configureer logrotatie om toekomstige groei te beperken en sla de databasestatus op in een expliciet volume in plaats van te vertrouwen op de tijdelijke beschrijfbare laag.

Controleer of het opschonen blijvende ademruimte oplevert

Voer na de gekozen vrijgavestap de normale schrijfbelasting gedurende een representatieve periode uit en vergelijk de vrije ruimte op de host, de grootte van databasebestanden, de grootte van transactielogboeken, Docker-logboeken en interne statistieken voor vrije ruimte of fragmentatie.

Een handleiding voor het verkleinen van PostgreSQL-opslag benadrukt dat verkleinen gericht onderhoud vereist, in plaats van ervan uit te gaan dat elke verwijdering de bestandsgrootte van het besturingssysteem onmiddellijk verkleint.

De oplossing is voltooid wanneer verwachte databasegroei opnieuw wordt benut of begrensd en de host na elke opschooncyclus geen onverklaarde capaciteit meer verliest. De gerelateerde ZimaSpace-handleiding over consistente back-ups van databasecontainers biedt een herstelpunt voordat een bewerking wordt uitgevoerd die databasebestanden herschrijft.

Veelgestelde vragen

Waarom levert het verwijderen van miljoenen rijen soms vrijwel geen vrije schijfruimte op de host op?

De engine kan die pagina’s binnen het databasebestand als herbruikbaar markeren in plaats van het bestand zelf in te korten. Daardoor kan toekomstige groei worden voorkomen zonder dat de bestandsgrootte op de host verandert.

Moet ik elke keer een volledige herschrijving uitvoeren wanneer de container groot wordt?

Nee. Bewerkingen die bestanden volledig herschrijven kunnen vergrendelingen, tijdelijke ruimte en aanzienlijke I/O vereisen. Gebruik ze alleen wanneer het nodig is om ruimte aan de host terug te geven en je de specifieke risico’s van de engine begrijpt.

Kan Docker prune een databasevolume opruimen?

Niet veilig wanneer het volume nog deel uitmaakt van de permanente databasestatus. Bepaal eerst of de ruimte afkomstig is van logboeken, images, gestopte containers of actieve databasegegevens voordat je opruimt.