Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[BananaJoe]

@klassisch wenn es das error.log ist 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)

[klassisch]

@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."

[BananaJoe]

@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.

[klassisch]

@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.

[BananaJoe]

@klassisch ok, dann kannst du Prüfen ob der Benutzer NT-SERVICE\MariaDB die Rechte auf die Verzeichnisse hat (was er haben sollte)

[klassisch]

@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....

[BananaJoe]

@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?

[klassisch]

@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.

[BananaJoe]

@klassisch Wenn nur das Verzeichnis mit den Datenbanken ausnehmen

[klassisch]

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.

[BananaJoe]

@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)

[klassisch]

@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.

[BananaJoe]

@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.

1. ist gerade die SSD super für Datenbanken geeignet, allein auf Grund der Zugriffszeiten.
2. 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.
3. 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.

[klassisch]

@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:

Spoiler

Der E/A-Vorgang an der logischen Blockadresse "0x130f15978" für den Datenträger "2" (PDO-Name: \Device\00000080) wurde wiederholt.


{Fehler beim verzögerten Schreibvorgang} Nicht alle Daten für Datei "F:\$Mft" wurden gespeichert. Die Daten gingen verloren. Mögliche Ursachen sind Fehler bei der Computerhardware oder bei der Netzwerkverbindung. Versuchen Sie, die Datei woanders zu speichern.

Bei einem Auslagerungsvorgang wurde ein Fehler festgestellt. Betroffen ist Gerät \Device\Harddisk2\DR2.

Die Daten konnten nicht in das Transaktionsprotokoll verschoben werden. Die Daten sind möglicherweise beschädigt: Volume-ID: F:, Gerätename: \Device\HarddiskVolume7.

           Fehlerstatus: Ein nicht vorhandenes Gerät wurde angegeben.

           Geräte-GUID: {bd0b7f69-f71c-3fad-2eb4-c5303153de8c}
           Gerätehersteller: TO Exter
           Gerätemodell: nal USB 3.0     
           Geräterevision: 0104
           Seriennummer des Geräts: 2015033100081
           Bustyp: USB

           Seriennummer des Adapters: 


Die Daten konnten nicht in das Transaktionsprotokoll verschoben werden. Die Daten sind möglicherweise beschädigt: Volume-ID: F:, Gerätename: \Device\HarddiskVolume7.

           Fehlerstatus: Ein nicht vorhandenes Gerät wurde angegeben.

           Geräte-GUID: {bd0b7f69-f71c-3fad-2eb4-c5303153de8c}
           Gerätehersteller: TO Exter
           Gerätemodell: nal USB 3.0     
           Geräterevision: 0104
           Seriennummer des Geräts: 2015033100081
           Bustyp: USB

           Seriennummer des Adapters: 


System call failed: WinUsb_ControlTransfer: 433.

{Fehler beim verzögerten Schreibvorgang} Nicht alle Daten für Datei "" wurden gespeichert. Die Daten gingen verloren. Mögliche Ursachen sind Fehler bei der Computerhardware oder bei der Netzwerkverbindung. Versuchen Sie, die Datei woanders zu speichern.

System call failed: WinUsb_ControlTransfer: 433.

Die Qualitätssicherungsüberprüfung für Fingereingabe-/Touchpad-Hardware wurde erfolgreich abgeschlossen.


Dienst "MariaDB" wurde unerwartet beendet. Dies ist bereits 2 Mal passiert.

Volume "F:" (\Device\HarddiskVolume12) ist fehlerfrei. Es ist keine Aktion erforderlich.

Keine Ahnung, was da war. Aber an den USBs hängt einiges. 2 Platten, Drucker.

[klassisch]

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.

[BananaJoe]

@klassisch laut google klingt das nun nicht so schwer ...
https://www.techbrothersit.com/2017/12/how-to-change-mariadb-data-directory-on.html

Bei mir unter Linux steht es in der

/etc/mysql/mariadb.conf.d/50-server.cnf

in 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/mysql

datadirklingt doch recht eindeutig ...

Die Daten können auch in der my.cnf stehen
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)

[klassisch]

@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.

[klassisch]

Das könnte damit zusammenhängen

Das heißt, das my.ini file steht im Datenverzeichnis.

Dort steht dann

[mysqld]
datadir=F:/mariadb/data
port=3306
innodb_buffer_pool_size=942M
[client]
port=3306
plugin-dir=C:\Program Files\MariaDB 10.7/lib/plugin

D.h. ich müßte dann den regedit Eintrag umbiegen auf das neue Datenverzeichnis und dort dann in der my.ini ebenfalls das neue Datenverzeichnis benennen.

Iregndwie doppelt, weil die ini im Datenverzeichnis und nicht beim Programm steht.

[klassisch]

@BananaJoe vielen Dank, Bin wieder im Testbetrieb.
Habe die my.ini auf dem neuen Laufwerk geändert und auch die registry editiert.
Danke für Deine geduldieg und ausdauernde Hilfe. Ich hätte nicht erwartet, daß ein Linuxprogramm solche Infos in der Win registry hinterlegt.
Jetzt beobachte ich weiter.
Ich habe ja keinen Zeitdruck, aber um das Thema Datenbank werde ich auf kurz oder lang nicht drumrumkommen. Also langsam "ranpirschen".

[klassisch]

So immerhin schon 3 Tage durchgelaufen ohne Probleme.
Mein Vetrauen wächst.
Also zurück zur Ausgangsfrage: Wie kann man jetzt aus den Daten Histogramme ableiten?
Nehme an, daß man dazu eine Datenbankabfrage vornimmt, wodurch dann die Histrogramme während der Abfrage berechnet werden.
Habe bisher noch keine Erfahrung mit solchen Abfragen und den mutmaßlich dafür genutzten "Sprachen".
Gibt es ein bewährtes und kompaktes Tutorial mit Beispielen an denen man sich orientieren udn entlanghangeln kann?