Bewährte Histogrammfunktion?
-
@bananajoe Danke, momentan läuft sie gerade (noch). Beim nächsten ungewollten Beenden schaue ich im log nach.
Kann man da ein loglevel einstellen? Soll ich da etwas höher stellen? -
@klassisch könnte man wohl aber bisher hatte bei solchen Fehlern der Standard gereicht.
-
@bananajoe gestern Abend hat MariaDB wieder gestreikt
Im ioBroker sieht das log so aus:
2022-03-30 17:34:50.601 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654479478, 997, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.618 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654486481, 3000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.620 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654465480, 998, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.622 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1648654485012, 615.7, 1, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartmeterReading) 2022-03-30 17:34:50.625 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654488487, 996, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.628 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654483480, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.637 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654482480, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.640 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654469479, 999, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.643 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654474480, 994, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.649 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654467480, 995, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.650 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654472479, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.653 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1648654470014, 610.5, 1, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartmeterReading) 2022-03-30 17:34:50.655 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654480480, 1002, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:50.658 - [31merror[39m: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654475488, 1007, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime) 2022-03-30 17:34:51.487 - [31merror[39m: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306 2022-03-30 17:34:52.486 - [31merror[39m: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306 2022-03-30 17:34:54.485 - [31merror[39m: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306 2022-03-30 17:34:56.482 - [31merror[39m: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306 2022-03-30 17:34:57.485 - [31merror[39m: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306 2022-03-30 17:34:58.488 - [31merror[39m: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306Es scheint also Probleme mit dem Datenpunkt "smartMeterSampleTime" zu geben. Der wird von einem Script etwa sekündlich erzeugt und läuft stabil durch. Also auch jetzt noch.
Im Errorlog von MariaDB selbst war da gar nichts zu sehen. Da sieht man nur den letzten Start
2022-03-28 8:05:24 0 [Note] InnoDB: Starting final batch to recover 540 pages from redo log. 2022-03-28 8:05:24 0 [Note] InnoDB: 128 rollback segments are active. 2022-03-28 8:05:24 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1" 2022-03-28 8:05:24 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2022-03-28 8:05:24 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2022-03-28 8:05:24 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2022-03-28 8:05:24 0 [Note] InnoDB: 10.7.3 started; log sequence number 32056487; transaction id 313154 2022-03-28 8:05:24 0 [Note] Plugin 'FEEDBACK' is disabled. 2022-03-28 8:05:24 0 [Note] InnoDB: Loading buffer pool(s) from F:\mariadb\data\ib_buffer_pool 2022-03-28 8:05:24 0 [Note] InnoDB: Buffer pool(s) load completed at 220328 8:05:24 2022-03-28 8:05:24 0 [Note] Server socket created on IP: '::'. 2022-03-28 8:05:24 0 [Note] Server socket created on IP: '0.0.0.0'. 2022-03-28 8:05:26 0 [Note] C:\Program Files\MariaDB 10.7\bin\mysqld.exe: ready for connections. Version: '10.7.3-MariaDB' socket: '' port: 3306 mariadb.org binary distribution -
@klassisch wenn es das
error.logist dann läuft aus dessen Sicht der dienst noch.ok Windows - Was sagt denn das Ereignisprotokoll? Auch Eventlog genannt, das von Windows selbst.
Es gibt einen Dienst für MariaDB, richtig? Der auf Automatisch steht. In den Erweiterten Einstellungen kann man dort setzen das er den Dienst bei einem Fehler wieder neu startet (was zwar die Symptome lindert habe den Grund nicht erklärt) -
@bananajoe Ja, vielen Dank, di Ereignisanzeige sagt was:
-
Fehler 17:34, MariaDB: InnoDB: Operating system error number 55 in a file operation.
-
Info 17:34 MariaDB: InnoDB: Some operating system error numbers are described at https://mariadb.com/kb/en/library/operating-system-error-codes/ . Der Link führt zu einer Website und dort steht unter 55:
"55 ENOANO No anode" . -
Fehler 17:34 MariaDB: InnoDB: File (unknown): 'flush' returned OS error 255. Cannot continue operation
-
Fehler 17:34 Application Error: Name der fehlerhaften Anwendung: mysqld.exe, Version: 10.7.3.0, Zeitstempel: 0x6205972c
- Name des fehlerhaften Moduls: server.dll, Version: 10.7.3.0, Zeitstempel: 0x62059706
- Ausnahmecode: 0x80000003
- Fehleroffset: 0x00000000003e8582
- ID des fehlerhaften Prozesses: 0x333c
- Startzeit der fehlerhaften Anwendung: 0x01d84269cde184f4
- Pfad der fehlerhaften Anwendung: C:\Program Files\MariaDB 10.7\bin\mysqld.exe
- Pfad des fehlerhaften Moduls: C:\Program Files\MariaDB 10.7\bin\server.dll
- Berichtskennung: fd3a5e4e-dbdb-4b02-ad2b-e68ce2eef71f
- Vollständiger Name des fehlerhaften Pakets:
- Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
-
17:34 Win Error Reporting
-
Fehlerbucket 1742235423834438271, Typ 4
-
Ereignisname: APPCRASH
-
Antwort: Nicht verfügbar
-
CAB-Datei-ID: 0
-
Problemsignatur:
-
P1: mysqld.exe
-
P2: 10.7.3.0
-
P3: 6205972c
-
P4: server.dll
-
P5: 10.7.3.0
-
P6: 62059706
-
P7: 80000003
-
P8: 00000000003e8582
-
P9:
-
P10:
-
Angefügte Dateien:
-
\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2CE7.tmp.dmp
-
\?\C:\ProgramData\Microsoft\Windows\WER\Temp
-
\WER2D94.tmp.WERInternalMetadata.xml
-
\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2DC4.tmp.xml
-
\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2DC2.tmp.csv
-
\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2E01.tmp.txt
-
Diese Dateien befinden sich möglicherweise hier:
-
\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive
-
\AppCrash_mysqld.exe_8bb04fadc453dbcb7177ab22926491040a8e4dc_48e38982_45e41aa6-c491-4535-8a75-0ed9d29c1cbe
-
Analysesymbol:
-
Es wird erneut nach einer Lösung gesucht: 0
-
Berichts-ID: fd3a5e4e-dbdb-4b02-ad2b-e68ce2eef71f
-
Berichtstatus: 268435456
-
Bucket mit Hash: 99f2dff1847fb019d82da9e320c0fa7f
-
CAB-Datei-Guid: 0
-
Die verlinkten Dateien sind entweder nicht (mehr) vorhanden oder access denied.
MariaDB scheint also Probleme mit dem Filesystem oder einem "Flush" zu haben.
Ich lege die Daten auf einer externen Platte ab, auf der ich auch die history Daten und andere Daten eines anderen Vielschreiber-Programms ablege.
Beim nächsten "Husten" versuche ich mal die Daten auf die Syste-SSD zu schreiben - was ich eigentlich vermeiden wollte.
Ich vermute mal - ohne eine wirkliche Ahnung zu haben - daß die Implementierung unter Windows nicht ganz so robust zu sein scheint. Wäre schade.
Edit: zu ENOANO findet man bei https://unix.stackexchange.com/questions/167368/what-is-enoano-no-anode-intended-to-be-used-for eine Antwort, bei der jemand richtig tief recherchiert hat.
Das scheint uralt zu sein, noch von Convergent/Burroughs Unix (CENTIX) stammend. Hat sich irgendwie durchgeschleppt, geriet aber in Vergessenheit
"So ENOANO probably indicated that either the kernel had run out of memory for inodes, or that the filesystem's inode table was full, in some commercial Unix in the 1980s. That Unix is now forgotten, its terminology is now forgotten, and due to some quirk the error code has stayed around."
-
-
@klassisch der Dienst läuft unter welchen Benutzer?
Und die Datenbank auf einer USB-Festplatte abzulegen ist denkbar doof (wenn ich das richtig verstanden habe)kein Zugriff ... es ist wichtig das der Benutzer unter dem MariaDB läuft zugriff hat. Wenn das SYSTEM ist sollte alles ok sein.
-
@bananajoe Vielen Dank!
Das sieht interessant aus:
Keine Ahnung wie das zustande kommt und ob/wie ich das ändern könnte.
Ja, SSD wäre blöd, deshalb ist das derzeit eine WD purple, die ohnehin 24/7 läuft, wofür sie auch ausgelegt ist.
Aber wegen der "Flush" Thematik hätte ich das halt probeweise auf die SSD gelegt bis das Problem behoben ist.
-
@klassisch ok, dann kannst du Prüfen ob der Benutzer
NT-SERVICE\MariaDBdie Rechte auf die Verzeichnisse hat (was er haben sollte) -
@bananajoe Vielen Dank! Auch mit Adminrechten angemeldet sehe ich diesen Benutzer leider nicht in der Benutzerverwaltung.
Prinzipiell darf Maria ja auf dieses Verzeichnis schreiben
Ich habe jetzt nochmals explizit für diesen Ordner eine Freigabe für den User MariDB erteilt. der User NT-SERVICE\MariaDB wurde abgelehnt, da nicht gefunden. MariaDB wurde akzeptiert und ist jetzt eingetragen. Mal sehen....
-
@klassisch ja, das sind diese neuen Spezialbenutzer für Dienste welche automatisch ihre Kennwörter ändern.
Sehr löblich das die das einsetzen, das gibt es auch schon seit vielen Jahren ... aber ich hatte mich noch nicht näher damit beschäftigt. Ich weis das die gibt. Das war es auch schon.Eigentlich sollte das Setup da alles selbst richtig machen.
Das Datenbankverzeichnis im Virenscanner ausklammern? -
@bananajoe Vielen Dank! Was es alles gibt. System vergibt und ändert selbst Passwörter.
Ich habe ja die Zugriffsrechte aufs Verzeichnis gewährt und warte ab.
Das mit dem Virenscanner mache ich als nächstes, wenn das Teil wieder stehen bleibt. Und das eigentlich eher ungern. Wäre ja schade, wenn eine Security Maßnahme dazu führen würde, daß eine fundamentalere ausgehebelt werden müßte. -
@klassisch Wenn nur das Verzeichnis mit den Datenbanken ausnehmen
-
Heute Mittag um 14:08:40 gab es einen interessanten Vorfall.
Anscheinend hatte die externe Platte, auf die noch andere Programme zugreifen, einen hickup.
History hat sich beschwert, daß er einige Dateien nicht lesen könne.
Und dann kam auch sql.
Während sich history aber wieder gefangen hat, war das bei der sql nicht der Fall. Den ganzen Nachmittag Fehlermeldungen. Ein Neustart des MariaDB Dienstes, der zwar noch lief sich aber nicht merh aus dem Fehlersumpf befreien konnte, half dann.Mein Fazit: Die MariaDB Implementierung unter Windows scheint nicht fehlertolerant ausgelegt zu sein. Einmal ein Problem mit dem (externen) Datenspeicher und es ist ein externer Eingriff erforderlich.
History ist da gutmütiger und robuster.
-
@klassisch du bist nicht ganz fair. In der Kombination hätte die Linux-Variante vermutlich genauso gezickt. Wer packt bitte schön auch eine Datenbank auf eine externe Festplatte ....
Stromsparmechanismen abgeschaltet? Falls das geht, externe Platten haben oftmals noch ihren eigenen Timer wenn nichts anderes greift.
Und die Windows Desktop Systeme sind da auch eifrig (während die Serversysteme ab 2016 mit Boardmitteln gar nicht mehr schlafen legen) -
@bananajoe Ich bin in der Beurteilung einfach nur pragmatisch.
History hat sich gefangen, MariaDB leider nicht.
Der Rechner (Laptop) hat leider nur eine SSD eingeaut. Darauf wollte ich die Datenbank nicht unbeding laufen lassen.
Die externe HD ist eine WD purple und läuft 24/7. Da wird ständig geschrieben, -auch von anderen Programmen - die geht nie schlafen. Und dafür ist die auch gebaut.
Über den Hickup bin ich nicht glücklich und ist mir bisher nicht so aufgefallen.
Wie gesagt, History hat das abgefangen.
Da eine Datenbank I/O als ein der Kernaufgaben hat, würde ich solche Robustheitsthemen bei Datenbanken erwartet. Aber ich bin kein Datenbank Experte. -
@klassisch sagte in Bewährte Histogrammfunktion?:
@bananajoe Ich bin in der Beurteilung einfach nur pragmatisch.
History hat sich gefangen, MariaDB leider nicht.
Der Rechner (Laptop) hat leider nur eine SSD eingeaut. Darauf wollte ich die Datenbank nicht unbeding laufen lassen.
Die externe HD ist eine WD purple und läuft 24/7. Da wird ständig geschrieben, -auch von anderen Programmen - die geht nie schlafen. Und dafür ist die auch gebaut.
Über den Hickup bin ich nicht glücklich und ist mir bisher nicht so aufgefallen.
Wie gesagt, History hat das abgefangen.
Da eine Datenbank I/O als ein der Kernaufgaben hat, würde ich solche Robustheitsthemen bei Datenbanken erwartet. Aber ich bin kein Datenbank Experte.- ist gerade die SSD super für Datenbanken geeignet, allein auf Grund der Zugriffszeiten.
- und dann kommt die Datenbank (oder der SQL-Adapter?) nicht aus dem Tritt. Das der Datenträger mal nicht da ist/richtig reagiert ist bei Datenbanken nicht vorgesehen. Die speichern ja etwas komplizierter (erst ins Log, dann in die Datenbank) und macht auch erst weiter wenn das Betriebssystem das Schreiben bestätigt hat (für jeden Schreibzugriff also mindestens 2 mal) damit diese Transaktion immer gültig / valide ist. Denn die Validität / Verlässlichkeit / ein konsistenter Zustand ist nun mal das wichtigste an einer Datenbank. Du hast da nur ein paar "poplige" Werte von 4 duzend Datenpunkten drin, ich habe Kunden mit mehrere hundert Gigabyte großen MariaDB / MySQL Datenbanken, da muss das einfach passen. Und dann kann das System halt nicht einfach "Robustheit" demonstrieren, das Problem ignorieren und weitermachen. Jedenfalls nicht wenn es um das Schreiben von Daten geht.
- Und der History-Adapter hat nichts abfangen. Denn der History-Adapter ist ja auch keine Datenbank sondern - Apollon77 möge mir diese vereinfachung verzeihen - etwas JavaScript was die Zustände in Text- und/oder Binärdateien speichert. Als ob du in deiner Textverarbeitung ein Dokument offen hast und es regelmäßig speicherst. Klar ist das "robuster" was Ausfälle/Verzögerungen des Datenträgers angeht weil diesem System es eigentlich ja auch ziemlich egal ist. Dann wartet es halt 10 Minuten wenn das schreiben so lange dauert. So etwas geht aber auch gerne kaputten wenn während des Schreibens der Strom ausfällt (Siehe die ganzen Raspberry Pi Post wo das System nach einem Stromausfall nicht mehr startet). Im kleinen geht das, es ist aber vermessen das mit einer Datenbank vom Kaliber MySQL/MariaDB zu vergleichen und es als "robuster" zu bezeichnen.
Zu "die geht nie schlafen" - was steht des zum Zeitpunkt des Schluckaufs im Ereignisprotokoll (System / Applikationen)
Das ist USB, da ist mehr als die Platte beteiligt, auch andere USB-Geräte , USB Hub (kann auch interner sein) oder etwas auf dem USB-Bus wurde initialisiert.So, ganz viel Text. Mein Technikerherz hat sich - wie ich zugeben muss - halt darüber aufgeregt das der Software vorgeworfen wird, nicht wieder in den tritt zukommen wenn es ein anderes Problem von außen gab.
Ich bin IT-Consultant und habe beruflich viel mit hochverfügbaren System zu tun. Und ich kann dir sagen das fast alle professionellen IT-Systeme im Zweifel ganz aussteigen wenn die Gefahr besteht das Daten nicht valide sind. Datenbanken stoppen, Dienste beenden sich, Speichersysteme sperren den (Schreib-)Zugriff, Server gehen in den Blue-/Purple- oder Green-Screen. Immer damit sich das ein Mensch das ansieht und entscheidet wie es weiter gehen soll. Meine Aufgabe ist oft das so etwas nicht passiert bzw. ein Ersatzsystem einspringt - oder das zumindest innerhalb kürzester Zeit benachrichtigt wird. -
@bananajoe Vielen Dank für die Erläuterungen.
Ich bin ja IT-Laie und hatte ein anderes Verständnis von Hochverfügbarkeit.
Ich mache seit 30 Jahren viel mit Safety und das geht tatsächlich oft zu Lasten der Verfügbarkeit, weil der sichere Zustand entsprechend definiert ist.
Deshalb dachte ich, daß bei Hochverfügbarkeitssystemen die Redundanz zugunsten der Verfügbarkeit genutzt wird.Ich werde mal versuchen, die MariaDB (für mich Laie halt eine Diva) auf die SSD zu legen. Bin ja noch immer im Testbetrieb, um genau solche Sachen zu lernen.
Die Ereignisanzeige sagt:
Keine Ahnung, was da war. Aber an den USBs hängt einiges. 2 Platten, Drucker.
-
Da kommt man sich so richtig blöd vor. Ich finde keine Möglichkeit, den Speicherort der Datenbank festzulegen.
Habe gelesen, man könne da in my.in oder my.cnf. Alles das scheint es bei mir nicht zu geben.
Heidi hilft leider auch nicht weiter. -
@klassisch laut google klingt das nun nicht so schwer ...
https://www.techbrothersit.com/2017/12/how-to-change-mariadb-data-directory-on.htmlBei mir unter Linux steht es in der
/etc/mysql/mariadb.conf.d/50-server.cnfin meiner `my.cnf' wird auf das Verzeichnis verweisen (so das alle Dateien dort includiert werden),
dort gibt es einen Abschnitt wie folgt:[mysqld] # # * Basic Settings # user = mysql pid-file = /run/mysqld/mysqld.pid socket = /run/mysqld/mysqld.sock #port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysqldatadirklingt doch recht eindeutig ...Die Daten können auch in der
my.cnfstehen
Alternativ wäre MariaDB beim starten diese Angaben als Parameter mitzugeben, dann müsste es im Dienst zu sehen sein und könnte in der Registry geändert werden. Wahrscheinlich steht da abe rnur der Verweis auf die Konfigurationsdatei(en) -
@bananajoe sagte in Bewährte Histogrammfunktion?:
Alternativ wäre MariaDB beim starten diese Angaben als Parameter mitzugeben, dann müsste es im Dienst zu sehen sein und könnte in der Registry geändert werden. Wahrscheinlich steht da abe rnur der Verweis auf die Konfigurationsdatei(en)
Vielen Dank! So irgendwie muß das sein.
Habe im MariaDB Verzeichnis nichts in Richtung *.cnf , *.cfg , .conf gefunden.
Auch nicht unter users.
Mal schauen, ob ich in der registry etwas finde, auch wenn ich mich dort nicht wirklich auskenne.
