mysqldump: Couldn’t execute show create table – Unknown table engine ‚InnoDB‘ (1286)

Meldet sich doch heute Nacht einer meiner MySQL Backups per Mail, ganz höflich und erklärt mir das er die DB BlaBla nicht dumpen konnte und der Befehl mysqldump -bla -bla nicht ausgeführt werden konnte.

Hallo?

Die laufen schon seit Wochen auf dem Server. Die laufen seit Jahren oder gar länger auf anderen Servern. Wovon redet mein Script da?

Also rein in die Konsole und den Befehl selber abgesetzt. Da kommt tatsächlich ein Fehler der was von „mysqldump: Couldn’t execute show create table“ schwafelt und mir noch erklärt „Unknown table engine ‚InnoDB‘ (1286)“.

Keine MySQL updates Gestern gemacht. Nichts an dem Server oder gar der DB geändert. Die Backups angeschaut. Alle Vortage sind einwandfrei da und gelaufen.

Was sagt mir also das Teil? Wovon redet dieses unintelligente Stück …

Tja, da kam die Erinnerung (muß sagen, werde langsam alt) … da war doch was wenn die MySQL ein Memory Problem hat. Also kurz in die Server Überwachung geschaut und siehe da … die RAM auf dem Server war gnadenlos ausgebucht. Ok. Kein anderer Dienst hatte sich bis jetzt beschwert. Also was hat MySQL gemacht?

In kurzen Worten … er konnte den Buffer Pool für die InnoDB nicht gebacken bekommen und hat sich on the fly nur für mich eine MyISAM gebastelt. Ohne was zu sagen.

Neustart von MySQL beweist er sagt kein Ton.

root@server / # /etc/init.d/mysql restart
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
root@server / #

Ok. Also wie stellen wir fest das ich hier keine Märchen erzähle sondern das da wirklich was im Busch ist. Ganz einfach. Rein in die MySQL und Sie direkt mal fragen.

root@server / # mysql -u root -p

Fragen wir mal:

mysql> SHOW VARIABLES LIKE 'have_innodb';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_innodb | NO |
+---------------+-------+
1 row in set (0.00 sec)

mysql>

Wer sicher sein will kann auch nochmal:

mysql>SHOW ENGINES \G

… doch in der Ausgabe wird er keine InnoDB finden.

Waow … !! Unglaublich!! Also was jetzt? Also entweder ihr habt Gestern oder so den InnoDB Buffer Pool etwas zu hoch geschraubt … also das mal kleiner schrauben in der /etc/mysql/my.cnf oder herausfinden was genau mit der Ram los ist? Anderer Prozess alles geklaut?

Wer es sich leisten kann, kann mal seine InnoDB Variablen auskommentieren und MySQL die defaults nehmen lassen. Dann wieder neu starten und die Werte wie oben abfragen BIS zu dem Punkt wo er ein „YES“ bei „have_innodb“ bekommt.

Was immer wieder verblüft ist das einfache neustarten von MySQL ohne nur eien Pieps zu sagen.

Da fällt mir noch ein, wer NICHT an der Buffer Pool Size geschraubt hat, der war vielleicht an den Log Files dran. Vielleicht kann es ja jemand im Kommentar besser beschreiben. Man muß den alten Log löschen wenn man die Log größe, also innodb_log_file_size geändert hat. Sollte irgenwo hier zu finden sein /var/lib/mysql/ib_logf....

Wenn es keins der beiden ist und die InnoDB engine denoch nicht anspringt, wie gesagt. Nachdenken. Irgendwas hat sich geändert oder ist passiert, man muß es nur finden.

Thank you for this post! It was most helpful even though the innodb engine in my case became disabled due to a change of the innodb_log_file_size attribute.

If you change this attribute and forget to remove the old /var/lib/mysql/ib_logfile* the same problem will arise.