Bewährte Histogrammfunktion?
-
@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. -
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/pluginD.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.
-
@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". -
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? -
@klassisch also ich nutze den eCharts Adapter. Der findet selbst alle Datenpunkte bei denen eingestellt wurde das Daten aufgezeichnet werden sollen, egal ob über History, SQL oder anderes.
In der Konfiguration von eCharts kann ich dann diese Datenpunkte als Quelle auswählen und mit mein passendes Diagramm zusammen bauen, ggf. aus mehreren Datenpunkten.
In die VIS bekommt man es über das zughörige Widget.
Vorher hatte ich Float genutzt, das funktioniert sinngemäß genauso. -
@bananajoe Vielen Dank, ich nutze noch Flot und kann Daten von History und MariaDB plotten.
Meine Frage geht jetzt in die Richtung:
- Ich habe Daten in ihrer zeitlichen Abfolge
- Aus diesem Zeitverlauf möchte ich nachträglich weitere Auswertungen fahren, wie z.B. ein Häufigkeitshistogramm erstellen. In Flot habe ich dazu keine Funktion gefunden und dachte jetzt, daß eine Datenbank das leisten kann.
-
@klassisch Wenn du dir die Anleitung des SQL-Adapters anschaust siehts du dort wie man eigene Abfragen machen kann.
Eine Auswertung wäre ja ein SQL-Statement / - AbfrageWas genau willst du "Auswerten"?
-
@bananajoe sagte in Bewährte Histogrammfunktion?:
@klassisch Wenn du dir die Anleitung des SQL-Adapters anschaust siehts du dort wie man eigene Abfragen machen kann.
Vielen Dank, das werde ich mir anschauen
Eine Auswertung wäre ja ein SQL-Statement / - Abfrage
Das war meine Vermutung
Was genau willst du "Auswerten"?
Ich will wissen wie häufig die aufgezeichneten Werte in entsprechenden Wertebereichen liegen. Also ein einfaches Histogramm aus aufgezeichneten Daten generieren.
