Influxdb3 - does DOCKER_INFLUXDB_INIT_ADMIN_TOKEN_FILE work

1

Hi,

I’ve started a project with Influxdb2 and it is still in its early stages so I thought it makes sense to move to influxdb3 core.

I’m using docker compose using the official docker image. With influxdb2, I was able to create an admin token using DOCKER_INFLUXDB_INIT_ADMIN_TOKEN_FILE in docker compose.

I tried the same using influxdb3 core, but I didn’t see the token being created and had to manually create one myself.

I’m wondering if DOCKER_INFLUXDB_INIT_ADMIN_TOKEN_FILE is (or will be) supported on influxdb3 core, and if it is already supported, if I have to do anything different in this case.

Thanks,
Sridhar

2

Looking at the V2.7 docker entrypoint script vs the 3.x entrypoint script, I’d say NO.
It took 1 year from reporting it not working in 2.X to actually working in 2.7, so I’d say be patient.

3

Also, V3 is early.
Too early to be using it, really. There’s no UI and a few things seem to be premature. There has been a lot of pressure on the v3 version to be pushed out.

I tried to upgrade from V2.7 to 3 and I stopped. Impossible to upgrade the data, impossible to import ATM. I’ll just let 2.7 run for another year or so until V3 is mature and there will be an import path from V2 to V3.

1 Like
4

I actually liked that it was lightweight, no UI, and focused on the core engine with support for admin tasks from the cli.

However, I too am thinking it is way too early to be using it - the fact that V3 seems to be optimized for processing recent data and they have a limit of 72 hours for queries just doesn’t fit my use case at all. (They handle this in the enterprise version apparently by compacting data and allowing for queries over much longer periods - the oss core version doesn’t compact the data and so query performance would degrade if longer than about 72 hours - TLDR).

It does seem like there was pressure to release V3. I thought it would make sense to start with latest and greatest for a new project (so no issue really with upgrading data), but that doesn’t seem to be the case here!

Thanks for your reply!

1 Like
5

@sridhar_rajagopall,
Yes if you need to query historical data and are a hobbyist who:

  • isn’t constrained by performance concerns
  • doens’t have high cardinality requirements
  • doesn’t have a need for the unlimited analytics, transformation, alerting capabilities of the Python Processing Engine
    Then I agree V2 or V1 might in fact be a better fit for you.

@ingoratsdorf
We are working on a UI to be released soon.
What migration paths did you try and what issues were you running into?

Thanks

6

Hi @Anaisdg .
Thanks for your contribution.

Well, the whole point, at least for me, for a TSDB is to have access to historical data. 365 days to be accurate. Which makes the database rather big, admittedly.

Which takes us to the next point, upgrade from 2.7 to 3 was treacherous even in the attempt.
100% CPU for hours, and total disk use with not enough storage space.

I cannot recall correctly, but somewhere it was suggested to use the influxdaemon raw export function to generate plain text raw output to then be imported again into influxdb, V3 in that instance. This generates terabytes of data, would have to be run in chunks due to export file sizes. I have neither time nor resources for this, unfortunately. And obviously this can not be run on a life system either, you’ll never get the full data. So shut down the db or create a container clone, either way you loose hours of data, if it ever succeeds.

Cheers,
Ingo