DB lob funktioniert seit Update nicht mehr

[Forstling]

Hallo

Ich habe Mal die verrückte Idee gehabt meinem FHEM ein Update zu verpassen.

Das System läuft seit jahren auf meinem Raspberry
Bisher ohne Probleme

Seit dem Update funktioniert DB log nicht mehr. (und ein Modul wo nur eine veraltete Version beim Update kommt, das habe ich aber wieder aktuell)
Was ich bisher rausfinden konnte ist das vermutlich die ganze Datenbank nach dem Update abgestützt ist. Mich direkt nach dem start des Datenbank service noch versuchen anzumelden. Da kommt wenn ich schnell genug bin die Meldung Passwort falsch (wenn ich das richtige eingebe ist der Service schon wieder abgestürtzt.)
Ich nutze MariaDB
Hin und wieder funktioniert die Datenbank mal kurz wieder.
Bin gerade am verzweifeln

Noch ein Paar Infos
SD Karte ist zu 44% belegt
Datenbankgröße sind 7,9GB

Hat jemand erfahrung mit so etwas.

[DS_Starter]

Sorry, aber ich werde aus dem was du schreibst nicht schlau.
Mit diesen "Informationen" kann dir niemand helfen.

Für den Anfang solltest du zumindest mal einen Auszug der Logmeldungen der angezeigten Fehler posten und sicherlich ist auch ein Auszug der Logmeldungen bei FHEM Start hilfreich.

VG

[Forstling]

Ok war ein Wenig unverständlich.

Also nochmal langsam
Ich habe ein Update von FHEM gemacht ("update all")

Seitdem funktioniert DB_log nicht mehr.
Mein Logfile wird mit folgenden Meldung überfüllt:

Code Auswählen Erweitern

2023.01.27 17:35:01 3: DbLog DBLogging - SubProcess connected to fhem
2023.01.27 17:35:07 2: DbLog DBLogging - Error table history - DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]
executing 97153 generated 97144 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 2998.

2023.01.27 17:35:07 2: DbLog DBLogging - Error - DBD::mysql::db rollback failed: Turning on AutoCommit failed at ./FHEM/93_DbLog.pm line 4204.

2023.01.27 17:35:09 2: DbLog DBLogging - ERROR: DBI connect('database=fhem;host=localhost;port=3307','fhemuser',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) at ./FHEM/93_DbLog.pm line 2497.

2023.01.27 17:35:33 3: DbLog DBLogging - SubProcess connected to fhem
2023.01.27 17:35:39 2: DbLog DBLogging - Error table history - DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]
executing 97254 generated 97227 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 2998.

2023.01.27 17:35:39 2: DbLog DBLogging - Error - DBD::mysql::db rollback failed: Turning on AutoCommit failed at ./FHEM/93_DbLog.pm line 4204.

2023.01.27 17:35:41 2: DbLog DBLogging - ERROR: DBI connect('database=fhem;host=localhost;port=3307','fhemuser',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) at ./FHEM/93_DbLog.pm line 2497.


Daraufhin habe ich mioch versucht von einem anderen Rechner auf die Datenbank zu schalten.
Dies hat bisher immer funktioniert dazu nutze ich HeidiSQL.
Allerdings funktioniert das auch nur Teilweise. und wenn es funktioniert auch nur kurz.

Als nächstes wollte ich mich direkt auf dem Raspberry auf die Datenbank anmelden.
Auch hier kommen ich nicht drauf. das maximalste was geht ist ohne Passwort da kommt ab und zu die Meldung Passwort falsch. (was ohne Passwort ja normal ist.)

Als nächstes habe ich mir gedacht es liegt vielleicht daran, dass das Betriebssystem nicht aktuell ist und habe den Raspberry auf den neusten Stand gebracht.

Auch hier gleicher Fehler.

Wenn ich jetzt in FHEM einen SVG Plot anschaue sehe ich (wenn ich Glück habe) das pro Tag vielleicht 4-5 Werte in die Datenbank geschrieben werden.
Also ganz gestorben ist sie wahrscheinlich noch nicht.

Ich hoffe mein Problem ist jetzt verständlicher.
Jetzt noch ein paar Daten zum System:
System läuft seit November 2020 ca. ein halbes Jahr später habe ich auf DB-Log umgestellt.
Datenbank ist jetzt ca. 8GB
Raspberry Pi 4 GB RAM
64GB SD Karte 32GB frei

Hat jemand ähnliche Erfahrung?
Kann das mit dem Update zusammen hängen?

[DS_Starter]

Das Hauptproblem ist dass sich deine MySQL DB abhängt:

Code Auswählen Erweitern


2023.01.27 17:35:07 2: DbLog DBLogging - Error table history - DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]


Alles andere sind Folgefehler.
Der Fehler "MySQL server has gone away" hat in unserem Umfeld meistens damit zu tun dass zu große Datenmengen auf einmal an den Server übertragen werden sollen und nicht zur gesetzten MySQL Variable max_allowed_packet im my.cnf passen.

Im Netz gibt es viele Hilfe dazu, eine ist hier: https://matomo.org/faq/troubleshooting/faq_183/

Um die Theorie zu prüfen stelle das DbLog Device auf asyncMode = 0.
Damit sind die Datenmengen überschaubar und/oder begrenze die zu loggenden Events. Wie viel zur Zeit geloggt wird kann ich nicht einschätzen.

Weiterhin prüfe die Variable max_allowed_packet und setze sie z.B. auf 1M. Wenn sie nicht vorhanden ist, verwendet MySQL seinen Standard und du setzt sie neu in der my.cnf. Mit der Größe 1M habe ich bei mir keinerlei Probleme, egal mit welchem Modus.

[Forstling]

Meine Vermutung war, dass die SD-Karte langsam den Geist aufgibt
Daher habe ich mal die Karte auf eine neue kopiert, allerdings ohne Erfolg.

Sämtliche Einstellungen im DB-Log bringen auch keine Änderung.

Das Problem ist, dass jetzt noch nicht mal der Datenbankdienst auf dem Raspberry starten möchte.

Ich habe jetzt erst mal die Datenbank erst mal auf einen anderen Rechner gelegt. Jetzt funktioniert der Log erst mal wieder.

Ich denke die Datenbank ist dort erst mal besser aufgehoben. Jetzt müsste ich nur noch die Daten aus der Datenbank vom Raspberry auf den anderen Rechner bringen.
Weiß hier jemand wie das geht?

[DS_Starter]

Ja, zum Bsp. mit DbRep exportToFile und importFromFile die Daten exportieren und auf der anderen Db importieren.
Weil deine Db zuemlich gross ist würde ich zb. monatsweise übertragen. Geht mit DbRep .

[Forstling]

Gut jetzt weiß ich wie ich die Daten von der einen Datenbank in die andere bringe.

Jetz muss ich nur den Datenbank service auf dem Raspberry wieder zum laufen bringen.

Kann ich 2 DB-Logs gleichzeit in einer FEHM Instanz laufen lassen?
Ich habe doch nur eine Definitionsdatai.

Jetzt wo ich wieder in eine Datenbank schreiben kann braucht FHEM auch nicht mewhr soviel CPU Leistung.

Aber erst mal zum jetzt vorhandenen Problem. wenn ich versuche den Datenbankservice zu starten erhalte ich folgende Meldung:

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl): mysql.serviceJob for mariadb.service failed because a fatal signal was delivered to the control process.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
failed!


Jetzt mus ich erst mal die Dateien und logs der Datenbank suchen um hier den Fehler zu finden.

[DS_Starter]

Kann ich 2 DB-Logs gleichzeit in einer FEHM Instanz laufen lassen?
Ich habe doch nur eine Definitionsdatai.

Ja, kannst du. Auf meinem Testsystem laufen 8 Dblog parallel.
Die Definitionsdatei kann doch unterschiedlich heißen. dbconf1, dbconf2 usw.
Du musst nur die passende Konfigdatei im Dblog Device angeben.

[Forstling]

ok Danke

Hier ein Auszug aus dem Log von MariaDB
Kann es sein das meine Datenbank einfach nur zu groß ist und daher abschmiert.
Aber 8GB ist für eine Datenbank eingentlich noch nicht riesig.

Code Auswählen Erweitern

2023-01-29 19:39:38 0 [Note] InnoDB: Using Linux native AIO
2023-01-29 19:39:38 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2023-01-29 19:39:38 0 [Note] InnoDB: Uses event mutexes
2023-01-29 19:39:38 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2023-01-29 19:39:38 0 [Note] InnoDB: Number of pools: 1
2023-01-29 19:39:38 0 [Note] InnoDB: Using generic crc32 instructions
2023-01-29 19:39:38 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2023-01-29 19:39:38 0 [Note] InnoDB: Completed initialization of buffer pool
2023-01-29 19:39:38 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2023-01-29 19:39:38 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 51 row operations to undo
2023-01-29 19:39:38 0 [Note] InnoDB: Trx id counter is 186500076
2023-01-29 19:39:38 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2023-01-29 19:39:38 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2023-01-29 19:39:38 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2023-01-29 19:39:38 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2023-01-29 19:39:38 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2023-01-29 19:39:38 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2023-01-29 19:39:38 0 [ERROR] InnoDB: Page [page id: space=5, page number=753089] log sequence number 59366609458 is in the future! Current system log sequence number 59366580439.
2023-01-29 19:39:38 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-01-29 19:39:38 0 [ERROR] InnoDB: Page [page id: space=5, page number=770048] log sequence number 59366636671 is in the future! Current system log sequence number 59366580439.
2023-01-29 19:39:38 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2023-01-29 19:39:38 0 [ERROR] [FATAL] InnoDB: InnoDB is trying to free page [page id: space=5, page number=785750] though it is already marked as free in the tablespace! The tablespace free space info is corrupt. You may need to dump your tables and recreate the whole database!Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
230129 19:39:38 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.3.36-MariaDB-0+deb10u2-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466215 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             28133                28133                processes
Max open files            32768                32768                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       28133                28133                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                   
Max realtime priority     0                    0                   
Max realtime timeout      unlimited            unlimited            us       
Core pattern: core

Kernel version: Linux version 5.10.103-v7l+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1529 SMP Tue Mar 8 12:24:00 GMT 2022



[DS_Starter]

Nein zu groß ist sie nicht.

Aber wenn ich das Log so sehe, sieht es wirklich nach einem nicht so trivialen Fehler aus.
Schau dir mal an -> https://mariadb.com/kb/en/library/innodb-recovery-modes/

Weiterhin mysqld got signal 6->
... the error say it clearly, your database corrupt or you doesn't copy the log. you may have to recover from a backup

Also ist die DB korrupt würde ich sagen. Wenn du ein aktuelles Backup hast, wäre es wahrscheinlich am Besten dieses zu restoren und dann die Daten per Export / Import auf die neue DB zu übertragen.
Sonst bleibt wohl nur ein Reparaturversuch über ein recovern mit den Hinweisen in dem oberen Link.

[Forstling]

Dachte ich mir schon das ich nie einfach zu lösende Probleme habe.

Nun ja aktuelles Backup ... Das erinnert mich das ich mir mal ein Programm suchen mus welches das Automatisch macht. Heißt da ist keins vorhanden.

Ja und eine Seite zum Reparieren der Datenbank habe ich auch schon gefunden mit

Code Auswählen Erweitern

innodb_force_recovery = 3
startet die Datenbank zumindest wieder und ich kann mit HeidiSQL darauf zugreifen.

Wenn ich die Datenbank allerdings in FHEM einbinde stürzt sie ab und es kommen die Fehler von oben.

[DS_Starter]

Wahrscheinlich kommt das Problem sobald du in die DB schreiben willst.
Vllt. kommst du voran, wenn du DbLog disabelst. Dann wird nicht geschrieben.
Aber du kannst über DbRep immernoch die DB lesen und den Export durchführen.
Probieren ...

[DS_Starter]

Apropos ....

Nun ja aktuelles Backup ... Das erinnert mich das ich mir mal ein Programm suchen mus welches das Automatisch macht. Heißt da ist keins vorhanden.

Für MariaDB ist Backup (und Restore) in Dbrep eingebaut. Nur einrichten und du hast jeden Tag ein aktuelles Backup direkt aus FHEM heraus mit optionalem FTP Transfer sowie integrierter Versionsverwaltung.

[Forstling]

Das mit dem Backup werde ich machen sobald ich die Daten synchronisiert habe.

Ich habe es jetzt geschafft die Datenbank zu verbinden und auf Disable zu setzen das funktioniert.

Wenn ich jetzt den Befehl "set history exportToFile" bekomme ich eine 8GB große .csv Datei mit knapp 63 Millionen Einträgen.
Jetzt ist nur die Frage hält das der Raspberry aus oder stürzt er ab.
Wenn FHEM zu stark beschäftigt ist kommt es auch seiner Hauptaufgabe nicht mehr rihtig nach und das wäre aktuell nicht gut.

Ja, zum Bsp. mit DbRep exportToFile und importFromFile die Daten exportieren und auf der anderen Db importieren.
Weil deine Db zuemlich gross ist würde ich zb. monatsweise übertragen. Geht mit DbRep .

Im Wiki habe ich keine Möglichkeit gefunden das Monatsweise abzurufen wie funktioniert das?

[DS_Starter]

Naja die erste Adresse für Informationen ist immer die Hilfe zum Modul.
Schau dir die Hilfe zum "set ... exportToFile" an -> help DbRep de

Du kannst den Export auch automatisch in Dateien der Größe X splitten lassen beim Export.

Es gibt die Attribute timestamp_begin, timestamp_end. Damit kann man den Zeitraum festlegen.