mpex Techblog

Bacula – Problem: Datenbank Fehler bei Dump: Error 2013: Lost connection to MySQL server during query when dumping table

Der Dump der Bacula Katalog Datenbank (InnoDB) bricht mit einem Fehler ab. Darauffolgende Aktionen brechen vermutlich auch mit einem Fehler ab, was aber vom ersten Fehler ausgelöst sein dürfte.

Problem

Der Dump der Bacula Katalog Datenbank (InnoDB) bricht mit dem folgenden Fehler ab: Darauffolgende Aktionen brechen vermutlich auch mit einem Fehler ab, was aber vom o.g. Fehler ausgelöst sein dürfte: Der Fehler trat in einem Fall z.B. nach einen RAID Rebuild auf. Wenn dieser Fehler bei anderen Datenbanken als dem Bacula Katalog während der Sicherung auftritt, kann diese Lösung auch helfen, muss aber mit dem Kunden koordiniert werden.

Analyse

• Zunächst die betroffenen Tabellen isolieren.
• Im Beispiel oben wird die Tabelle File aufgeführt, es ist aber nicht gesagt, dass danach nicht noch weitere Tabellenfehler auftreten, die aber aufgrund des Disconnects nicht mehr zum Zuge kommen.
• Dazu ist es empfehlenswert alle Tabellen einer Datenbank mit je einem einzelnen mysqldump Befehl zu dumpen.
  • Dabei immer genau den Dump Befehl verwenden, den das Script zum Sichern der Datenbank auch verwendet, um Abweichungen zu vermeiden.
  
  

  Lösung

  InnoDB Datenbanken: Die empfohlene Lösung, den Dump mit innodb_force_recovery bis auf die kaputten Einträge vollständig zu erstellen, hat in diesem Fall nicht wie erwartet funktioniert, es musste dann mit dem unvollständigen Dump gearbeitet werden. Bei künftigen Fehlern sollte es dennoch erstmal so probiert werden, sofern der Datenbank Fehler kein anderer ist!

• Zeitfenster suchen, in dem in den nächsten Stunden keine Backups anstehen (vermutlich tagsüber)
• Information an Technik und ggf. Kunden, falls mit Restores zu rechnen ist
• Vorbereitung
  # Vollsicherung erstellen (vorher prüfen ob genug Speicherplatz) /etc/init.d/mysql stop touch mysql-dump-save-$(date +%Y%m%d).tar ; chown root.root mysql-dump-save-$(date +%Y%m%d).tar ; chmod 600 mysql-dump-save-$(date +%Y%m%d).tar tar cf mysql-dump-save-$(date +%Y%m%d).tar /var/lib/mysql echo -e "[mysqld]\ninnodb_force_recovery=1" > /etc/mysql/conf.d/innodb_recovery_temp.cnf /etc/init.d/mysql start

• Dump der defekten Tabellen erstellen, bei InnoDB ggf. mit extra Settings zum schnelleren einlesen
  echo -e "SET autocommit=0;\nSET unique_checks=0;\nSET foreign_key_checks=0;\n" > dump.sql time mysqldump <Dump Optionen laut originalem Dump Script> <Datenbank> <Tabelle> >> dump.sql # Ggf. weitere defekte Tabellen einzeln Dumpen # time mysqldump <Dump Optionen laut originalem Dump Script> <Datenbank> <Tabelle 2> >> dump.sql echo -e "\nCOMMIT;" >> dump.sql

• Prüfen, ob der Dump durchlief und wie groß das Ergebnis ist
• Recovery Mode wieder deaktivieren
  rm /etc/mysql/conf.d/innodb_recovery_temp.cnf /etc/init.d/mysql restart

• Bacula Director stoppen
• Sofern das der Dump nicht schon aufgrund der verwendeten Dump Optionen enthält: Soeben gedumpte Tabelle(n) innerhalb der Datenbank löschen:
  use <Datenbank>; DROP TABLE <defekte Tabelle>;

• Erstellten Dump wieder einspielen
• Bacula Director wieder starten
• Selektive Restore Tests mit mindestens 4 Clients durchführen, dabei unterschiedliches Restore Datum wählen
  bconsole * restore 6 [Restore Zeit] [Client] $ add [Datei]

• Ggf. wiederherstellen verlorener Katalog Einträge mittels bscan

Request Tracker – Problem: Fehlermeldung "[Mason] Cannot resolve file to component"

Fehlermeldung: Request Tracker Webinterface "[Mason] Cannot resolve file to component".

Artikel lesen

Puppet – Problem: Fehler beim Import von Exported Resources

Puppet Lauf ist fehlerhaft und es kommt zu folgender Fehlermeldung: Could not evaluate: is required attribute for bei mehreren Exported Resources.

Artikel lesen