Christophs Weblog

Vierundzwanzig sind zu wenig

mySQL Segfault hausgemacht

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 :-).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Christophs Weblog © 2016