NEWS
Problems using influxDB on an external SSD
-
Das mouten passiert durch "/etc/fstab" und dem Eintrag:
"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw 0 2"
-
@crunchip
Die Platte ist normal ansprechbar. Ich kann dort Dateien schreiben und lesen.Nachdem ich Datenbank von influxDB von der Sicherungskopie, die auch auf der externen Platte liegt, wieder hergestellt habe, läuft das Logging auch auf der externen Platte ohne Probleme.
Jedoch sobald ich das System neu starte mit "sudo reboot" ist wieder alles kaputt und ich muss wieder alles kompliziert herstellen. Also zuerst alle Systeme deaktivieren, dann die DB löschen, aus dem BackUp wieder herstellen und wieder alles neu starten...
Schlimm ist wenn das System aus anderen Gründen neu startet, ich kein aktuelles BackUp habe,... jedes Mal Daten Verlust...
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
nofail,rw
Das sind zu wenig Optionen.
Ich würde da wenigstens 'defaults' noch setzen, besser noch den richtigen User, der drauf schreiben soll. -
@thomas-braun
Der Kommentar von Meister Mopper am 24 Mar 2022, 17:29 fand ich interessant.
Aber so wie er geschrieben war konnte ich ihn nicht umsetzten und ich hatte Angst, dass wenn ich etwas falsch mache, ich das komplette System zerstöre.Ich kann mir folgendes vorstellen:
1.) dass das System hochfährt, die Platte erst nach dem Start von influxDB verbunden wird und sie deshalb an einer anderen Stelle etwas schreibt.
2.) dass nach dem Neustart die Zugriffsrechte der Platte nicht richtig sind (diese muss ich nach dem Löschen und wieder herstellen manuell setzten) und deshalb influxDB den Fehler macht.Oder natürlich etwas anderes. Aber wie ich das rausfinden und beheben kann, weiß ich leider nicht.
Ich unterstütze gerne mit Logs und freue mich über alle Tipps. Danke
-
@thomas-braun
Das hört sich nach meiner "Option 2" an. Kennst du dich da besser aus? Wie kann ich das Mouten "optimal" einstellen?- Also lange genug warten, dass infuxDB auf jeden Fall nach dem Mounten startet. Aber falls die Platte defekt ist, trotzdem nicht endlos hängen bleiben.
- InfluxDB oder besser alle Benutzer vollen schreibe und Lese Zugriffe haben
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
1.) dass das System hochfährt, die Platte erst nach dem Start von influxDB verbunden wird und sie deshalb an einer anderen Stelle etwas schreibt.
Die Reihenfolge wie Dienste gestartet werden kann man in systemd sehr genau definieren. Das mounten der Dateisysteme (per fstab) geschieht allerdings recht früh, das wird vermutlich nicht ursächlich sein.
-
@thomas-braun
Und wie stelle ich die Zugriffsrechte richtig ein? -
Schau in die man-page:
https://linux.die.net/man/8/mount
Da stehen alle Optionen für die einzelnen Dateisysteme drin.
-
Ist es ausreichend, wenn ich an meinen mount Befehl "users" anhänge?
"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw,users 0 2"
Oder wie stelle ich ein, dass jeder volle Zugriffsrechte auf die Platte hat?
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
Ist es ausreichend, wenn ich an meinen mount Befehl "users" anhänge?
Nein, lt. man page beschreibt das nur, dass jeder user das Dateisystem mounten darf.
Die Rechte ergeben sich aus den Rechten des mount-Punktes.Man kann nach dem mounten z. B. so in der Art die Rechte vergeben:
sudo chown -R UserNameOfSudo:users /media/data sudo chmod -R g+rw /media/data
-
@thomas-braun said in Problems using influxDB on an external SSD:
sudo chown -R UserNameOfSudo:users /media/data sudo chmod -R g+rw /media/data
Aber das kann ich dann nicht in "/etc/fstab" reinschreiben. Ich müsste es in einen Chronjob nach dem Start? Oder wie lege ich das fest? Ist das dann nicht wieder zu spät, also erst nachdem schon influxDB gestartet ist?
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
/media/data
Wie sehen die Rechte an /media/data aus, wenn das Dateisystem nicht gemounted ist?
-
@thomas-braun
Hast du mir nen Befehl, mit dem ich dir das rausfinden kann? Sorry. Bin nicht so fit mit Unix. -
ls -la /media/mySSD
-
pi@ioBroker:~ $ ls -la /mnt/mySSD insgesamt 628 drwxr-xr-x 5 root root 4096 Okt 1 2021 . drwxrwxrwx 3 root root 4096 Sep 23 2021 .. drwxrwxrwx 2 root root 614400 Apr 12 02:00 Influx-BackUp drwxrwxrwx 5 root root 4096 Okt 1 2021 InfluxDB drwx------ 2 root root 16384 Sep 28 2021 lost+found
-
Und das Dateisystem ist nicht gemounted?
Dann muss der Mountpunkt leer sein. -
@thomas-braun
Wie meinst du, dass das Dateisystem nicht gemountet ist??
An was siehst du das? -
@mathias2803 sagte in Problems using influxDB on an external SSD:
An was siehst du das?
eben nicht, das war Bedingung:
@thomas-braun sagte in Problems using influxDB on an external SSD:
Wie sehen die Rechte an /media/data aus, wenn das Dateisystem nicht gemounted ist?
deswegen die Nachfrage
-
Das Verzeichnis media/data gibt es gar nicht. Woher kommt das und warum?
pi@ioBroker:~ $ sudo ls -la /media/data ls: Zugriff auf '/media/data' nicht möglich: Datei oder Verzeichnis nicht gefunden
-
In der influxdb.conf taucht auch keine "media/data" auf sondern nur folgende Einstellungen:
[meta] dir = "/mnt/mySSD/InfluxDB/meta" [data] dir = "/mnt/mySSD/InfluxDB/data" wal-dir = "/mnt/mySSD/InfluxDB/wal" series-id-set-cache-size = 100 [http] enabled = true bind-address = ":8086" auth-enabled = false log-enabled = true write-tracing = false pprof-enabled = false https-enabled = false https-certificate = "/etc/ssl/influxdb.pem"
Alles andere sind nur Kommentare.