Influxdb: Wie altes backup in neuere DB einspielen
-
@dp20eic
Ich benutze den Backitup adapter. Das einfachste wäre, wenn ich das backup via dem Adapter in die jetzige Datenbank einspielen könnte. Ich weiß aber nicht, ob und wie dies geht. Normalerweise wird vor dem restore die existierende Datenbank gelöscht (das habe ich schon gemacht).
Wer weiß, was ich machen soll?
Danke
HUK -
@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:
Wer weiß, was ich machen soll?
- den Backitup-Adapter korrekt konfigurieren (hängt davon ab, wie/wo deine DB installiert ist
-
Deine Backup-Dateien unter /opt/iobroker/backups ablegen
-
"Backup" starten
- Sicherungen abrufen
- Datei auswählen und auf "wiederherstellen" klicken
-
Ob das Ganze sinnvoll ist, solange du nicht weißt, warum Daten einfach so "verschwinden", steht auf einem anderen Blatt ...
-
@marc-berg
Wie gesagt, ich weiß, wie ich ein normales restore der Influxdb mache (habe ich schon mehrfach gemacht). Aber dies war immer die gesamte Datenbank. Jetzt geht es darum, wie ich die alten Werte in eine existierende einfügen kann. Was passiert, wenn ich ein restore mit Backitup in eine existierende Datenbank mit gleichem Aufbau und Namen mache? Geht das überhaupt?
HUK -
Stimmt, da habe ich nicht richtig gelesen.
Du kannst das Backup in eine neue Datenbank (auf dem gleichen Server) zurückspielen:
influxd restore -portable -db <AKTUELLERDBNAME> -newdb <TEMPORÄRER_DB_NAME> path-to-backupUnd dann die Daten in die bestehende DB kopieren:
SELECT * INTO "<AKTUELLERDBNAME>".autogen.:MEASUREMENT FROM "<TEMPORÄRER_DB_NAME>".autogen./.*/ GROUP BY *Zum Schluss die temporäre DB löschen:
DROP DATABASE "<TEMPORÄRER_DB_NAME>" -
@marc-berg
OK, wie komme ich an das influxd verständliche backup der alten Datenbank? Ich habe ja nur die vom Backitup produzierte Datei (z.B. influxDB_2023_08_25-02_05_32_backupiobroker.tar.gz). Oder kann influxd diese Datei von Backitup direkt restaurieren? Kann ich diese Datei in den influxd restore ... Befehl für <AKTUELLERDBNAME> einsetzen?
Danke für Deine Hilfe
HUK -
@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:
OK, wie komme ich an das influxd verständliche backup der alten Datenbank? Ich habe ja nur die vom Backitup produzierte Datei (z.B. influxDB_2023_08_25-02_05_32_backupiobroker.tar.gz). Oder kann influxd diese Datei von Backitup direkt restaurieren?
Ich habe das mal durchgespielt, bei mir heißt die Datenbank "iobroker1".
Du musst die Backup-Datei zunächst auspacken. Zum Beispiel direkt auf der Kommandozeile:
influxdb1:/var/lib/influxdb/backup# tar -xvzf influxDB_2023_09_01-18_17_13_backupiobroker.tar.gzIn diesem Beispiel werden die Daten direkt in .../backup entpackt.
Weiter geht's mit dem Restore-Befehl in die temporäre DB:
influxdb1:~# influxd restore -portable -db iobroker1 -newdb iobroker1_tmp /var/lib/influxdb/backup 2023/09/02 07:29:52 Restoring shard 128 live from backup 20230901T161713Z.s128.tar.gz 2023/09/02 07:29:52 Restoring shard 132 live from backup 20230901T161713Z.s132.tar.gz 2023/09/02 07:29:52 Restoring shard 134 live from backup 20230901T161713Z.s134.tar.gz 2023/09/02 07:29:52 Restoring shard 136 live from backup 20230901T161713Z.s136.tar.gz 2023/09/02 07:29:52 Restoring shard 143 live from backup 20230901T161713Z.s143.tar.gz 2023/09/02 07:29:52 Restoring shard 151 live from backup 20230901T161713Z.s151.tar.gzDann die Daten kopieren:
influxdb1:~# influx Connected to http://localhost:8086 version 1.8.10 InfluxDB shell version: 1.8.10 > select * INTO "iobroker1".autogen.:MEASUREMENT FROM "iobroker1_tmp".autogen./.*/ GROUP BY * name: result time written ---- ------- 0 41265und temporäre DB löschen:
> DROP DATABASE "iobroker1_tmp"Kann ich diese Datei in den influxd restore ... Befehl für <AKTUELLERDBNAME> einsetzen?
nein
-
@marc-berg
Hat teilweise geklappt.
Nach dem select Befehl kam nach einiger Zeit:
ERR: timeout
Warning: It is possible this error is due to not setting a database.
Please set a database with the command "use <database>".Daraufhin habe use iobroker (Name meiner Datei) eingegeben und den select Befehl wiederholt. Es kam wieder der ERR: timeout
Wenn ich mit Grafana die Datenbank ansehe gibt es Diagramme, die die älteren Daten zeigen. Die meisten aber nicht.
Wie kann ich dem timeout Fehler begegnen?
Hab vielen Dank für Deine explizite Anleitung, die ich offensichtlich brauche.
HUK -
@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:
Nach dem select Befehl kam nach einiger Zeit:
ERR: timeoutDa wird deine Datenbank zu groß sein, bzw. die Hardware zu langsam, sodass das Timeout erreicht wird. Wahrscheinlich wirst du die "SELECT" Query in kleinere zeitliche Häppchen aufteilen müssen. Also die Query ergänzen z.B. um
where time >= '2021-01-01 00:00:00' and time < '2022-01-01 00:00:00'oder noch kleinere zeitliche Intervalle, wenn der Timeout immer noch auftritt.
-
@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:
Nach dem select Befehl kam nach einiger Zeit:
Moin,
bitte nicht aus dem Kopf, irgendwelche Fehler zitieren, immer alles zeigen, von der Eingabezeile, bis hin zum neuen Prompt. Nätürlich als Text in Code Tags </>
VG
Bernd -
@marc-berg sagte in Influxdb: Wie altes backup in neuere DB einspielen:
oder noch kleinere zeitliche Intervalle, wenn der Timeout immer noch auftritt.
Ein anderer Ansatz wäre, die Datenbank komplett zu löschen und dein "großes" Backup per normalen Backitup-Restore zurückzuspielen. Danach nur noch den kleinen Teil (der nach dem Crash entstanden ist) per o.g. Methode einfügen. Das würde ich machen, wenn das Timeout auch bei kleinen Häppchen auftritt und der Aufwand zu hoch wäre, tausend "Mini-Häppchen" zurückzuspielen.
-
@marc-berg
Das ist eine gute Idee.
Mit dem where stehe ich noch auf Kriegsfuß:> select * INTO "iobroker".autogen.:MEASUREMENT FROM "iobroker_tmp".autogen./.*/ GROUP BY * where time >= '2023-06-01 00:00:00' and time < '2023-06-30 00:00:00' ERR: error parsing query: found WHERE, expected ; at line 1, char 91HUK
-
@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:
Mit dem where stehe ich noch auf Kriegsfuß:
Bin jetzt nicht wirklich fit in InfluxQL, aber ich glaube die "where" Clause muss vor "group".
-
@marc-berg
Habe dies so versucht mit delta t = 1 Monat> select * INTO "iobroker".autogen.:MEASUREMENT FROM "iobroker_tmp".autogen./.*/ where time >= '2023-06-01 00:00:00' and time < '2023-06-30 00:00:00' GROUP BY * ERR: timeout > select * INTO "iobroker".autogen.:MEASUREMENT FROM "iobroker_tmp".autogen./.*/ where time >= '2023-06-01 00:00:00' and time < '2023-06-30 00:00:00' GROUP BY * ERR: partial write: points beyond retention policy dropped=155Dann noch einmal, mit neuem Fehler. Die alte Datenbank ist nur 18.905 KB groß als GZ Datei (für ca. 9 Monate). Die jetzige ist 422 KB für ca. 7 Tage. Beide wirklich nicht groß würde ich denken. Werde die Umkehrung versuchen.
HUK -
@hukio Wenn du mit unterschiedlichen Retention policies arbeitest, musst du natürlich "autogen" durch den Namen der policy ersetzen.
-
@marc-berg
Bei mir ist alles default, wüßte nicht, wie ich die retention policy beeinflussen kann.
HUK -
@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:
Habe dies so versucht mit delta t = 1 Monat
Moin,
lese nur noch am Rande mit, aber wie ist denn die
Retentionder Datenbank, sagen wir mal, die steht auf 30 Tage, dann kannst Du keine Daten einfügen, die älter als 30 Tage sind.
Wie gesagt, lese hier nur noch sporadisch mit, falls das schon beantwortet wurde, sorry.VG
BerndP.S.: @Marc-Berg war schneller
-
@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:
Bei mir ist alles default, wüßte nicht, wie ich die retention policy beeinflussen kann.
Moin,
und wieder mal die schöne Dokumentation vom Hersteller https://docs.influxdata.com/influxdb/v1.8/query_language/explore-schema/#show-retention-policies
VG
BerndP.S.: und wenn Du das ändern möchtest https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#modify-retention-policies-with-alter-retention-policy
-
@dp20eic sagte in Influxdb: Wie altes backup in neuere DB einspielen:
lese nur noch am Rande mit, aber wie ist denn die Retention der Datenbank, sagen wir mal, die steht auf 30 Tage, dann kannst Du keine Daten einfügen, die älter als 30 Tage sind.
Ja, das sieht für mich auch so aus, dass nach dem Crash eine Retention policy ungleich "unendlich" angelegt wurde. Aber dann ist der umgekehrte Weg der Wiederherstellung wahrscheinlich sowieso der bessere.
Edit:
Aber die Überlegung wirft nochmal ein anderes Licht auf das "Verschwinden" der Daten. Vielleicht wurden durch das Verstellen der Retention policy Daten gelöscht.
-
SHOW RETENTION POLICIES name duration shardGroupDuration replicaN default ---- -------- ------------------ -------- ------- autogen 17520h0m0s 168h0m0s 1 trueIst offensichtlich nicht unendlich, wäre 0 h für duration denke ich.
HUK
