Das Problem des Tages war heute ein mySQL-Server, der plötzlich nicht mehr starten wollte. In den Logfiles fand sich eine Fehlermeldung mit wenig Aussagekraft und auch sonst deutete kaum etwas auf die Ursache hin ...
In /var/log/mysql/mysqld.log sorgte ein Start des mysql-Servers für folgende Zeilen:
110228 20:35:03 InnoDB: Started; log sequence number 9 876865675
110228 20:35:03 [Note] Recovering after a crash using /var/lib/mysql/binary_log
110228 20:35:03 [Note] Starting crash recovery...
110228 20:35:03 [Note] Crash recovery finished.
110228 20:35:03 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=0
read_buffer_size=4194304
max_used_connections=0
max_connections=200
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 7372800 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xb, backtrace may not be correct.
Bogus stack limit or frame pointer, fp=0xb, stack_bottom=0x7fffbfa70000, thread_stack=524288, aborting backtrace.
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Auf der Konsole ergab ein "/etc/init.d/mysql start" den Fehler
Starting service MySQL warning: /var/run/mysql/mysql.sock didn't appear within 30 seconds ...
Ein Googlen nach den diversen Fehlern und auch die crashing.html von dev.mysql.com brachten mich nicht wirklich weiter.
Erst ein "strace mysqld" brachte mich etwas auf die Spur. Dann kurz bevor sich der Prozess mit einem Seqfault beendete, gab das strace aus, dass mysqld gerade versuchte die Datei /var/lib/mysql/binary_log.000100 zu öffnen. Da diese Datei nicht mehr existierte, sondern erst das binary_log.000109, kam der Server wohl durcheinander und crashte.
Die Lösung war dann sehr einfach: In binary_log_index.index stehen alle aktuell verfügbaren Binlogs und nachdem ich manuell die nicht mehr existierenden Einträge gelöscht hatte, funktionierte der Server wieder. Noch sauberer wäre wohl gewesen, die fehlenden Dateien aus dem Backup zu holen.
Wie kann sowas passieren? Da die Binlogs bei einem Master-Slave-Setup u. U. relativ viel Platz verbrauchen, werden sie gerne mal Opfer unbedachter Aufräumaktionen. Das man diese Dateien hätte nicht anfassen sollen, erkennt man aber erst nach dem nächsten Dienst-Neustart. Das einzig positive an der ganzen Geschichte: Ich habe die binlogs wenigstens nicht gelöscht :-).