1.8: you can have multiple retention per database.
2.0: one bucket , one retention. you need to downsample to a different bucket.


  • 1.8 : can only use FluxSQL
  • 2.0: can use Flux and FluxSQL

Continuous Query

Continuous query is replaced with Task – you need to convert your InfluxSQL in Continuous query to Influx query and setup the task.

Convert FLUXSQL to FLux query


data3 = from(bucket: “telegraf”)
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) =>
(r._measurement =~ /system.*/))

|> aggregateWindow(fn: mean, every: 1h)
|> filter(fn: (r) =>
(exists r._value))
|> to(bucket: “telegraf_30min”, org: “MyHomeInflux”)

Sampling is easy, don’t you think that we just need to run a continuous query / task to do the job? It’s easy if all data we have only contains metrics (number) only.


we normally use an aggregate function like “mean” , there is a challenge with this, if there is a field type is string, the mean function will not work, so that query will fail.

For example, we have 1 bucket with 100 measurements , 99 measurements only have metric data. But we have 1 measurement with 10 fields, but one of the field has “string” data. A single query to sample will not work because we can’t do “mean” with string data. Our query must exclude this field/measurement from the query.

Although InfluxDB can store string data, but since we can’t do sampling on string data. So if you need sampling, it’s better to have a bucket only has metrics data, we can store string data in another bucket.


When you use the cli “influx”, it’s totally different between v1 and v2

in v1: you will connect to an influx instance and run the command on that, just like our mysql command

in v2: it’s different, you need to provide flag, query …. one time, one query