NEWS
InfluxDB - Daten weg / Wiederherstellung [gelöst]
-
Zu früh gefreut, heute kam folgender Eintrag im ioBroker Log:
influxdb.0 2023-01-23 11:28:10.662 error Error: ESOCKETTIMEDOUT influxdb.0 2023-01-23 11:28:10.661 error getHistory: Error: ESOCKETTIMEDOUT -
Hatte heute doch noch ein Netzwerkproblem gefunden. Ein Powerline Adapter machte ungewöhnlich starke Probleme (Heute ab 18 Uhr). Hatte ich so vorher noch nie gehabt.
Mein Log ist voll davon (Der ESP8266 ist über WLAN mit genau diesem Adapter verbunden... oder auch nicht ;-) )
2023-01-23 18:19:20.163 - info: mqtt.0 (959) Client [ESP8266Client-790e] connected with secret * 2023-01-23 18:19:21.158 - info: shelly.0 (1057) [MQTT] Device 192.168.1.130 (shelly1 / shelly1-68C63AFAFEAB / SHSW-1#68C63AFAFEAB#1) connected! Polltime set to 5 sec. 2023-01-23 18:19:57.677 - info: mqtt.0 (959) Client [ESP8266Client-790e] connection closed: timeout 2023-01-23 18:21:26.190 - info: influxdb.0 (141035) Store 1001 buffered influxDB history points 2023-01-23 18:21:27.964 - info: shelly.0 (1057) [MQTT] Device 192.168.1.110 (shellyht / shellyht-F4483E / SHHT-1#F4483E#1) connected! Polltime set to 5 sec. 2023-01-23 18:22:01.574 - info: mqtt.0 (959) Client [ESP8266Client-85f6] connected with secret * 2023-01-23 18:22:24.100 - info: mqtt.0 (959) Client [ESP8266Client-85f6] connection closed: timeout 2023-01-23 18:23:31.491 - info: mqtt.0 (959) Client [ESP8266Client-b49f] connected with secret * 2023-01-23 18:23:53.994 - info: mqtt.0 (959) Client [ESP8266Client-b49f] connection closed: timeout 2023-01-23 18:24:24.048 - info: influxdb.0 (141035) Store 1001 buffered influxDB history points 2023-01-23 18:24:36.669 - info: shelly.0 (1057) [MQTT] Device 192.168.1.112 (shellyht / shellyht-A4CF12F44435 / SHHT-1#A4CF12F44435#1) connected! Polltime set to 5 sec. 2023-01-23 18:25:49.622 - info: mqtt.0 (959) Client [ESP8266Client-589] connected with secret * 2023-01-23 18:26:12.128 - info: mqtt.0 (959) Client [ESP8266Client-589] connection closed: timeout 2023-01-23 18:26:19.188 - info: mqtt.0 (959) Client [ESP8266Client-ec93] connected with secret *Ich hab jetzt alle Adapter auf die gleiche Phase geklemmt (Stromkreise im Hausanschlusskasten getauscht). Das hat immer schon mal die ständigen Netzwerkabbrüche verhindert. Die Datenrate zu dem Adapter ist trotzdem "nicht gut" bzw. nicht wie erwartet gestiegen. Support ist bereits kontaktiert.
-
Habe heute 2 alte Backups wieder gestellt. In dem Zeitraum in dem in der "Live" Datenbank die Daten fehlen, sind in beiden jeweils Abschnitte mit Daten enthalten die ich gerne zurückholen würde. Zum besseren Verständnis hab ich in Grafana eine Gegenüberstellung am Beispiel einer Temperatur (Vorlauftemperatur meiner Heizung) gemacht:
Geht das mit der Methode von marc-berg nur wenn ich die Datenbank auf 2.0 migriert habe? Oder gibt es auch eine Möglichkeit das in der Version 1.8 zu machen?
@marc-berg said in InfluxDB - Daten weg / Wiederherstellung:
Für eine InfluxDB 2.x habe ich mal zwei Zeiträume zusammengeführt. Das geht aber nur manuell, nicht mit dem Backitup Adapter.
Dazu machst Du zunächst ein Restore in ein neues Bucket (das *tar.gz muss vorher entpackt werden):
influx restore --new-bucket <NAMENEW> --bucket <NAMEOLD> <PFAD/ZUM/BACKUP> -t <TOKEN>Danach kopierst Du die Daten (Dabei entstehen keine doppelten Daten, falls sich die Zeiträume überlappen, der "range" kann also großzügig gewählt werden)
influx query 'from(bucket:"<NAMENEW>") |> range(start:-10y) |> filter(fn: (r) => r._measurement == "<NAME_MEASUREMENT>") |> set(key: "_measurement", value: "<NAME_MEASUREMENT>") |> to(bucket: "<NAMEOLD>")'Bezeichner in spitzen Klammern sind natürlich alle anzupassen.
Mit dem zweiten Befehl kann man so innerhalb eines Buckets auch relativ einfach Daten zwischen Measurements kopieren, hilfreich, wenn man mal Objekte umbenennt.
Danach natürlich noch das "ZWISCHENBUCKET" löschen. Fertig.
-
Habe heute 2 alte Backups wieder gestellt. In dem Zeitraum in dem in der "Live" Datenbank die Daten fehlen, sind in beiden jeweils Abschnitte mit Daten enthalten die ich gerne zurückholen würde. Zum besseren Verständnis hab ich in Grafana eine Gegenüberstellung am Beispiel einer Temperatur (Vorlauftemperatur meiner Heizung) gemacht:
Geht das mit der Methode von marc-berg nur wenn ich die Datenbank auf 2.0 migriert habe? Oder gibt es auch eine Möglichkeit das in der Version 1.8 zu machen?
@marc-berg said in InfluxDB - Daten weg / Wiederherstellung:
Für eine InfluxDB 2.x habe ich mal zwei Zeiträume zusammengeführt. Das geht aber nur manuell, nicht mit dem Backitup Adapter.
Dazu machst Du zunächst ein Restore in ein neues Bucket (das *tar.gz muss vorher entpackt werden):
influx restore --new-bucket <NAMENEW> --bucket <NAMEOLD> <PFAD/ZUM/BACKUP> -t <TOKEN>Danach kopierst Du die Daten (Dabei entstehen keine doppelten Daten, falls sich die Zeiträume überlappen, der "range" kann also großzügig gewählt werden)
influx query 'from(bucket:"<NAMENEW>") |> range(start:-10y) |> filter(fn: (r) => r._measurement == "<NAME_MEASUREMENT>") |> set(key: "_measurement", value: "<NAME_MEASUREMENT>") |> to(bucket: "<NAMEOLD>")'Bezeichner in spitzen Klammern sind natürlich alle anzupassen.
Mit dem zweiten Befehl kann man so innerhalb eines Buckets auch relativ einfach Daten zwischen Measurements kopieren, hilfreich, wenn man mal Objekte umbenennt.
Danach natürlich noch das "ZWISCHENBUCKET" löschen. Fertig.
@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:
Geht das mit der Methode von marc-berg nur wenn ich die Datenbank auf 2.0 migriert habe? Oder gibt es auch eine Möglichkeit das in der Version 1.8 zu machen?
Diese Methode basiert auf der Skriptsprache "Flux" und läuft nur unter influxdb 2.x. Sicher gibt es auch eine entsprechende Methode für die 1.x, die kenne ich aber nicht.
-
@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:
Geht das mit der Methode von marc-berg nur wenn ich die Datenbank auf 2.0 migriert habe? Oder gibt es auch eine Möglichkeit das in der Version 1.8 zu machen?
Diese Methode basiert auf der Skriptsprache "Flux" und läuft nur unter influxdb 2.x. Sicher gibt es auch eine entsprechende Methode für die 1.x, die kenne ich aber nicht.
Ich bin gerade darüber gestolpert, werde mir das mal genauer ansehen:
https://github.com/toni-moreno/syncflux#run-as-a-database-replication-tool
-
Ich bin gerade darüber gestolpert, werde mir das mal genauer ansehen:
https://github.com/toni-moreno/syncflux#run-as-a-database-replication-tool
@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:
Ich bin gerade darüber gestolpert, werde mir das mal genauer ansehen:
https://github.com/toni-moreno/syncflux#run-as-a-database-replication-tool
Hm, interessant. Es sieht für mich aber so aus, als ob du dafür zwei Datenbanken (Server) benötigst. Ich dachte, du hättest einen Server und x Backup-Files.
Meinst du nicht, dass das hier besser ist:
Das entspricht etwa "meiner" Methode.
-
@marc-berg said in InfluxDB - Daten weg / Wiederherstellung:
@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:
Ich bin gerade darüber gestolpert, werde mir das mal genauer ansehen:
https://github.com/toni-moreno/syncflux#run-as-a-database-replication-tool
Hm, interessant. Es sieht für mich aber so aus, als ob du dafür zwei Datenbanken (Server) benötigst. Ich dachte, du hättest einen Server und x Backup-Files.
Meinst du nicht, dass das hier besser ist:
Das entspricht etwa "meiner" Methode.
Stimmt, ich habe 1 Server.
Bei den Begriffen gerate ich ins Straucheln.
show databasesZeigt mir die Datenbanken an. Deshalb spreche ich von einer Datenbank. Die Backups die ich wieder gestellt habe, habe ich als neue Datenbank anlegen lassen. Ich will die aktuelle Datenbank ja nicht überschreiben.
pi@raspberrypi:~ $ influx Connected to http://localhost:8086 version 1.8.10 InfluxDB shell version: 1.8.10 > > show databases name: databases name ---- _internal iobroker iobroker080123 iobroker010123 iobroker130123 >Und jetzt möchte ich die Zeitabschnitte in denen die Backups Daten enthalten in mein "iobroker" Datenbank migrieren.
Wenn ich deinen Link verstehe, dann müsste das jetzt funktionieren. Alte Datenpunkte mit identischen Daten werden einfach überschrieben.Punkt 1 hab ich bereits erledigt:
- Restore a backup to a temporary database.
Fehlt noch:
2. Use InfluxQL or Flux to query data from the temporary database and write it back to the existing database.-- Repeat for each retention policy in the temporary database SELECT * INTO "example-db".autogen.:MEASUREMENT FROM "example-tmp-db".autogen./.*/ GROUP BY * -
@marc-berg said in InfluxDB - Daten weg / Wiederherstellung:
@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:
Ich bin gerade darüber gestolpert, werde mir das mal genauer ansehen:
https://github.com/toni-moreno/syncflux#run-as-a-database-replication-tool
Hm, interessant. Es sieht für mich aber so aus, als ob du dafür zwei Datenbanken (Server) benötigst. Ich dachte, du hättest einen Server und x Backup-Files.
Meinst du nicht, dass das hier besser ist:
Das entspricht etwa "meiner" Methode.
Stimmt, ich habe 1 Server.
Bei den Begriffen gerate ich ins Straucheln.
show databasesZeigt mir die Datenbanken an. Deshalb spreche ich von einer Datenbank. Die Backups die ich wieder gestellt habe, habe ich als neue Datenbank anlegen lassen. Ich will die aktuelle Datenbank ja nicht überschreiben.
pi@raspberrypi:~ $ influx Connected to http://localhost:8086 version 1.8.10 InfluxDB shell version: 1.8.10 > > show databases name: databases name ---- _internal iobroker iobroker080123 iobroker010123 iobroker130123 >Und jetzt möchte ich die Zeitabschnitte in denen die Backups Daten enthalten in mein "iobroker" Datenbank migrieren.
Wenn ich deinen Link verstehe, dann müsste das jetzt funktionieren. Alte Datenpunkte mit identischen Daten werden einfach überschrieben.Punkt 1 hab ich bereits erledigt:
- Restore a backup to a temporary database.
Fehlt noch:
2. Use InfluxQL or Flux to query data from the temporary database and write it back to the existing database.-- Repeat for each retention policy in the temporary database SELECT * INTO "example-db".autogen.:MEASUREMENT FROM "example-tmp-db".autogen./.*/ GROUP BY *Das Statement müsste in deinem Fall
SELECT * INTO iobroker.autogen.<measurement_name>:MEASUREMENT FROM iobroker080123.autogen.<measurement_name> GROUP BY *lauten. Ich würd's aber erstmal in einer weiteren DB testen.
-
Das Statement müsste in deinem Fall
SELECT * INTO iobroker.autogen.<measurement_name>:MEASUREMENT FROM iobroker080123.autogen.<measurement_name> GROUP BY *lauten. Ich würd's aber erstmal in einer weiteren DB testen.
Ich merge zum Test erst zwei Backups.
-
Das Statement müsste in deinem Fall
SELECT * INTO iobroker.autogen.<measurement_name>:MEASUREMENT FROM iobroker080123.autogen.<measurement_name> GROUP BY *lauten. Ich würd's aber erstmal in einer weiteren DB testen.
Ich hab jetzt kein einzelnes Measurement gewählt:
> SELECT * INTO iobroker130123.autogen.:MEASUREMENT FROM iobroker080123.autogen./.*/ GROUP BY * ERR: timeoutFür ein einzelnes Measurement hat es so geklappt:
> SELECT * INTO iobroker130123.autogen."shelly.0.SHSW-PM#A4CF12F3CBAB#1.ext.temperatureC1" FROM iobroker080123.autogen."shelly.0.SHSW-PM#A4CF12F3CBAB#1.ext.temperatureC1" GROUP BY * name: result time written ---- ------- 0 640288Ergebnis:
:smiley:
Wir aber ein ganz schöner Aufwand, dass für alle 147 Measurements händisch zu machen... -
Nochmal ein Vorher / Nachher Vergleich:
Influx starten:
pi@raspberrypi:~ $ influxMeasurement auswählen:
> SELECT * INTO iobroker130123.autogen."shelly.0.SHSW-PM#A4CF12F3CBAB#1.ext.temperatureC1" FROM iobroker010123.autogen."shelly.0.SHSW-PM#A4CF12F3CBAB#1.ext.temperatureC1" GROUP BY * name: result time written ---- ------- 0 635668Ergebnis:
Danke dir in jedem Fall @Marc-Berg und auch @Thomas-Braun, @crunchip und @Glasfaser. Ich setze das Topic dann auf gelöst.
-
Nochmal ein Vorher / Nachher Vergleich:
Influx starten:
pi@raspberrypi:~ $ influxMeasurement auswählen:
> SELECT * INTO iobroker130123.autogen."shelly.0.SHSW-PM#A4CF12F3CBAB#1.ext.temperatureC1" FROM iobroker010123.autogen."shelly.0.SHSW-PM#A4CF12F3CBAB#1.ext.temperatureC1" GROUP BY * name: result time written ---- ------- 0 635668Ergebnis:
Danke dir in jedem Fall @Marc-Berg und auch @Thomas-Braun, @crunchip und @Glasfaser. Ich setze das Topic dann auf gelöst.
@naturfreund said in InfluxDB - Daten weg / Wiederherstellung [gelöst]:
Ich setze das Topic dann auf gelöst.
Hallo Naturfreund,
bei mir kommt es in letzter Zeit leider ebenfalls zu Datenverlust in der InfluxDB Datenbank. Du hast das Topic auf gelöst gesetzt, einen tatsächlichen Grund habt ihr aber nicht gefunden, richtig? Die Lücken in den Daten konntest du nur wieder schließen, weil du noch Backups hattest.
Läuft denn jetzt mit dem neuen System alles wieder ohne Probleme?
-
@naturfreund said in InfluxDB - Daten weg / Wiederherstellung [gelöst]:
Ich setze das Topic dann auf gelöst.
Hallo Naturfreund,
bei mir kommt es in letzter Zeit leider ebenfalls zu Datenverlust in der InfluxDB Datenbank. Du hast das Topic auf gelöst gesetzt, einen tatsächlichen Grund habt ihr aber nicht gefunden, richtig? Die Lücken in den Daten konntest du nur wieder schließen, weil du noch Backups hattest.
Läuft denn jetzt mit dem neuen System alles wieder ohne Probleme?
@iojoker
Oh, sorry, hab deine Frage übersehen. Ja, es läuft seit dem super stabil. Ich hab die SD Karte im Verdacht, beweisen kann ich es aber nicht. Mit SSD bisher keine Probleme mehr gehabt.
Würde auch jedem raten direkt mit einer SSD zu starten. -
@iojoker
Oh, sorry, hab deine Frage übersehen. Ja, es läuft seit dem super stabil. Ich hab die SD Karte im Verdacht, beweisen kann ich es aber nicht. Mit SSD bisher keine Probleme mehr gehabt.
Würde auch jedem raten direkt mit einer SSD zu starten.Haha, besser spät als gar nicht. :)
Ich vermute, es lag am 32bit Betriebssystem. Ich hatte ja direkt mit SSD begonnen, jedoch mit 32bit. Seitdem ich auf 64bit umgestiegen bin, sind zum Glück keine Lücken mehr in den Daten aufgetreten.
Support us
622
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge