Nach einem Stromausfall von ca. 1 Stunde diese Woche hatte ich eine korrupte mysql-Datenbank: Eine der mysql-Datenbanken war so kaputt, dass sie sich nicht mehr von selber reparieren und hochfahren konnte. Eigentlich hätte ich von einer “ordentlichen” DB erwartet, dass sie das wirklich selber “löst”… Naja, also musste ich selber Hand anlegen und die korrupte mysql-Datenbank wieder zum Laufen bringen.

Hier eine Skizze der von mir unternommenen Schritte:

• vi /opt/dockervolumes/zabbix-int/mysql.conf.d/mysqld.cnf ->

  [mysqld]
  innodb_force_recovery = 1
  

  Nun mysql wieder hochfahren und schauen, ob es wieder läuft. Dazu tail -F /opt/dockervolumes-docker-int1/zabbix-int/var_lib_mysql/error.log.

  Den Wert bei innodb_force_recovery habe ich nun schrittweise erhöht – jeweils unter Erhöhung der Gefahr des Datenverlustes (siehe mysql-Doku) bis die DB wieder lief – nun jedoch nur im Read-Only-Mode.

• mysqldump und Neu-Einspielen der Daten – ähnlich wie hier beschrieben. Zur Beschleunigung des Einspielens noch ein paar Checks abgeschaltet:

  (echo "SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0;" \
  && cat /opt/dockervolumes/zabbix-int/mysql-backup-weekly/mysqldump_zabbix.after-crash.sql ) \
  | docker exec -i zabbix-int_mysql_1 mysql -h mysql -u root --password=xxx zabbix --default-character-set=utf8
  

• Danach die Checks wieder an:

  echo "SET autocommit=1; SET unique_checks=1; SET foreign_key_checks=1;" 
  | docker exec -i zabbix-int_mysql_1 mysql -h mysql -u root --password=xxx zabbix --default-character-set=utf8
  

Nachdem schon der Dump für die betroffene 12 GB Datenbank (grob geschätzt) ca. 30 Minuten gedauert hat, brauchte der Import (trotz abgeschalteter Checks) über 6 Stunden. Wenn die DB also noch weiter wächst, wird das so immer unpraktikabler. Ich weiß noch nicht, wie ich das dann löse…

Spontan würde ich ja sagen, dass es ja “bekanntermaßen” keine gute Idee ist, eine DB in einem Docker-Container laufen zu lassen. Aber ich habe erfahren, dass das gleiche Problem auch bei mysql auf einer echten, physischen Maschine passiert ist. Das ist ja im übrigend auch nicht das erste Mal, dass ich eine msql-DB reparieren muss… Daher bleibt die Frage für’s Erste offen. Hat jemand Vorschläge, die im Hobby-Bereich praktikabel umsetzbar sind?