So verhindern Sie, dass ein Datenbank-Container nach der Datenbereinigung weiter wächst

Ein Datenbank-Container kann nach der Datenbereinigung weiter wachsen, da gelöschte Zeilen, Transaktionsprotokolle, Indizes und Container-Protokolle unterschiedlichen Regeln zur Speicherfreigabe unterliegen.

Gehen Sie nicht davon aus, dass das Datenbank-Volume wächst, nur weil der gesamte Speicherbedarf des Containers zunimmt. Messen Sie das Datenbankdatenverzeichnis, die WAL- oder Binlog-Verzeichnisse, die Docker-Protokolldatei, die beschreibbare Ebene sowie Sicherungs- und temporäre Pfade separat. Ermitteln Sie anschließend, ob gelöschter Datenbankspeicher intern wiederverwendbar ist, aber nicht an den Host zurückgegeben wird, ob tatsächlich eine Neuschreibung erforderlich ist oder ob eine vollständig andere Datei weiter wächst.

Ermitteln, welcher Pfad weiter wächst

Notieren Sie vor und nach einem Bereinigungszyklus die Größe des benannten Volumes oder des per Bind-Mount eingebundenen Datenbankverzeichnisses, der beschreibbaren Container-Ebene, des containerbezogenen Protokolls auf dem Host, des Transaktionsprotokollverzeichnisses der Datenbank sowie jedes Dump- oder temporären Verzeichnisses.

Ein Leitfaden zur Fehlerbehebung bei knappem Speicherplatz in PostgreSQL beginnt mit demselben Grundsatz: Finden Sie heraus, wo der Speicherplatz belegt ist, bevor Sie eine Freigabemaßnahme auswählen.

Wenn nur das Docker-Protokoll wächst, ist die Datenbankbereinigung irrelevant. Wenn die Datendatei groß bleibt, aber nach der Bereinigung nicht weiter wächst, verwendet die Engine möglicherweise bereits freigegebene Seiten wieder, obwohl das Host-Dateisystem keine Verkleinerung erkennt.

Wiederverwendbaren Datenbankspeicher von tatsächlich freigegebenem Speicherplatz unterscheiden

Viele transaktionale Datenbanken entfernen Dateiblöcke aus der Mitte einer Tabelle nicht sofort, nachdem Zeilen gelöscht wurden. Stattdessen markieren sie interne Seiten als wiederverwendbar oder geben sie intern frei, sodass spätere Einfügungen diesen Speicher nutzen können, während die zugrunde liegende Datei gleich groß bleibt.

PostgreSQL ist ein anschauliches Beispiel: Das normale VACUUM macht Speicher intern wiederverwendbar, gibt diese mittleren Dateibereiche jedoch normalerweise nicht an das Betriebssystem zurück.

Beobachten Sie, ob die Datei nach der Bereinigung bei neuen Einfügungen weiter wächst. Eine stabile Dateigröße bei abnehmender interner Fragmentierung unterscheidet sich von unkontrolliertem Wachstum und rechtfertigt normalerweise keine dringende Neuschreibung.

Verwenden Sie die Freigabemethode der Datenbank-Engine, nicht eine allgemeine Docker-Bereinigung

Wenn Speicherplatz an den Host zurückgegeben werden soll, bestimmen Sie zuerst die Engine und das Speicherformat. PostgreSQL, MySQL oder MariaDB und SQLite verwenden keine austauschbaren Verkleinerungsbefehle, und manche Freigabevorgänge schreiben große Dateien neu oder sperren Tabellen.

Ein Artikel zum MySQL-Speicher erklärt, wie OPTIMIZE InnoDB-Tabellen neu aufbauen kann, anstatt ein DELETE als Beweis dafür zu betrachten, dass der Host sofort wieder Speicherplatz erhalten sollte.

Sichern Sie die Datenbank und prüfen Sie, ob ausreichend freier Arbeitsbereich vorhanden ist, bevor Sie einen Vorgang starten, der umfangreiche Neuschreibungen erfordert. Ein nahezu volles Dateisystem auf einem Home-Server ist der schlechteste Zeitpunkt, um einen Befehl auszuführen, der eine zweite Kopie einer großen Tabelle benötigt.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

WAL, Binlogs und Replikationsaufbewahrung separat prüfen

Transaktionsprotokolle können weiter wachsen, selbst nachdem alte Anwendungszeilen gelöscht wurden. Ein fehlgeschlagener Archivierungsjob, ein veralteter Replikationsslot, eine verzögerte Replikation, eine lange Transaktion oder eine Anforderung zur Aufbewahrung von Sicherungen kann dazu führen, dass historische Protokollsegmente auf der Festplatte verbleiben.

Eine aktuelle PostgreSQL-Notiz zur Wiederherstellung zeigt, wie die WAL-Aufbewahrung unabhängig von den Tabellendaten Speicherplatz belegen kann, die ein Benutzer gerade bereinigt hat.

Löschen Sie WAL- oder Binlog-Dateien nicht manuell aus dem Dateisystem. Beheben Sie die Ursache der Aufbewahrung über die Datenbank-Engine und prüfen Sie anschließend, ob die normale Wiederverwendung wieder einsetzt.

Docker-Protokolle begrenzen und die beschreibbare Ebene prüfen

Ein Datenbank-Container kann scheinbar wachsen, weil stdout oder stderr in ein unbegrenzt wachsendes Docker-Protokoll geschrieben wird oder weil ein temporärer Export, ein Cache oder eine Datenbankdatei in die Container-Ebene statt in das vorgesehene persistente Volume geschrieben wurde.

Ein Fall aus dem selbst gehosteten Docker-Betrieb weist darauf hin, dass Containerprotokolle unbegrenzt wachsen können, wenn keine Rotation eingerichtet ist.

Ordnen Sie jede große Datei auf dem Host zunächst ihrem Containerpfad zu, bevor Sie etwas löschen. Konfigurieren Sie die Protokollrotation für zukünftiges Wachstum und verschieben Sie den Datenbankstatus in ein explizites Volume, anstatt sich auf die flüchtige beschreibbare Ebene zu verlassen.

Überprüfen, ob die Bereinigung dauerhaft freien Speicher schafft

Führen Sie nach dem gewählten Freigabeschritt die normale Schreiblast über einen repräsentativen Zeitraum aus und vergleichen Sie den freien Speicherplatz auf dem Host, die Größe der Datenbankdateien, die Größe der Transaktionsprotokolle, die Docker-Protokolle sowie interne Kennzahlen zu freiem Speicher oder Fragmentierung.

Ein Leitfaden zur Reduzierung des PostgreSQL-Speicherbedarfs betont, dass eine Verkleinerung gezielte Wartungsmaßnahmen erfordert, anstatt davon auszugehen, dass jedes Löschen die vom Betriebssystem angezeigte Dateigröße sofort reduziert.

Die Korrektur ist abgeschlossen, wenn das erwartete Datenbankwachstum wiederverwendet oder begrenzt wird und der Host nach jedem Bereinigungszyklus keinen unerklärlichen Speicherplatz mehr verliert. Der zugehörige ZimaSpace-Leitfaden zu zuverlässigen Sicherungen von Datenbank-Containern definiert die Möglichkeit zur Wiederherstellung vor jedem Vorgang, der Datenbankdateien neu schreibt.

Häufig gestellte Fragen

Warum werden beim Löschen von Millionen Zeilen manchmal kaum Speicherplatz auf dem Host freigegeben?

Die Engine markiert diese Seiten möglicherweise innerhalb der Datenbankdatei als wiederverwendbar, anstatt die Datei selbst zu kürzen. Dadurch kann zukünftiges Wachstum verhindert werden, ohne dass sich die auf dem Host sichtbare Dateigröße ändert.

Sollte ich jedes Mal eine vollständige Neuschreibung durchführen, wenn der Container groß wird?

Nein. Vorgänge mit umfangreichen Neuschreibungen können Sperren, temporären Speicherplatz und erhebliche I/O-Ressourcen erfordern. Verwenden Sie sie nur, wenn die Rückgabe von Speicherplatz an den Host notwendig ist und die enginespezifischen Risiken verstanden wurden.

Kann Docker Prune ein Datenbank-Volume bereinigen?

Nicht sicher, wenn das Volume weiterhin Teil des persistenten Datenbankstatus ist. Ermitteln Sie vor dem Bereinigen, ob der Speicherplatz zu Protokollen, Images, gestoppten Containern oder aktiven Datenbankdaten gehört.