influxdb 3.0.0 verfügbar - eine Zusammenfassung

[Diginix]

@apollon77 Vielen Dank die ausführlichen Infos!

Da sollte sich meine DB mit nur 586 MB ja ggf. in einem Rutsch migrieren lassen.
btw: Als ich alles noch mit dem history Adapter gespeichert habe, hatte diese Daten schon >4 GB als json.

[apollon77]

@diginix Such mal ... vllt findest Du ja den anderen Thread wegen Migration ...

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Das hier?:

https://forum.iobroker.net/topic/46098/test-adapter-influxdb-2-0/164

Ich werde das bei Gelegenheit mal so probieren.

[apollon77]

Jaa danke ... ok Faktor 20 :-)))

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Habe ich das denn richtig verstanden, dass das nur den Export betrifft? Nach dem Import ist die neue DB wieder ungefähr so groß wie die alte?

[apollon77]

@ofbeqnpolkkl6mby5e13 Das fragst du MICH der noch nicht migriert hat??? Aber ich nehme es stark an. Der Export sind die Rohdaten in textform ... also müsste denke ich

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Ich werde berichten, bei Gelegenheit.

[oFbEQnpoLKKl6mbY5e13]

@apollon77 sagte in influxdb 3.0.0 verfügbar - eine Zusammenfassung:

Jaa danke ... ok Faktor 20 :-)))

Bei mir Faktor 15

[oFbEQnpoLKKl6mbY5e13]

Für die, die wie ich eine InfluxDB vor v1.8.3 einsetzen:

Die Option -lponly gibt es erst ab v1.8.3:

https://github.com/influxdata/influxdb/issues/19367

Mit den DDL und DML Daten im Export kann man aber nicht importieren. Also vor dem Export erst mal auf mindestens 1.8.3 updaten.

timhallinflux created this issue in influxdata/influxdb

closed Provide -lponly option for influx_inspect export & generate only line protocol #19367

[oFbEQnpoLKKl6mbY5e13]

So, 2,5 Stunden später ist der Import auf einem betagten NAS offensichtlich erfolgreich verlaufen. Instanz entsprechend angepasst, scheint zu laufen.

Die Größe der InfluxDB2 ist sogar etwas kleiner.

@apollon77
Bei einem Datenpunkt erhalte ich die folgende Fehlermeldung:

2022-05-20 00:07:43.832  - error: influxdb.0 (9531) HttpError: runtime error @4:12-4:136: filter: type conflict: bool != string

wenn ich den Verlauf angucken möchte.

Wo ist das Problem?

[oFbEQnpoLKKl6mbY5e13]

Ich habe den Datenpunkt nochmal deaktiviert und wieder aktiviert, nun geht es.

[apollon77]

@ofbeqnpolkkl6mby5e13 auch wenn es geht: ein bissl mehr log - in dem Fall debug log damit man die query sieht - würde Sinn machen.

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Wird das Editieren von Datenpunkten wie bei Influxdb1 im Admin noch hinzukommen?

[apollon77]

@ofbeqnpolkkl6mby5e13 ... wenn es jemand einbaut ... InfluxDB 2 ist da speziell. leg gern ein Feature Request an dann sieht man das

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Feature Request für den Admin Adapter? Dein Ernst?

[apollon77]

@ofbeqnpolkkl6mby5e13 Nein InfluxDB Adapter. der kann updateState nur für InfluxDB 1 ...

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Heute mal auf Deutsch...

https://github.com/ioBroker/ioBroker.influxdb/issues/262

RP70DP created this issue in ioBroker/ioBroker.influxdb

closed InfluxDB 2: Datenpunkte im Verlauf (Admin) bearbeiten/löschen/updaten ... #262

[Palm_Maniac]

Hallo,

ich hatte ja schon mal geschrieben, dass sich seit einiger Zeit Warnmeldungen bekomme, die mir dann das Log sprengen. Gestern habe mal den Adapter auf Debug gestellt, in der Hoffnung, dass der Fehler wieder auftritt. Er tat es. Anbei ein Ausschnitt des Log, das mittlerweile wieder auf eine Größe von über 2,6GB angewachsen ist. Ein Neustart des Adapter oder des InfluxDB Service behebt das Problem bis zum nächsten Auftreten, meistens irgendwann in der Nacht.

Während des Fehlers findet ein deutlich erhöhter Netzwerktraffic zwischen iobroker und dem Influx Container statt.

influxdb.0
2022-05-21 11:02:42.874	info	Add point that had error for linkeddevices.0.Sensoren.EG.Küche.Küchenmaschine.ENERGIE_Strom to buffer again, error-count=9

influxdb.0
2022-05-21 11:02:42.874	warn	Error on writePoint("{"value":0,"time":"2022-05-21T08:54:22.593Z","from":"system.adapter.linkeddevices.0","q":0,"ack":true}): HttpError: unexpected error writing points to database: timeout / "unexpected error writing points to database: timeout""

influxdb.0
2022-05-21 11:02:42.874	warn	Point could not be written to database: iobroker

influxdb.0
2022-05-21 11:02:42.861	debug	Write Point: linkeddevices.0.Sensoren.OG.Thomas.Fernseher.ENERGIE_Spannung values:{"value":229,"time":"2022-05-21T08:58:52.780Z","from":"system.adapter.linkeddevices.0","q":0,"ack":true} options: null

influxdb.0
2022-05-21 11:02:42.861	info	Add point that had error for linkeddevices.0.Sensoren.OG.Thomas.Fernseher.ENERGIE_Spannung to buffer again, error-count=9

influxdb.0
2022-05-21 11:02:42.861	warn	Error on writePoint("{"value":229,"time":"2022-05-21T08:58:52.780Z","from":"system.adapter.linkeddevices.0","q":0,"ack":true}): HttpError: unexpected error writing points to database: timeout / "unexpected error writing points to database: timeout""

influxdb.0
2022-05-21 11:02:42.861	warn	Point could not be written to database: iobroker

influxdb.0
2022-05-21 11:02:42.860	debug	Write Point: linkeddevices.0.Sensoren.OG.Thomas.PC.ENERGIE_Strom values:{"value":0.733,"time":"2022-05-21T09:00:42.807Z","from":"system.adapter.linkeddevices.0","q":0,"ack":true} options: null

influxdb.0
2022-05-21 11:02:42.860	info	Add point that had error for linkeddevices.0.Sensoren.OG.Thomas.PC.ENERGIE_Strom to buffer again, error-count=8

PS: Ich glaube, ich habe eine Spur gefunden. Die vorausgehenden Kommunikationsfehler treten ab 4Uhr Früh auf und genau da starten Update-Tasks in Proxmox, speziell der von meiner Windows 11 VM, die bei mir als Datei und Multimedia Server läuft. Wieso stört dieser Vorgang die Container von iobroker und InfluxDB? Die laufen doch weiter und genug Resourcen sind im Server auch noch frei und davor hat es immer Problemlos funktioniert?

PPS: Problem gelöst. Es trat auf, nachdem ich eine 6TB HDD in den PVE integriert hatte und alle VMs und CTs dort hin verschoben hatte. Wenn dann nun ein Backup einer VM anspringt, scheint die Last auf der HDD so hoch zu werden, dass es zu starken Verzögerungen zu kommen scheint, die dann diese Kommunikationsfehler mit der InfluxDB auslösen. Ich habe nun die CTs auf ein anderes Laufwerk verschoben und nun klappt es endlich wieder wunderbar, inkl. automatischer Backups.

[apollon77]

@palm_maniac Perfekt, genau das wäre auch meine Vermutung gewesen. Der Fehlert liegt bei der InfluxDB. Und die "erhöhle Neutzwerklast" entsteht übrigens das der Adapter bei einem "Massenschreib Fehler" darauf zurückfällt die Daten einzeln zu schreiben

[Marty56]

@apollon77
Ein grundsätzliche Frage. Bei dem History DB Adapter gibt es die Möglichkeit die Retention Policy für jeden Datenpunkt festzulegen. Die "Datenverdichtung" im InfluxDB Jargon, die Continuous Queries, habe ich in meinen Javascripten selber gemacht. Keine Ahnung, ob das der von Dir angedachte Ansatz ist.

Retention Policies habe ich bei dem Influx DB Adapter nicht gefunden.
Kommt das noch zu einem späteren Zeitpunkt, oder muss der Anwender seine Retention Policies und auch die Continuous Queries außerhalb des Adapters in der InfluxDB definieren?

Ich fände es wünschenswert, dass zu mindestens die Retention Polices auch Teil des InfluxDB Adapters werden sollten. Dann wäre die Migration von historyDB nach InfluxDB bzgl. der Scripts einfacher.

Update: Habe gerade nochmal die Doc gelesen. Vermutlich kann man eine kompatible RP nicht realisieren, weil influxDB 2.0 die nur pro Bucket unterstützt und nicht mehr für die einzelnen Messungen. Und dann hat sich auch noch die Query Language geändert, was wiederum einen Effekt hat auf die Javascript. Ok, es bleibt nicht einfach.

Update 2: Ich habe jetzt doch die Retention Policy in den Adapter settings gefunden. Hatte aus "Gewohnheit" bei den Datenpunkten geschaut.
Vergiss die Anfrage.