Umschreiben großer InfluxDB Datenbanken

Entwicklung / Development Fehleranalyse / Troubleshooting
1

Einleitung

Wir wollen die 7.6 GB große InfluxDB Datenbank mit Daten von luftdaten.info kompakter gestalten, siehe Erneuerung der Luftdatenpumpe.

Die Abfrage

Die dafür anvisierte SQL Anfrage "luftdaten-migration-1a.sql" lautet:

-- Explicitly select fields
SELECT
    time, location_id, sensor_id, geohash, P0, P1, P2,
    durP1, durP2, ratioP1, ratioP2, temperature, humidity,
    altitude, pressure, pressure_at_sealevel, max_micro, min_micro, samples

-- Select target database
INTO "luftdaten_info"."autogen"."earth_45_sensors"

-- Select source database
FROM "luftdaten_info"."autogen"."earth_43_sensors"

-- Copy all tags
GROUP BY *

– InfluxDB SELECT INTO backing up and restoring data method. · GitHub

Fail.

Das klappte nicht ganz, der Prozess antwortete lapidar mit:

ERR: %!s(<nil>)

Die Logdatei

journalctl --unit influxdb --since '19:55' --follow

gibt darüber Auskunft, dass der Prozess sang- und klanglos gestorben ist.

Degrading

Nov 05 19:55:09 eltiempo influxd[10550]: ts=2018-11-05T18:55:05.066207Z lvl=info msg="Cache snapshot (start)" log_id=0BYsu_K0000 engine=tsm1 trace_id=0BaJVApW000 op_name=tsm1_cache_snapshot op_event=start
Nov 05 19:55:09 eltiempo influxd[10550]: ts=2018-11-05T18:55:06.094079Z lvl=info msg="Cache snapshot (start)" log_id=0BYsu_K0000 engine=tsm1 trace_id=0BaJVIFl000 op_name=tsm1_cache_snapshot op_event=start
Nov 05 19:58:31 eltiempo systemd[1]: influxdb.service: Main process exited, code=killed, status=9/KILL
Nov 05 19:58:31 eltiempo systemd[1]: influxdb.service: Unit entered failed state.
Nov 05 19:58:31 eltiempo systemd[1]: influxdb.service: Failed with result 'signal'.

Bounced by systemd

Nov 05 19:58:32 eltiempo influxd[29673]: ts=2018-11-05T18:58:32.154932Z lvl=info msg="InfluxDB starting" log_id=0BaJh0MW000 version=1.6.4 branch=1.6 commit=a2ba6e7654fb078f8a3f5add1f8d935df38161bd
Nov 05 19:58:32 eltiempo influxd[29673]: ts=2018-11-05T18:58:32.154985Z lvl=info msg="Go runtime" log_id=0BaJh0MW000 version=go1.10.3 maxprocs=4
Nov 05 19:58:32 eltiempo influxd[29673]: ts=2018-11-05T18:58:32.264910Z lvl=info msg="Using data dir" log_id=0BaJh0MW000 service=store path=/var/lib/influxdb/data

Und nun?

… das ganze noch einmal ohne weitere konkurrierende Last auf der Datenbank. Wir haben nun sowohl die Importjobs als auch die Grafana Instanzen einstweilen abgeschaltet und bitten um Euer Verständnis.

2

Update: InfluxDB kann die Anfrage zum Umschreiben der Datenkollektion weiterhin nicht bewältigen sondern bricht nach ca. 10 Minuten zusammen.

Durch "SHOW TAG KEYS" konnten wir herausfinden, dass "location_name" weiterhin Bestandteil der neuen Datenkollektion war, das wollten wir ja gerade nicht. Man muss die Tags also ebenfalls explizit im "GROUP BY" Teil der "SELECT ... INTO" Anfrage ausschließen. Außerdem wurden die im "SELECT" Teil genannten Tag Felder "location_id, sensor_id, geohash" doppelt in die Zielkollektion projiziert, sorgten dort also für abermals erhöhtes Aufkommen.

Nächster Versuch also mit einer überarbeiteten "luftdaten-migration-1b.sql", diesmal auch explizit in eine neue Datenbank:

-- Explicitly select fields, don't list tags
SELECT
    time,
    P0, P1, P2, durP1, durP2, ratioP1, ratioP2, temperature, humidity,
    altitude, pressure, pressure_at_sealevel, max_micro, min_micro, samples

-- Select target database
INTO "ldi02"."autogen"."earth_01_sensors"

-- Select source database
FROM "luftdaten_info"."autogen"."earth_43_sensors"

-- Copy specific tags
GROUP BY location_id, sensor_id, sensor_type, geohash
3

Das davon in der Zielkollektion erzeugte Schema sieht schonmal gut aus:

> show tag keys

tagKey
------
geohash
location_id
sensor_id
sensor_type

> show field keys

fieldKey             fieldType
--------             ---------
P0                   float
P1                   float
P2                   float
altitude             float
humidity             float
pressure             float
pressure_at_sealevel float
temperature          float

Erste Daten scheinen auch schon in der Zieldatenbank anzukommen:

du -sch /var/lib/influxdb/data/ldi02/

1.7G	 total

Jetzt muss nur noch der Prozess durchhalten, bevor die Ressourcen ausgehen.

1 Like
4

Der gesamte Prozess hat 90 Minuten gedauert, ist aber endlich erfolgreich durchgelaufen. Allerdings vermutlich nur, weil wir in dieser Zeit keine weiteren Anfragen an die Datenbank zugelassen haben. Wir müssen hier also nochmal ran, siehe Erneuerung der Luftdatenpumpe.