[gelöst] InfluxDB 2: Welcher Wert müllt die DB voll?
-
@iobroker2001 sagte in InfluxDB 2: Welcher Wert müllt die DB voll?:
Einige Tagen wurden schon gelöscht, dann werde ich mal das Backup wieder einspielen...
Moin,
gut, dass Du ein Backup hast, denn das wäre ja nicht so schön, wenn Dir Daten flöten gehen.
Das ist der Grund warum ich mit mehreren
Organisationenarbeite, so hat jede Organisation nur sein Bucket
Beim Strom sind es zwei Buckets, einmal alles und einmal aggregiert auf einen Tag
Hier nur mal nur zum Testen und für Spielereien, hier fürs Forum
VG
Bernd -
@dp20eic Habe mit BackItUp meine iobroker-InfluxDB-Datensicherung "Backupdatei wiederherstellen" eingespielt, ging ruckzuck, aber Daten vor 7 Tagen sind trotzdem weg!
Bucket iobroker steht auf "Retention: Forever", nur influx-statistikdaten wie geplant auf 7 Tage.
Backup noch einmal eingespielt, während Backup Log:Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [DEBUG] [influxDB] - influxdb.0 is stopped [ERROR] [influxDB] - 2023/04/07 18:23:53 INFO: Restoring bucket "420ba78195c86dab" as "iobroker" Error: failed to restore bucket "iobroker": 422 Unprocessable Entity: bucket with name iobroker already exists [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done [DEBUG] [influxDB] - influxdb.0 started -
@iobroker2001
Oh, jetzt war ich mal ein paar Stunden im Garten, und du löschst alle Daten
Mal 'ne blöde Frage: was ist eigentlich das Bucket "influx-statistikdaten"? Wurde das manuell angelegt?
-
@marc-berg Das ist das 1. Bucket, welches InfluxDB anlegt. Das habe ich dann wohl umbenannt.
Ich hatte damals gehört, dass es besser sei, für die reinen ioBroker-Daten ein eigenes Bucket anzulegen, damit das Backup nicht so groß würde. Das ist das Bucket iobroker. -
@iobroker2001 sagte in InfluxDB 2: Welcher Wert müllt die DB voll?:
@dp20eic Habe mit BackItUp meine iobroker-InfluxDB-Datensicherung "Backupdatei wiederherstellen" eingespielt, ging ruckzuck, aber Daten vor 7 Tagen sind trotzdem weg!
Bucket iobroker steht auf "Retention: Forever", nur influx-statistikdaten wie geplant auf 7 Tage.
Backup noch einmal eingespielt, während Backup Log:Error: failed to restore bucket "iobroker": 422 Unprocessable Entity: bucket with name iobroker already existsDas Bucket darf vor dem Restore nicht existieren, oder du hakst in der Backitup Instanz folgendes an:
-
@marc-berg Habe den Haken gesetzt, beim Restore kommt identische Meldung, aber auch die gute Bestätigung wie beim 1. Mal, s. auch oben!
[DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done [DEBUG] [influxDB] - influxdb.0 startedDas Restore scheint also funktioniert zu haben, aber nicht den gewünschten Effekt zu haben. Habe Raspi schon neu gestartet. Den Bucket "influx-statistikdaten" versuche ich testweise, wieder auf ewig zu setzen, wird zwar mit OK-Meldung ("was successfully updated") quittiert, aber Anzeige bleibt auf 7 Tage, auch nach Neustart. Grrrr..
Im influx-statistikdaten finde ich Einträge wie boltdb_reads_total, go_memstats...., service_ etc.
-
@iobroker2001
Alles etwas seltsam. Was heißt denn konkret "Das Restore scheint also funktioniert zu haben, aber nicht den gewünschten Effekt zu haben." -
@marc-berg Ich meine damit, BackItUp meint, Restore wäre ok gewesen...;-)
-
@iobroker2001
Sind jetzt gar keine Daten mehr da, oder wie? -
@marc-berg Es sind nur noch die Daten der letzten 7 Tage da.
-
@iobroker2001
Ok, dann schau mal in deine Influxdb-Instanz:
-
@marc-berg Sieht bei mir genauso aus:
-
Dann bin ich jetzt auch ratlos. Irgendwo scheint ja die Retention Time von 7 Tagen gespeichert zu sein. Ich würde mich jetzt durchprobieren: Influxdb-Instanzen stoppen, das Bucket über die InfluxDb Web UI löschen und das Restore über die Kommandozeile machen. Ist zwar alles nicht logisch, aber eine andere Idee habe ich im Moment nicht.
-
@marc-berg Ich glaube, ich muss mich von den Daten verabschieden - sie haben sich ja selbst schon von mir verabschiedet
Ausgerechnet dieses Mal hatte ich kein SD-Karten-Image-Backup gemacht...
Ich werde am Wochenende Deinen Vorschlag mal probieren.Wie auch immer:
@marc-berg VIELEN VIELEN DANK!!!!
@dp20eic VIELEN VIELEN DANK!!!!
Wünsche Euch frohe Ostern!!
-
@iobroker2001 sagte in InfluxDB 2: Welcher Wert müllt die DB voll?:
@marc-berg Ich glaube, ich muss mich von den Daten verabschieden - sie haben sich ja selbst schon von mir verabschiedet
Ausgerechnet dieses Mal hatte ich kein SD-Karten-Image-Backup gemacht...
Ich werde am Wochenende Deinen Vorschlag mal probieren.Wie auch immer:
@marc-berg VIELEN VIELEN DANK!!!!
@dp20eic VIELEN VIELEN DANK!!!!
Wünsche Euch frohe Ostern!!
Moin,
ich glaube da ist das Restore nicht korrekt gelaufen und Du siehst immer noch das Bucket, als Du es versehentlich auf 7 Tage eingestellt hast.
Geh mal in die WEB UI voninfluxDBund benenne dasiobrokerBucket um iniobroker_oldoder so und versuch es dann noch mal mit dem Restore.Es ist immer besser, wenn Du Log Files immer komplett postest, war den der Delete erfolgreich?
VG
Bernd -
@dp20eic
ich glaube da ist das Restore nicht korrekt gelaufen und Du siehst immer noch das Bucket, als Du es versehentlich auf 7 Tage eingestellt hast.
Geh mal in die WEB UI voninfluxDBund benenne dasiobrokerBucket um iniobroker_oldoder so und versuch es dann noch mal mit dem Restore.Hallo Bernd,
schön, dass Du Dich trotz meiner Resignation noch gemeldet hast, und es hat sich gelohnt!!
Habe Deine Anweisungen befolgt, es hat geklappt, ich habe meine Daten wieder!
Das Restore von iobroker hat dann geklappt, es lag daran, dass es den Bucket schon gab.
Erschwerend kam noch hinzu, dass es per Web-UI auf Github schon als Bug vermerkt ist, dass das Ändern der Retention-Zeit manchmal nicht klappt. Per CLI funktionierte es dann auch.
Die DB ist jetzt wesentlich kleiner:sudo du -s /var/lib/influxdb/engine/data 1158868 /var/lib/influxdb/engine/dataMal sehen, wie sie sich jetzt entwickelt.
Auf jeden Fall hat das Happy-End mein Vertrauen in die InfluxDB wieder gestärkt.Danke noch einmal, Dir und Marc-Berg wünsche ich Frohe Ostern!
-
@marc-berg sagte in [gelöst] InfluxDB 2: Welcher Wert müllt die DB voll?:
@iobroker2001
Unter dem /data -Verzeichnis liegen ja die einzelnen Buckets. Was möglich sein KÖNNTE, dass das "Monitoring" Bucket sehr viele Daten enthält.
Die ID des Buckets findet sich unter dem /data Verzeichnis wieder. Ggf. lohnt es sich, die Verzeichnisse noch einzeln mit "du" auszuwerten.
Hier hab ich mal ne Frage.
Der Ordner data\6228c6c48973b58d\autogen war bei mir auch mal auf 27 GB angewachsen.
Wenn ich mir den Inhalt von Data ansehe:
passt das nicht ganz zu meinen Buckets.
Ich finde meine ioBroker DB und _monitoring als Ordner wieder.
Für _tasks habe ich keinen Ordner in /data aber das eigentliche Problem ist dass ich für den Ordner 6228c6c48973b58d der Speicher frisst keine DB habe.
Wie ist denn da der Zusammenhang oder was frisst hier meinen Speicher? -
@rushmed sagte in [gelöst] InfluxDB 2: Welcher Wert müllt die DB voll?:
Wie ist denn da der Zusammenhang oder was frisst hier meinen Speicher?
Mit den Informationen schwer zu sagen. Vielleicht gibt es bei Dir mehr als eine Organisation? Sind die Daten in dem Verzeichnis aktuell oder vielleicht ein Überbleibsel einer älteren Installation?
-
@marc-berg Es gibt keine weitere Organisation und die Installation war damals frisch als ich auf 64 Bit gewechselt bin.
In dem Ordner werden auch immernoch Daten geschrieben. -
@rushmed sagte in [gelöst] InfluxDB 2: Welcher Wert müllt die DB voll?:
@marc-berg Es gibt keine weitere Organisation und die Installation war damals frisch als ich auf 64 Bit gewechselt bin.
In dem Ordner werden auch immernoch Daten geschrieben.Das ist seltsam, denn selbst in der offiziellen Doku steht, dass die Unterverzeichnisse nach den Bucket-IDs benannt werden.
Aber schau mal hier: https://community.influxdata.com/t/hidden-bucket-occupying-a-lot-of-disk-size/26837
Also einfach mal prüfen, ob irgendwelche Tasks/Scrapers eingerichtet sind.
