influxdb 3.0.0 verfügbar - eine Zusammenfassung
-
@apollon77 Dauert noch ein paar Monate bis die 2 Jahre bei den ältesten Werten erreicht sind. Dann sehe ich ob Einstellung 5 Jahre greift.
In Adapter v2.6.3 hatte ich bereits die Standard Entprellzeit auf 1000 ms gesetzt. Nach dem Update auf v3 steht dort aber eine 0. Hätte der alte Wert nicht übernommen werden sollen?
Und die damalige Entprellzeit pro Objekt ist nun neu die Blockzeit. Das ist so richtig?
-
@diginix Naja, liess mal oben ganz genau ... In der alten war es als "Blockzeit" implementiert ... daher ist mit dem Update die 1000 auch ins neue Feld "Blocktime" gewandert und Entprellzeit ist 0
-
@diginix Auf GitHub sollte die UI für alle Fälle korrigiert sein
-
@stephan61 GitHub Versio sollte es behoben haben. Falls Du testen willst nach GitHub install bitte manuell Adapter neu starten
-
@apollon77 sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:
@diginix Auf GitHub sollte die UI für alle Fälle korrigiert sein
Bisher sehe ich die Checkbox wenn ich die Instanzeinstellungen öffne und auch wenn ich dann zB 2000 Tage statt 1825 eintrage, bleibt die Checkbox und ich kann ohne nicht speichern.
-
@diginix Mist ... einen Fall hab ich natürlich vergessen
Jetzt aber hoffentlich
-
@apollon77 Passt nun.
-
@diginix party :-))) Danke!
-
@apollon77
mit der github version werden die Werte wieder angezeigt . DankeGruß Stephan
-
Hallo,
eine Verständnisfrage. Die Aufbewahrungszeit, liese die sich auch pro Datenpunkt einstellen oder geht das bei InfluxDB nur generell, also Adapterweit? Der Hintergrund der Frage ist der, dass ich Datenpunkte habe, wo ich alle Infos ohne Löschung aufzeichne und andere, wo nur ein paar Wochen reichen würden.
-
@palm_maniac Geht nur pro DB.
-
@diginix Ok, danke. Schade.
-
@palm_maniac Bist jetzt gefühlt der 5. der das fragt. Legt halt ein GitHub Ossue als Feature Request an ... kann man halt nur manuell machen. Muss mal lesen ob InfluxDB sowas mag oder überhaupt erlaubt
-
Hallo,
bei mir häufen sich in der letzten Zeit diese Fehler:
influxdb.0 2022-05-18 10:16:55.037 warn Error in query "import "influxdata/influxdb/schema" schema.tagKeys(bucket: "iobroker")": RequestTimedOutError: Request timed outDie treten jeden Morgen auf, gefolgt von mehreren Einträgen pro Datenpunkt im Log, was dazu führt dass es mehrere Gigabyte an Größe zulegt. Helfen tut hier nur ein Neustart des InfluxDB Service oder des LXC-Containers, in dem nur Influx läuft. Das Problem habe ich seit einiger Zeit und weiß langsam nicht mehr wo ich suchen soll. Vielleicht hat hier jemand eine Idee.
Im LXC ist Ubuntu 21.11 als Grundsystem installiert mit InfluxDB V2.2.
Ich frage auch deshalb hier, weil sich das Problem gefühlt mit meinen Tests mit der Adapterversion 3.0 eingestellt hat. Leider scheint es aber wohl nur ein Gefühl zu sein, denn der Fehler tritt jetzt auch mit der V2.6.3 auf, da aber bei weitem nicht so oft.
-
@palm_maniac Request "timeout" deutet an sich darauf hin das die InfluxDB selbst irgendwas hat bzw die Query länger dauert als der aktuelle Timeout. Den Request Timeout kannst Du hochsetzen in der Konfig ... vllt mal erhöhen?
Auch die Frage ist wo die Meldung herkommt schema.tagKeys gibts in den queries nicht ... machst Du custom Queries?
-
@apollon77 Ich habe vor einiger Zeit nach Anleitung von V1.8 auf V2 gewechselt und die Datenbanken konvertiert. es sind also keine reinen frischen V2 Datenbanken. Vielleicht liegt es daran? Aber das hat bis vor kurzem nie Probleme bereitet.
-
@palm_maniac Keine Ahnung. ich bin selbst noch auf InfluxDB 1.8 und scheue mich vor den mega GB der migration :-)))
-
@apollon77 dito
-
@apollon77 Wie entwickelst du dann den Adapter für influxDB v2? Testsystem mit Dummy Daten?
Hab bisher gedacht ich wäre allein mit v1.8 und sollte es mal angehen. Aber wenn das nicht einfach nur ein Update Kommando ist sondern mit mehr Aufwand verbunden ist, dann sitze ich das noch eine Weile aus.
Was hätte man mit v2 für Vorteile und gibt es auch Nachteile?
-
@diginix sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:
@apollon77 Wie entwickelst du dann den Adapter für influxDB v2? Testsystem mit Dummy Daten?
@diginix Die 2.0 Implementierung hat primär @Excodibur gebaut und der hatte da dann installiert. Ich hab auch irgendwo für sondertests ne mini influxdb in nem container laufen ... Ansonst habe ich einige Stunden gebastelt um bei den GitHub Actions wo alle Tests bei GitHub ausgeführt werden sowohl eine InfluxDB 1 wie auch eine InfluxDB 2 zu installieren und dann mit testdaten zu füttern und damit ie Tests laufen zu lassen ... https://github.com/ioBroker/ioBroker.influxdb/actions/runs/2337929675
Damit geht das meiste recht gut.
Das immer ein problem ist sind "Massendaten tests" weil die nahezu unmöglich sind zu stellen es sei denn man hat wirklich ein größ0eres System was Daten einliefert.
Hab bisher gedacht ich wäre allein mit v1.8 und sollte es mal angehen. Aber wenn das nicht einfach nur ein Update Kommando ist sondern mit mehr Aufwand verbunden ist, dann sitze ich das noch eine Weile aus.
Upgrade ist quasi ein Datenexport aus der 1.x und Import in die 2.x weil die Strukturen inkompatibel sind. In irgend einem Thread hier im Forum gabs das Thema schonmal auch mit den Befehlen und so.
Wenn ich es mal mache ist meine Idee:
- Adapter umstellen auf Influxdb 2 und damit gehen alle neuen Daten da rein
- Dann entweder die alten Daten Monatsweise oder so exportieren und dann die Exports Files durch die gegend schieben und einzeln importieren ODER irgendwie ein großes Dir per nfs von meiner NAS mounten und alles exportieren ... Ich glaube wir waren mal bei export faktor 10 oder größer oder sowas ... ich habe 41GB Roh-Daten angesammelt gg So arg will ich die VM nicht aufblasen
Und ich brauch noch ne Lösung für collectd weil die InfluxDB 2 das nicht mehr von hause aus kann sondern nur über umwege
Und um das alles rauszufinden fehlt mir gerade Zeit und Muse
Was hätte man mit v2 für Vorteile und gibt es auch Nachteile?
Im zweifel: 1.x ist EOL denke ich und kriegt keine Updates mehr .... 2.x ist halt aktuell und bekommt Updates und neue Features udn hat ne neue Abfragesprache mit mehr möglichkeiten
