Lösungen und Tipps von den mpex Profis

mpex Techblog

11.11.2020

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:
10-Sep 21:16 bacula-fd JobId 262719: ClientRunBeforeJob: mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table File at row: <Zeile>
Darauffolgende Aktionen brechen vermutlich auch mit einem Fehler ab, was aber vom o.g. Fehler ausgelöst sein dürfte:
10-Sep 21:16 bacula-fd JobId 262719: ClientRunBeforeJob: mysqldump: Couldn't execute 'show table status like 'FileSet'': MySQL server has gone away (2006)
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

Kann mpex weiterhelfen?

Mit über 20 Jahren Erfahrung im Bereich Managed Hosting haben wir ein umfangreiches Repertoire an Problemlösungen angesammelt, die uns beim Betrieb von Serverumgebungen auf höchstem technischen Niveau geholfen haben. Unsere Systeme bauen komplett auf Open-Source-Technologien auf. Damit sind wir flexibel und können bei technischen Schwierigkeiten direkt selbst eingreifen. Analog zur Open-Source-Idee haben wir uns für diesen Techblog entschieden, um unsere Expertise und Problemlösungen mit dir zu teilen. Dazu zählen Technologien wie Bacula, Debian, Pacemaker, Puppet, diverse allgemeine Serverprobleme und noch vieles darüber hinaus. Wenn du mehr über unsere individuellen Business-Lösungen erfahren und dich als Admin auf deine Kernkompetenzen konzentrieren möchtest, sprich uns einfach an. Wir realisieren das Managed Hosting deiner Anwendung und kümmern uns in Zukunft um all solche Probleme.

Zum Kontaktformular
mpex GmbH
Weitere Blog Artikel
27.01.2021

E-Mail Versand von der Linux Kommandozeile (am Beispiel Gmail unter Debian/Ubuntu)

Manchmal möchte man den Status eines Scripts einfach und schnell von einem Server per E-Mail übermitteln. Dies kann unter Linux auch über authentifizierte E-Mail Accounts über die Kommandozeile erfolgen. Wir zeigen wie es unter Ubuntu/Debian funktioniert.

Artikel lesen
27.01.2021

Bacula – Problem: Fehlermeldung bei bacula-fd Start unter Debian 10

Bei dem Start von bacula-fd unter Debian 10 kommt es zu folgender Fehlermeldung: "Failed to initialize TLS context for File daemon".

Artikel lesen

Kontaktformular - Sprechen Sie uns an!

Sprechen Sie uns an!

Sie wollen mehr über uns und unsere Leistungen erfahren? Lernen Sie uns im persönlichen Gespräch kennen!

Telefon: +49 30 780 97 180
E-Mail: info@mpex.de