MySQL Binary Logs: Löschen funktioniert nicht

[Anonymous]

Hallo!

Ich habe ein paar Probleme mit meinen MySQL Binary Logs: Diese sammeln sich nun seit dem Aufsetzen meines Servers in /var/log/mysql und können weder automatisch noch manuell (über MySQL) gelöscht werden.

Mein System:
- AMD 64 CPU
- Debian 4
- MySQL 5.0.32 -Debian_7etch5
- PHP 5.2.0-8+etch10
- Apache 2.2.3

Meine /etc/mysql/my.cnf schaut wie folgt aus:

Code: Select all

[...]
# The following can be used as easy to replay backup logs or for replication.
#server-id      = 1
log_bin         = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See README.Debian!
expire_logs_days   = 5
max_binlog_size         = 100M
#binlog_do_db      = include_database_name
#binlog_ignore_db   = include_database_name
[...]

Demnach sollten die Binlogs also nach 5 Tagen automatisch gelöscht werden.

Dennoch schaut mein /var/log/mysql Ordner so aus:

Code: Select all

mysql-bin.000001  13kB  mysql  adm  29/Feb
mysql-bin.000002  104MB  mysql  adm 29/Feb
[...]
mysql-bin.000109  104MB  mysql  adm  06:25
mysql-bin.000110  27MB  mysql adm  11:22
mysql-bin.index

Der ganze Ordner belegt momentan 7,6 GB und enthält alle binlogs seit der Installation von Debian.


Die mysql-bin.index schaut übrigens so aus:

Code: Select all

/var/log/mysql/mysql-bin.000001
/var/log/mysql/mysql-bin.000002
[…]
/var/log/mysql/mysql-bin.000109
/var/log/mysql/mysql-bin.000110

Wenn ich nun unter mysql direkt mit PURGE MASTER LOGS TO 'mysql-bin.000010'; bzw.
PURGE BINARY LOGS TO 'mysql-bin.000010'; versuche die Binlogs zu löschen, erhalte ich die Fehlermeldung:
ERROR 1373 (HY000): Target log not found in binlog index

Auch RESET MASTER; klappt nicht. Fehler:
ERROR 1105 (HY000): Unknown error

SHOW MASTER LOGS, SHOW BINARY LOGS bringen mir den Fehler:
Empty set (0.00 sec)

Show Master Status zeigt aber:
File | Position | Binlog_Do_DB | Binlog_Ignore_DB
Mysql-bin.000110 | 28351971

Es scheint als ob MySQl Probleme hätte die Binlogs zu finden und anzusprechen und sie deshalb auch nicht löschen kann.

MySQl arbeitet ansonsten fehlerfrei, die Logs zeigen nichts Auffälliges.

Hat jemand einen Tipp für mich, wo hier das Problem liegen könnte und wie ich die alten Binlogs dennoch (automatisch) löschen kann?

Von der Gewaltmethode (binlogs einfach aus dem Verzeichnis löschen) habe ich bisher abgesehen. Würde das im Notfall schadenfrei funktionieren?

[Joe User]

Funktioniert problemlos:

Code: Select all

back_log                        = 50
sync_binlog                     = 0
binlog_cache_size               = 1M
max_binlog_size                 = 100M
expire_logs_days                = 7

[Anonymous]

Bei mir funktioniert es mit diesen Einstellungen nicht
Weder das automatische Löschen der alten mysql-bins noch das manuelle Löschen dieser aus mysql heraus funktioniert. Fehlermeldungen wie im ersten Beitrag.

Sind denn die Einstellungen User "mysql", Group "adm" sowie die Permission 0660 soweit korrekt für die mysql-bin.* & mysql-bin.index? Ich habe gerade über einige Probleme mit dem Debian Logfile Rotation gelesen, daß in früheren Versionen bereits zu Problemen deswegen geführt hat.

[Joe User]

Normalerweise hat mysql-bin.log die Rechte mysql/mysql/0660 aber Debian geht bekanntlich gerne eigene (Holz)Wege. logrotate hat mit den Binlogs nichts zu tun, dafür ist der MySQLd zuständig. Was sagen denn mysql[d].(log,err) zum Problem?

[theomega]

Und: Welche Dateien enthählt der Binary-Index? Es müßte in dem Order der Logs eine Text-datei mit der endung .index geben wenn mich nicht alles täuscht.

[isotopp]

Und: Welche Dateien enthählt der Binary-Index? Es müßte in dem Order der Logs eine Text-datei mit der endung .index geben wenn mich nicht alles täuscht.

Man sollte an dieser Datei niemals bei laufendem Server rum pfuschen. Der Server hält sie offen und schließt sie auch bei FLUSH LOGS nicht. DIes ist ein Fehler, aber nicht zu ändern.

Daher: Server beenden. Datei neu erzeugen. Server neu starten.

Ein beliebter Spaß ist es auch, Binlogs von Hand zu löschen, anstatt expire_logs_days walten zu lassen oder PURGE MASTER LOGS zu verwenden. Dies führt ebenfalls zu den beschriebenen Symptomen.