DbLog erkennt nicht, dass MySQL nicht mehr läuft - state bleibt connected

[wkarl]

Hallo,

zu dieser Situation bin ich auf Umwegen gekommen. Habe mich heute nachmittag an fhem gesetzt und einen Raum mit gplots aufgerufen (auf iMac mit Chrome, hat nicht mit der aktuellen iOS8 Diskussion zu tun). Ergebnis - alle plots leer und fhem abgestürzt. fhem in der Console laufen lassen ergibt als letztes Lebenszeichen

Code Auswählen Erweitern

Can't call method "prepare" on an undefined value at /opt/fhem/FHEM/93_DbLog.pm line 891.
Zufälligerweise sehe ich, dass MySQL nicht läuft. Nach Starten von MySQL sind die plots wieder da und fhem stürzt nicht ab.
Bei der Untersuchung wie ich dem automatisch entgegenwirken kann, stelle ich fest, dass nach Stoppen der DB der DbLog Status unbeeindruckt connected behauptet.

Kann dies jemand bestätigen?

Danke und ciao
walter

[kmatthias]

Hallo Walter,

ja, kann ich. Heute ist FHEM komplett tot. In der Vergangenheit fehlten immer nur die Logeinträge und FHEM lief noch. Bei mir läuft nachts immer ein DB Backup. Dazu wird MySQL beendet und später wieder gestartet.

In Perl und den FHEM Modulen kenne ich mich nicht wirklich gut aus. Aber anhand Deiner Fehlermeldung würde ich sagen: Beim Senden der Daten zur Datenbank sollte erst geprüft werden, ob die Verbindung noch besteht. Falls nicht, müsste sie erst wiederhergestellt werden. Kann das jemand ändern?

Viele Grüße
Matthias

[rudolfkoenig]

Dazu wird MySQL beendet und später wieder gestartet.

Das geht doch auch online. Gibt es einen besonderen Grund fuer den Stopp?
Nein, ich will nix reparieren, bin nur neugierig.

[kmatthias]

Ja, ich mache eine Kopie der entsprechenden Tabellen aus dem data/ Verzeichnis von MySQL. Ich hatte mal gelesen, dass es besser ist, den MySQL Server erst zu stoppen, damit die Daten konsistent sind.

[rudolfkoenig]

Wenn man cp als Backup-Tool verwendet, ist das vmtl. auch besser, obwohl ich schon oefters ohne Stoppen mit cp eine verwendbare Kopie erstellt habe.


Ich verwende aber lieber mysqldump zum Sichern, weil es lesbare create bzw. insert Statements generiert, die man mit einem Editor bearbeiten/pruefen kann.

[kmatthias]

Ist bei mir genau andersherum. Das SQL interessiert mich in diesem Fall nicht weiter. Sollte mal der Restore anstehen, kopiere ich die Dateien einfach zurück. Mysqldump benutze ich immer zum Überträgen der Daten zwischen verschiedenen MySQL Servern.

[kmatthias]

Man könnte über $dbh->ping gucken, ob die Verbindung noch steht bzw. vor dem Ausführen einer Query mit $dbh->connect_cached(...) die Verbindung herstellen.

Wie bekommt man solche Erweiterungen in den offiziellen Code?

[rudolfkoenig]

Indem man dem Modul-Maintainer (siehe MAINTAINER.txt) einen Patch schickt, und hofft, dass er keine Probleme damit hat.