archivKoData muss regelmäßig repariert werden

[lio123]

Hallo,

bei meinem EDOMI-System muss regelmäßig repariert werden. Dh momentan fällt sie regelmäßig um Mitternacht aus (letzte 3 Tage beobachtet).
Kein definierter Zeitpunkt feststellbar und ich lese das aus den Diagrammen ab, die nach der Reparatur wieder zur Verfügung stellen.
System- und Fehlerlog geben hier für mich keine Aufschlüsse.

Hat da jemand eine Idee, wie ich der Sache auf die Spur komme?

Danke und Grüße,
Lio

[givemeone]

Backup ist es nicht? (ggf. Füll disk wegen Backup?)
Das Si d meine einzigen Abstürze der letzten Jahre.

[lio123]

givemeone
hatte ich vergessen zu erwähnen, die Backups sind es nicht, Festplatte ist nur 1/3 voll.

[jonofe]

Dh momentan fällt sie regelmäßig um Mitternacht aus (letzte 3 Tage beobachtet).

Wer genau fällt aus?

Findet ein Reboot statt?

[lio123]

jonofe

die archivKoData (reicht das?)

Weder unmittelbar davor noch danach findet ein reboot statt. Möchte das aber noch mal genau testen.
In den Logs war aber bisher nichts verdächtiges zu erkennen.

Gestern war der Ausfall ca 23:20h zu verzeichnen, vorgestern ziemlich genau um 0:00h.
Da fand kein reboot statt.

[jonofe]

Gestern war der Ausfall ca 23:20h zu verzeichnen, vorgestern ziemlich genau um 0:00h.
Da fand kein reboot statt.

Eine Tabelle an sich kann ja nicht ausfallen. Ist dann die mySQL DB nicht verfügbar? Woran erkennst du den "Ausfall"? Was genau hast du um 23.20 Uhr beobachtet und welche Log Einträge / Meldungen gab es dann?

[lio123]

jonofe

Ich habe es aus den Diagrammen abgelesen, muss ich aber jetzt revidieren, nachdem ich mir die Datenarchive heruntergeladen habe ist nun klar zu sehen, dass ab Mitternacht keine Werte mehr geschrieben werden.

Hier ein Auszug aus dem Systemlog mit genauer Bezeichnung der Datenbank:

SystemLog.jpg

Hier im Systemlog was um 0:00h passiert:

NullUhrSystemLog.jpg
Und hier das Fehlerlog:
ErrorLog.jpg

[lio123]

mittlerweile kann ich sagen, dass die edomiLive.archivKoData immer um 0:00h und bei jedem Neustart von Edomi ausfällt und repariert werden muss.
In den Edomi-Logs finde ich keine Hinweise.
Gibt es ggf ein MySql-Log in das man schauen könnte?

[jonofe]

Wie viele Einträge sind denn in der Tabelle?

[lio123]

jonofe

das sind 482.629 Einträge, Stand heute morgen.

Download.jpg

[jonofe]

okay, das sollte dann nicht die Ursache sein.
Sowas kann natürlich auch immer durch HW Fehler (Prozessor/RAM/Platte) verursacht werden. Allerdings wäre es dann erstaunlich warum das immer nur um 0:00 Uhr auftritt. Mir fällt da jetzt auch nicht mehr viel ein ...

[lio123]

hmm...
Mir ist aufgefallen, dass der RAM ziemlich stabil bei rund 68% liegt. Vllt recht hoch, aber auch ziemlich stabil. (im EDOMI-Monitor)

kann man die RAM-Auslastung irgendwie aufzeichnen, eine Historie auslesen?

[starwarsfan]

Was ist das denn für ein System? Blech? Container? Wie lange läuft es schon in diesem Setup? Hast Du in der Zeit vor dem Auftreten des Problems etwas geändert? Auch am System/Netzwerk darum herum?

[lio123]

starwarsfan


Edomi läuft seit über 3Jahren auf einem FUJITSU Futro S920 mit 4 GB RAM 1,5 GHz unter CenOS7 und das ziemlich stabil.
Ansonsten ein ganz normales System, kein Container, etc

Ausser ggf zusätzliche Logiken mit Datenarchiven und etwas Visu-Kosmetik hat sich am System nichts geändert.
Die letzte Datenarchiv habe ich versuchsweise auch schon wieder gelöscht.

Ein Stromausfall wäre möglich, ist mir aber nicht bekannt.

Die KNX-Schnittstelle bietet ein WireGate der ersten Generation. Hier muss ich hin und wieder den EibKNX neu starten.

Ich wurde auf den Ausfall aufmerksam, als die Diagramme keine Linien mehr anzeigten. Das war vor ca 3 Wochen, ich konnte mich aber erst letzte Woche darum kümmern.
In der Zeit wurde Edomi von einem Router auf einen Anderen umgezogen, das würde ich noch mal rückgängig machen.
Ansonsten ggf in einen RAM investieren.

[lio123]

Es schneint nach einer Reperatur auf der Konsole zu funktionieren.
Nach einem Neustart und einmal Übernacht, gab es keine Ausfälle-davor immer zu diesen Ereignissen.

Hier was ich getan habe:
https://www.databasefilerecovery.com...ir-failed.html

MyISAM file /var/lib/mysql/edomiAdmin/user.MYI

danach gab's dann mehr Info was los ist:

myisamchk: MyISAM file /var/lib/mysql/edomiAdmin/user.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
MyISAM-table '/var/lib/mysql/edomiAdmin/user.MYI' is usable but should be fixed
myisamchk: MyISAM file /var/lib/mysql/edomiLive/archivKoData.MYI
myisamchk: warning: 1 client is using or hasn't closed the table properly
myisamchk: error: Found 467064 keys of 467060
myisamchk: error: Record-count is not ok; is 467064       Should be: 467060
myisamchk: warning: Found 6335304 deleted space.   Should be 6335512
myisamchk: warning: Found      95675 deleted blocks       Should be: 95678
myisamchk: warning: Found     567704 key parts. Should be: 567703
MyISAM-table '/var/lib/mysql/edomiLive/archivKoData.MYI' is corrupted
Fix it using switch "-r" or "-o"
...
​...
​

danach dann erster erfolgloser Reparaturversuch mit

myisamchk -r /var/lib/mysql/edomiLive/archivKoData.MYI

​

siehe Ergebnis:

- recovering (with sort) MyISAM-table '/var/lib/mysql/edomiLive/archivKoData.MYI'
Data records: 467508
myisamchk: error: Can't create new tempfile: '/var/lib/mysql/edomiLive/archivKoData.TMD'
MyISAM-table '/var/lib/mysql/edomiLive/archivKoData.MYI' is not fixed because of errors
Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag

​

Also dann mit -f probiert, voilá:

[root@edomi ~]# myisamchk -f /var/lib/mysql/edomiLive/archivKoData.MYI
Checking MyISAM file: /var/lib/mysql/edomiLive/archivKoData.MYI
Data records:  467554   Deleted blocks:   95383
myisamchk: warning: 1 client is using or hasn't closed the table properly
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
myisamchk: error: Found 467558 keys of 467554
- recovering (with sort) MyISAM-table '/var/lib/mysql/edomiLive/archivKoData.MYI'
Data records: 467554
- Fixing index 1
- Fixing index 2
Data records: 467558

​

Danke an alle Supporter!