Datenbank löschen gibt keinen Plattenpeicher frei?

S

siradlib

New Member
Hallo zusammen,

ich habe unter Plesk Panel 9.5 eine 1 GB große Datenbank angelegt, etwas damit gearbeitet und die Datenbank anschließend wieder gelöscht.
Ich hätte nach dem Löschen erwartet, dass 1 GB Plattenplatz wieder freigegeben werden (Anzeige mit "df" an der Shell), zumindest nach einger Zeit, wenn MySQL die Änderungen durchgeführt hat.
Die Platte ist aber auch nach dem Löschen der DB noch genauso voll/leer wie vorher.
Wobei ich vor dem Anlegen der DB nicht auf den "Füllstand" der Festplatte geachtet habe sondern leider nur unmittelbar vor und nach dem Löschen der DB. :mad:

Kann mir jemand diesen Zusammenhang erläutern?
Es kann sich hierbei natürlich auch um eine Eigenheit nur von MySQL und nicht von Plesk handeln, habe das noch nicht ausprobiert...

LG siradlib
 
Du liegst mit deiner Vermutung richtig. Mysql gibt den Platz nicht wieder her. Dir bleibt einzig die Möglichkeit, die DB zu dumpen (in SQL Statements) alle db files zu löschen und anschließend wieder zu importieren. Dann wird Mysql genauso große Dateien anlegen wie es für deine derzeitigen Daten benötigt.

Gruss
 
Joe User said:
Die Aussage ist schlicht falsch, zumindest solange keine InnoDB-Engine zum Zug kommt.
Click to expand...

Dankeschön an euch beide, bin ich also doch nicht bekloppt. :rolleyes:
Heißt das: InnoDB zeigt dieses Verhalten, aber die anderen (Standard-) Datenbankengines nicht?
Was ist eigentlich der Sinn hinter diesem Nichtwiederfreigeben des Speichers?

Der Thread darf übrigens gern in den Datenbank-Bereich der SSF verschoben werden.
 
Last edited by a moderator:
Joe, Danke für den Link auf die Dokumentation.

Für mich liest sich das aber so, als ob ich mein Problem (="Datenbank braucht mehr Platz auf der Platte als die eigentlichen Daten benötigen würden") nur dann auftritt, wenn ich z.B. mit DROP TABLE Tabellen lösche- und dann nur innerhalb des Tablespace der Datenbank.
Bei einem DROP DATABASE fänd ich das Vorhalten des Tablespace aber unnütz.

Ich würde also davon ausgehen, dass spätestens beim Löschen der Datenbank der Platz wieder freigegeben wird. Dies scheint* zumindest beim Nutzen von InnoDB als Engine nicht so zu sein.
Ist das wirklich so?

Oder habe ich etwas/den Begriff "Tablespace" falsch verstanden?


* bin nicht ganz sicher, weitere Tests nötig
 
Der oder die Tablespaces werden systemweit verwendet und sind keiner Datenbank direkt zugeteilt. Der Platz ist also für alle da und wird dementsprechend auch nicht freigegeben, wenn nur eine einzelne Datenbank gelöscht wird.

Es gibt eine Option innodb_file_per_table, womit statt eines Tablespaces für alle Tabellen wieder eine Datei pro Tabelle verwendet wird. Damit wird der Platz auch wieder freigegeben, wenn die Tabelle gelöscht wird.
 
So, ich kann es nun bestätigen: Bei Nutzung von "InnoDB" als Storage-Engine gibt "DROP DATABASE" keinen Speicherplatz frei! :eek:

Cenic said:
Es gibt eine Option innodb_file_per_table, womit statt eines Tablespaces für alle Tabellen wieder eine Datei pro Tabelle verwendet wird. Damit wird der Platz auch wieder freigegeben, wenn die Tabelle gelöscht wird.
Click to expand...

Danke für den Tipp!
(Wird der Platz bei aktivierter Option eigentlich automatisch wieder freigegeben, oder muss man dann von Hand aufräumen?)

Das hätte man vor dem Starten der Projekte wissen sollen- mir ist diese unschöne Eigenschaft von InnoDB jedenfalls vorher so nicht bekannt gewesen. :rolleyes:
Es gibt allerdings ein Howto, welches die Schritte für Umstellung der MySQL-Datenbank ohne Downtime auf "innodb_file_per_table" zeigt.

Kann mir jemand bei Gelegenheit kurz erklären, warum man dort mit Replikation und drei MySQL-Instanzen arbeitet? Ich habe die Funktionsweise der Geschichte noch nicht verstanden.
 
Last edited by a moderator:
siradlib said:
(Wird der Platz bei aktivierter Option eigentlich automatisch wieder freigegeben, oder muss man dann von Hand aufräumen?)
Click to expand...

Ja, die entsprechende Datei verschwindet beim DROP TABLE.

siradlib said:
Kann mir jemand bei Gelegenheit kurz erklären, warum man dort mit Replikation und drei MySQL-Instanzen arbeitet? Ich habe die Funktionsweise der Geschichte noch nicht verstanden.
Click to expand...

Der Aufwand wird getrieben, um von der laufenden Instanz eine Kopie zu machen, die dann anschließend automatisch auch die parallel anfallenden Änderungen übernimmt. Das normale Backup erzeugt ein Abbild von einem bestimmten Zeitpunkt. Wenn die Datenbanken weiter benutzt werden, kommen aber laufend Änderungen hinzu. Die Replikation wird genutzt, um diese Änderungen dann auf die parallel laufende Instanz zu bringen, wo der Parameter gesetzt wurde. Dann kann später augenblicklich von der alten auf die neue Instanz umgeschaltet werden und diese beinhaltet dann auch die aktuellsten Daten.
 
Das Grundprinzip hatte ich mir schon so gedacht. Aber kannst Du mir die einzelnen Punkte nochmal erklären, also wann welche DB zum Slave/Master von welcher gemacht wird?
 
Die erste Instanz ist logischerweise der Master. Das Aufsetzen der Replikation erfordert laut Handbuch ein Unterbinden aller Schreibanweisungen, um einen konsistenten Datenbestand auf den Slave zu ziehen. Die Rahmenbedingung hier war jedoch, dass man mit der Masterinstanz normal weiterarbeiten kann.

Da kommt die zweite Instanz ins Spiel. Sie dient dazu, mittels des Programmes Xtrabackup einen konsistenten Stand der laufenden Instanz zu erzeugen. Dazu wird ein Backup ohne Locks auf den Tabellen erstellt. Während das Backup läuft, werden die Änderungen von MySQL ins Binlog geschrieben. Das nutzt dann das Backupprogramm, um anschließend die während des Backups durchgeführten Änderungen auch ins Backup zu schreiben. Zum Schluß gibt das Backup-Programm noch die Transaktions-ID aus, bis zu der das Backup dann konsistent ist.

Mit dem so erstellten Backup kann nun die dritte Instanz erstellt werden. Da die Transaktions-ID bekannt ist, kann nun die dritte Instanz als Slave an die erste Instanz gekoppelt werden. Ab dem Moment übernimmt die Replikation das Nachfahren der Änderungen aus der ersten Instanz.

Sobald da kein zeitlicher Versatz mehr ist, kann die Applikation von der ersten auf die dritte Instanz geschwenkt werden und dort mit dem dann ja aktuellen Bestand weiterarbeiten.
 
You must log in or register to reply here.
Back
Top