var/lib/mysql Verzeichnis zu voll

magnum · 11 März 2012

Hallo,

auf meinem Server ( cloud Server suse 11.3 bei 1&1) wird angezeigt, das das /var mittlerweile 78% der zugeteilten 30GB Partition belegt.
Ich habe schon einiges durchgesehen und bin jetzt auf eine komische Sache gestoßen:

Die Ausgabe von

Code:

du -h /var/lib/mysql

bringt diese seltsamen Größenangaben:

Code:

984K    /var/lib/mysql/mysql
2.4M    /var/lib/mysql/psa
156K    /var/lib/mysql/phpmyadmin_wgm1vF4e0tDm
768K    /var/lib/mysql/sitebuilder5
668K    /var/lib/mysql/horde
172K    /var/lib/mysql/phpmyadmin_y9sX7wDK1S2r
228K    /var/lib/mysql/apsc
176K    /var/lib/mysql/phpmyadmin_5tEmKeXpYxxe
109M    /var/lib/mysql/alptraeume_16
16M     /var/lib/mysql/svm_
4.2M    /var/lib/mysql/livezilla_
676K    /var/lib/mysql/wiki_
540K    /var/lib/mysql/NFruehholz_
89M     /var/lib/mysql/alptraeume_16_entwicklung
2.7M    /var/lib/mysql/entwicklung_
4.3M    /var/lib/mysql/demo_shop_
88M     /var/lib/mysql/alptraeume_17_entwicklung
212M    /var/lib/mysql/alptraeume_17
3.2M    /var/lib/mysql/shoptest_
1.9M    /var/lib/mysql/xtcommerce_d
2.7M    /var/lib/mysql/version_16
2.4M    /var/lib/mysql/veyton_4_
172K    /var/lib/mysql/phpmyadmin_t6jHLAkxAepP
172K    /var/lib/mysql/phpmyadmin_WWSaeSH2W468
176K    /var/lib/mysql/phpmyadmin_EOXxtQLysv2v
19G     /var/lib/mysql

Das lese ich so, dass /var/lib/mysql 19GB belegt, die Summe der einzelnen Verzeichnisse davon aber meilenweit weg ist.
Wie kann denn sowas sein und wie finde ich die großen Dateien?
Die Differenz würde mein Problem schon locker lösen...

Gruß

Magnus

EDIT:

jetzt komme ich der Sache schon näher:

Code:

ls -la -h  /var/lib/mysql

Brachte mir diese Ausgabe
Sind das alles Log-Files von mysql? Brauch ich die?
Sieht mir so aus, als wäre das mein gesuchter Plattenplatz ...

Code:

-rw-rw----  1 mysql mysql 426K Sep 28 22:40 mysql-bin.000001
-rw-rw----  1 mysql mysql 405K Sep 28 23:07 mysql-bin.000002
-rw-rw----  1 mysql mysql 306K Sep 28 23:28 mysql-bin.000003
-rw-rw----  1 mysql mysql 1.1G Oct 18 11:30 mysql-bin.000004
-rw-rw----  1 mysql mysql 1.1G Nov  2 02:58 mysql-bin.000005
-rw-rw----  1 mysql mysql 1.1G Nov  9 04:13 mysql-bin.000006
-rw-rw----  1 mysql mysql 1.1G Nov 17 16:45 mysql-bin.000007
-rw-rw----  1 mysql mysql 1.1G Dec  5 10:18 mysql-bin.000008
-rw-rw----  1 mysql mysql 1.1G Jan  2 20:50 mysql-bin.000009
-rw-rw----  1 mysql mysql 359M Jan 13 09:28 mysql-bin.000010
-rw-rw----  1 mysql mysql 8.3M Jan 13 13:21 mysql-bin.000011
-rw-rw----  1 mysql mysql 455K Jan 13 13:40 mysql-bin.000012
-rw-rw----  1 mysql mysql 3.9M Jan 13 16:22 mysql-bin.000013
-rw-rw----  1 mysql mysql 860M Feb  1 18:28 mysql-bin.000014
-rw-rw----  1 mysql mysql  16M Feb  1 23:31 mysql-bin.000015
-rw-rw----  1 mysql mysql 489M Feb  3 20:43 mysql-bin.000016
-rw-rw----  1 mysql mysql 1.1G Feb  8 19:09 mysql-bin.000017
-rw-rw----  1 mysql mysql 288M Feb 11 13:30 mysql-bin.000018
-rw-rw----  1 mysql mysql 279M Feb 14 10:54 mysql-bin.000019
-rw-rw----  1 mysql mysql 112M Feb 15 22:10 mysql-bin.000020
-rw-rw----  1 mysql mysql 654M Feb 17 22:32 mysql-bin.000021
-rw-rw----  1 mysql mysql 2.2M Feb 17 22:47 mysql-bin.000022
-rw-rw----  1 mysql mysql  37K Feb 17 22:47 mysql-bin.000023
-rw-rw----  1 mysql mysql 716K Feb 17 22:51 mysql-bin.000024
-rw-rw----  1 mysql mysql 1.1G Feb 21 11:38 mysql-bin.000025
-rw-rw----  1 mysql mysql 1.1G Feb 25 08:49 mysql-bin.000026
-rw-rw----  1 mysql mysql 1.1G Feb 27 10:04 mysql-bin.000027
-rw-rw----  1 mysql mysql 1.1G Feb 29 20:41 mysql-bin.000028
-rw-rw----  1 mysql mysql 832M Mar  2 18:11 mysql-bin.000029
-rw-rw----  1 mysql mysql 1.1G Mar  5 11:05 mysql-bin.000030
-rw-rw----  1 mysql mysql 1.1G Mar  8 01:26 mysql-bin.000031
-rw-rw----  1 mysql mysql 272M Mar  8 18:01 mysql-bin.000032
-rw-rw----  1 mysql mysql 116M Mar  9 09:22 mysql-bin.000033
-rw-rw----  1 mysql mysql 694M Mar 11 18:40 mysql-bin.000034
-rw-rw----  1 mysql mysql  646 Mar  9 10:18 mysql-bin.index

magnum · 11 März 2012

so, also die Dateien sind Binär-Logdateien und dienen dazu, Daten nach Crashes wieder herstellen zu können und um Datenbanken synchronisieren zu können.
Ich habe mir jetzt erstmal so beholfen, dass ich in der /etc/my.cnf den Eintrag expire_logs_days reingeschrieben und auf 30 Tage gesetzt habe.

Code:

# binary logging is required for replication
log-bin=mysql-bin
# WARNING: Using expire_logs_days without bin_log crashes the server!
expire_logs_days = 30

nach einem

Code:

/etc/init.d/mysql restart

waren die LogDateien dann auch bis auf die letzten 30 Tage verschwunden, über 8 GB Speicherplatz wurde jetzt frei.

Ich hoffe, ich mach damit keinen allzu großen Fehler, aber mit der bisherigen Einstellung wäre absehbar gewesen, wann die Platte voll läuft und dann bekommt mysql ja auch ein Problem. D.h. der Server fällt aus ...

Gruß

Magnus

panamajo · 12 März 2012

Die Binary Logs werden hauptsächlich für Replikation verwendet. Wenn InnoDB verwendet wird werden dort auch Transaktionen gespeichert.
Falls du beides nicht verwendest kann man das auch ausschalten (log-bin und expire_logs_days auskommentieren).

magnum · 12 März 2012

vielen Dank für die Antwort,
das mit den Transaktionen liegt dann ja an den Anwendungen, wenn ich das jetzt ganz abschalte, dann funktionieren die überhaupt nicht mehr? Um mir den Ärger mit einer eventuellen Fehlersuche zu sparen, lass ich das erstmal angeschaltet. Im Moment siehts ja recht gut aus und der Speicherbedarf dürfte ja kaum nur noch wachsen, wenn die Datenbanken schneller bearbeitet werden. Sollte also auf absehbare Zeit gelöst sein.

viele Grüße

Magnus

bmk · 14 März 2012

Hallo Magnus,

ich hatte das Problem mit den binären Logfiles bislang immer händisch auf dem mysql-prompt gelöst:

Code:

purge binary logs to 'mysql-bin.000162';

bzw.

Code:

purge binary logs before '2012-03-14';

Jedenfalls startet bei mir der mysql-server nicht, wenn ich den log-bin-Eintrag auskommentiere.

Wenn keine Datenbankreplikationen anstehen, sollte m.E. es ausreichen, die letzten 1-2 Logfiles zu behalten. So wie es aussieht, wird bei einem mysql-Neustart und dann (zumindest bei mir) beim Erreichen der 1GB-Grenze ein neues Logfile angelegt.

Die Logfiles kann man mit

Code:

mysqlbinlog mysql-bin.000162

ansehen, bei mir ist es die Zabbix-Systemüberwachung, die für viele Datenbankaktivitäten und entsprechend große Logfiles sorgt.

Die Option expire_logs_days kannte ich noch nicht, ich werde sie mal mit dem Wert 7 ausprobieren.

Gruß bmk

magnum · 14 März 2012

dass das mit dem Auskommentieren manchmal zu Problemen führt habe ich auch schon gelesen, dort hat angeblich ein setzen der Tage auf 0 geholfen. Also so: (ungetestet)

Code:

# WARNING: Using expire_logs_days without bin_log crashes the server!
expire_logs_days = 0

Das mit dem händisch löschen ist halt recht unzuverlässig, je länger der Server problemlos läuft, umso weniger beobachtet man ihn. Und dann steht er halt von einem Moment auf den anderen und die Suche nach der Ursache geht los...

viele Grüße

Magnus

var/lib/mysql Verzeichnis zu voll

magnum

Newbie

magnum

Newbie

panamajo

Guru

magnum

Newbie

bmk

Member

magnum

Newbie