content/shared/influxdb-v2/reference/faq.md
{{% show-in "cloud,cloud-serverless" %}}
{{% /show-in %}}
{{% show-in "cloud,cloud-serverless" %}}
{{% /show-in %}}
{{% show-in "v2" %}}
{{% /show-in %}}
{{% show-in "v2" %}}- How can I identify my InfluxDB version?{{% /show-in %}}
GROUP BY time() queries?GROUP BY time() queries return timestamps that occur after now()?WHERE OR time clause returning empty results?fill(previous) return empty results?{{% show-in "cloud,cloud-serverless" %}}
Use the Forgot Password link on the InfluxDB Cloud login page to update your password. For more information, see Change your password.
{{% /show-in %}}
{{% show-in "v2" %}}
Use the influx CLI and the
influx user password command
command to update a user's password.
For more information, see
Change your password.
{{% /show-in %}}
{{% show-in "cloud,cloud-serverless" %}}
Use the Switch Accounts functionality in your InfluxDB Cloud account settings to switch between InfluxDB Cloud accounts. For more information, see Switch InfluxDB Cloud accounts.
For more information, see Manage InfluxDB Cloud billing.
For billing issues, please contact InfluxData support.
To view your InfluxDB Cloud organization's data usage, view the Usage page in the InfluxDB Cloud user interface. For more information, see View InfluxDB Cloud data usage.
{{% /show-in %}}
{{% show-in "cloud,cloud-serverless" %}}
InfluxDB Cloud regions and underlying services are monitored at all times. To see the current status of InfluxDB Cloud, view the InfluxDB Cloud status page. To receive outage alerts and updates, subscribe to our status page.
{{% /show-in %}}
{{% show-in "v2" %}}
InfluxDB {{< current-version >}} provides different ways to monitor its status:
/health API endpoint returns a JSON
body with a summary of the current status of your InfluxDB instance.{{% expand-wrapper %}} {{% expand "View example health summary" %}}
{
"name": "influxdb",
"message": "ready for queries and writes",
"status": "pass",
"checks": [],
"version": "{{< latest-patch >}}",
"commit": "xx00x0x000"
}
{{% /expand %}} {{% /expand-wrapper %}}
The /metrics API endpoint provides internal
InfluxDB metrics in Prometheus exposition format. Use Telegraf,
InfluxDB scrapers, or the Flux
prometheus.scrape() function
to scrape these metrics and store them in InfluxDB where you can monitor and
alert on any anomalies.
You can also use the InfluxDB Open Source (OSS) Metrics template quickly setup InfluxDB OSS monitoring.
For more information, see Monitor InfluxDB OSS using a template
{{% /show-in %}}
InfluxDB {{< current-version >}} supports the following token types:
{{% show-in "v2" %}}- Operator tokens{{% /show-in %}}
For more information about each token type, see Manage API tokens.
InfluxDB {{< current-version >}} enforces security best practices by requiring API requests to be authenticated. Authentication cannot be disabled.
{{% show-in "cloud,cloud-serverless" %}}
InfluxDB Cloud has only one permission level for users: Owner. With Owner permissions, a user can delete resources and other users from your organization. Take care when inviting a user.
{{% /show-in %}}
{{% show-in "v2" %}}
Use one of the following methods to identify the version of InfluxDB OSS you're using:
Use the InfluxDB UI:
Use the influxd version command
$ influxd version
InfluxDB {{< latest-patch >}} (git: x0x000xx0x) build_date: YYYY-MM-DDThh:mm:ssZ
Use the /health API endpoint.
The following example uses jq to process the
JSON body returned from the /health API endpoint and extract the InfluxDB version.
You don't have to process the JSON with jq. For an example of the JSON
returned by the /health endpoint, see View example health summary.
$ curl -s http://localhost:8086/health | jq -r '.version'
{{< latest-patch >}}
{{% /show-in %}}
For information about what versions of Flux are packaged with official InfluxDB releases, see Flux versions in InfluxDB.
If using a custom build, use the following query to return the current version of Flux being used:
import "array"
import "runtime"
array.from(rows: [{version: runtime.version()}])
For more information, see Query the Flux version.
{{% show-in "v2" %}}
All InfluxDB logs are output by the influxd service.
To store logs to a file, pipe the output of influxd to a file. For example:
influxd 2>~/path/to/influxd-errors.log
InfluxDB buckets store data in shard groups. A single shard group covers a specific time interval. InfluxDB determines that time interval by using the retention period of the bucket. The table below outlines the default relationship between the bucket retention period and the time interval of a shard group:
| Bucket retention period | Default shard group duration |
|---|---|
| less than 2 days | 1h |
| between 2 days and 6 months | 1d |
| greater than 6 months | 7d |
For more information, see InfluxDB Shards and shard groups.
{{% /show-in %}}
Below are reasons why data may not be dropped immediately after updating the retention period of a bucket:
{{% show-in "v2" %}}-
InfluxDB drops shard groups, not individual points. Shard groups cover a specific time interval assigned to the shard group on creation. The retention service will only delete a shard group when the entire time range covered by the shard group is beyond the bucket retention period.
If the bucket's new retention period is less than the old shard group duration and InfluxDB is currently writing data to the old, longer shard group, the the retention service will not drop old shard group until its assigned interval is fully expired.
{{% /show-in %}}
For more information, see Data retention.
<!-{{% show-in "cloud,cloud-serverless" %}}-
{{% /show-in %}} -->
InfluxDB stores all integers as signed 64bit integers.
Minimum integer: -9223372036854775808
Maximum integer: 9223372036854775807
Values close to but within those limits may lead to unexpected behavior. Some query operations convert 64bit integers to 64bit float values which can cause overflow issues.
InfluxDB uses 64bit integers to represent Unix nanosecond timestamps.
Minimum timestamp: -9223372036854775806 or 1677-09-21T00:12:43.145224194Z
Maximum timestamp: 9223372036854775806 or 2262-04-11T23:47:16.854775806Z
Timestamps outside that range return a parsing error.
Flux type-conversion functions let you change a fields data type at query time. However, you cannot change the type of a field on disk. Below are some possible workarounds:
Copy a field to a new field as a different type. The example below does the following:
example-string-field.example-boolean-field.from(bucket: "example-bucket")
|> range(start: -30d)
|> filter(fn: (r) => r._measurement == "exampled-measurement")
|> filter(fn: (r) => r._field == "example-string-field")
|> toBool()
|> set(key: "_field", value: "example-boolean-field")
|> to(bucket: "example-bucket")
Copy a field to a new bucket as a different type. The example below does the following:
example-int-field from the example-bucket-1 bucket.example-float-field.example-bucket-2 bucket.from(bucket: "example-bucket-1")
|> range(start: -30d)
|> filter(fn: (r) => r._measurement == "exampled-measurement")
|> filter(fn: (r) => r._field == "example-int-field")
|> toFloat()
|> set(key: "_field", value: "example-float-field")
|> to(bucket: "example-bucket-2")
Field values can be floats, integers, strings, or Booleans. Field value types cannot differ within a shard, but they can differ across shards.
The
SELECT statement
returns all field values if all values have the same type.
If field value types differ across shards, InfluxDB first performs any
applicable cast
operations and then returns all values with the type that occurs first in the
following list: float, integer, string, Boolean.
If your data have field value type discrepancies, use the syntax
<field_key>::<type> to query the different data types.
The measurement just_my_type has a single field called my_field.
my_field has four field values across four different shards, and each value has
a different data type (float, integer, string, and Boolean).
SELECT * returns only the float and integer field values.
Note that InfluxDB casts the integer value to a float in the response.
SELECT * FROM just_my_type
name: just_my_type
------------------
time my_field
2016-06-03T15:45:00Z 9.87034
2016-06-03T16:45:00Z 7
SELECT <field_key>::<type> [...] returns all value types.
InfluxDB outputs each value type in its own column with incremented column names.
Where possible, InfluxDB casts field values to another type;
it casts the integer 7 to a float in the first column, and it
casts the float 9.879034 to an integer in the second column.
InfluxDB cannot cast floats or integers to strings or Booleans.
SELECT "my_field"::float,"my_field"::integer,"my_field"::string,"my_field"::boolean FROM just_my_type
name: just_my_type
------------------
time my_field my_field_1 my_field_2 my_field_3
2016-06-03T15:45:00Z 9.87034 9
2016-06-03T16:45:00Z 7 7
2016-06-03T17:45:00Z a string
2016-06-03T18:45:00Z true
SHOW FIELD KEYS returns every data type, across every shard, associated with
the field key.
The measurement just_my_type has a single field called my_field.
my_field has four field values across four different shards, and each value has
a different data type (float, integer, string, and Boolean).
SHOW FIELD KEYS returns all four data types:
> SHOW FIELD KEYS
name: just_my_type
fieldKey fieldType
-------- ---------
my_field float
my_field string
my_field integer
my_field boolean
In line protocol, identify integers with a trailing i and unsigned integers
with a trailing u. Without these, numeric field values are parsed as floats.
# Integer
value=100i
# Unsigned integer
value=100u
# Float
value=100
InfluxDB uniquely identifies a point by its measurement, tag set, and timestamp. If you submit a new point with the same measurement, tag set, and timestamp as an existing point, InfluxDB unions the old field with the new field set, and any ties go to the new field set.
For more information, see Handle duplicate data points.
InfluxDB line protocol relies on line feed (\n, which is ASCII 0x0A) to
indicate the end of one line and the beginning of a new line.
Files or data that use a newline character other than \n will result in errors
similar to bad timestamp or unable to parse.
{{% note %}}
Windows uses carriage return and line feed (\r\n) as the newline character which
will result in an error if you manually write line protocol on a Windows machine.
Strip out any carriage returns (\r) before submitting the line protocol to the
InfluxDB write API.
{{% /note %}}
Line protocol quote usage guidelines are provided in the line protocol documentation.
Yes. Timestamp precision affects ingest performance. The more precise the timestamp, the longer it takes to write the point. To maximize performance, use the coarsest possible timestamp precision when writing data to InfluxDB. However, if too coarse, you risk writing points from the same series with the same timestamp, which would be treated as duplicate points.
{{% show-in "v2" %}}
For sparse historical data, we recommend:
Use a longer shard group duration on the bucket you're writing historical data to. Historical shard group durations can and should cover several years. If your historical data spans many years, but your bucket's shard group duration is 1 week, InfluxDB will create many shards, negatively affecting overall performance.
Temporarily lower the
storage-cache-snapshot-write-cold-duration configuration setting
while ingesting historical data.
The default setting (10m) can cause the system cache all of your data for every shard.
Temporarily lowering the storage-cache-snapshot-write-cold-duration setting
to 10s while you write the historical data makes the process more efficient.
{{% /show-in %}}
A SELECT statement in InfluxQL returns data with a column for each queried tag and field.
The Flux from() function returns
data with a column for each tag as well as a _field column that contains the
field key. Each field is grouped into a different table.
To structure each field as a column, use either pivot()
or schema.fieldsAsCols().
{{< code-tabs-wrapper >}} {{% code-tabs %}} pivot() schema.fieldsAsCols {{% /code-tabs %}} {{% code-tab-content %}}
exampleData
|> pivot(rowKey: ["_time"], columnKey: ["_field"], valueColumn: "_value")
{{% /code-tab-content %}} {{% code-tab-content %}}
import "influxdata/influxdb/schema"
exampleData
|> schema.fieldsAsCols()
{{% /code-tab-content %}} {{< /code-tabs-wrapper >}}
| _measurement | sensor_id | location | _field | _time | _value |
|---|---|---|---|---|---|
| machine | abc123 | station20 | temp | 2022-01-01T00:00:00Z | 150.1 |
| machine | abc123 | station20 | temp | 2022-01-01T00:00:10Z | 152.8 |
| machine | abc123 | station20 | temp | 2022-01-01T00:00:20Z | 153.3 |
| _measurement | sensor_id | location | _field | _time | _value |
|---|---|---|---|---|---|
| machine | abc123 | station20 | flow | 2022-01-01T00:00:00Z | 12.2 |
| machine | abc123 | station20 | flow | 2022-01-01T00:00:10Z | 14.9 |
| machine | abc123 | station20 | flow | 2022-01-01T00:00:20Z | 16.1 |
| _measurement | sensor_id | location | _time | temp | flow |
|---|---|---|---|---|---|
| machine | abc123 | station20 | 2022-01-01T00:00:00Z | 150.1 | 12.2 |
| machine | abc123 | station20 | 2022-01-01T00:00:10Z | 152.8 | 14.9 |
| machine | abc123 | station20 | 2022-01-01T00:00:20Z | 153.3 | 16.1 |
To compare multiple field values and derive a state:
Query all fields necessary to derive a state.
Use pivot() or schema.fieldsAsCols() to pivot fields into columns.
Use map() to iterate over each input row assign a new column value based
on values in the field columns.
The fn parameter of map() defines a
functions that outputs a record for each input row. Use conditional
logic to assign a state.
from(bucket: "example-bucket")
|> range(start: -1h)
|> filter(fn: (r) => r._measurement == "example-measurement")
|> filter(fn: (r) => r._field == "field1" or r._field == "field2")
|> pivot(rowKey: ["_time"], columnKey: ["_field"], valueColumn: "_value")
|> map(
fn: (r) =>
({r with state:
if r.field1 > 90 and r.field2 < 10 then
"critical"
else if r.field1 > 70 and r.field2 < 30 then
"warning"
else if r.field1 > 40 and r.field2 < 60 then
"info"
else
"ok",
}),
)
{{% show-in "cloud,cloud-serverless" %}}
{{% /show-in %}}
{{% show-in "v2" %}}
{{% /show-in %}}
Using InfluxQL with InfluxDB {{< current-version >}} is made possible by the
v1 compatibility API which replicates
the /query endpoint from InfluxDB 1.x. This allows all InfluxDB v1-compatible
clients to work with InfluxDB {{< current-version >}}. However, InfluxQL relies
on a database and retention policy data model doesn't exist in InfluxDB
{{< current-version >}}, but has been replaced by buckets.
InfluxDB {{< current-version >}} lets you map unique database and retention policy combinations used in InfluxQL to specific buckets using DBRP mappings.
For detailed instructions on using InfluxQL with InfluxDB {{< current-version >}} and configuring DBRP mapping, see Query with InfluxQL.
InfluxQL does not support mathematical operations within functions. Use a subquery to perform the mathematical calculation.
For example, InfluxQL does not support the following syntax:
SELECT MEAN("dogs" - "cats") from "pet_daycare"
Instead, use a subquery to get the same result:
SELECT MEAN("difference") FROM (SELECT "dogs" - "cat" AS "difference" FROM "pet_daycare")
In InfluxQL, epoch 0 (1970-01-01T00:00:00Z) is often used as a null timestamp equivalent.
If you request a query that has no timestamp to return, such as an aggregation
function with an unbounded time range, InfluxDB returns epoch 0 as the timestamp.
The following InfluxQL functions support nesting:
COUNT() with DISTINCT()CUMULATIVE_SUM()DERIVATIVE()DIFFERENCE()ELAPSED()MOVING_AVERAGE()NON_NEGATIVE_DERIVATIVE()HOLT_WINTERS() and HOLT_WINTERS_WITH_FIT()For information on how to use subqueries as substitutes for nested functions, see InfluxQL data exploration.
GROUP BY time() queries?The time intervals returned by GROUP BY time() queries conform to the InfluxDB
database's preset time windows or to the user-specified
offset interval.
For example, the following query calculates the average value of sunflowers between
6:15pm and 7:45pm and groups those averages into one hour intervals:
SELECT mean("sunflowers")
FROM "flower_orders"
WHERE time >= '2016-08-29T18:15:00Z' AND time <= '2016-08-29T19:45:00Z' GROUP BY time(1h)
InfluxQL uses the duration specified in the GROUP BY time() clause to partition
data based on time. Preset time window boundaries fall on the duration unit specified.
For example:
| GROUP BY time() duration | Resulting window boundaries |
|---|---|
| 1s | 00:00:00 - 00:00:01, 00:00:01 - 00:00:02, etc. |
| 1m | 00:00:00 - 00:01:00, 00:01:00 - 00:02:00, etc. |
| 5m | 00:00:00 - 00:05:00, 00:05:00 - 00:10:00, etc. |
| 1h | 00:00:00 - 01:00:00, 01:00:00 - 02:00:00, etc. |
Although window boundaries may fall outside of the queried time range, only points within the queried time range are used in the calculation for each window.
As another example, the following query calculates the average value of
sunflowers between 6:15pm and 7:45pm and groups those averages into one hour intervals.
It offsets the InfluxDB database's preset time windows by 15 minutes.
SELECT mean("sunflowers")
FROM "flower_orders"
WHERE time >= '2016-08-29T18:15:00Z' AND time <= '2016-08-29T19:45:00Z' GROUP BY time(1h,15m)
---
|
offset interval
InfluxQL uses the duration and offset specified in the GROUP BY time() clause to partition
data based on time. Time boundaries begin at the specified offset.
For example:
| GROUP BY time() duration and offset | Resulting window boundaries |
|---|---|
| 1m,30s | 00:30:00 - 01:30:00, 01:30:00 - 02:30:00, etc. |
| 5m,15s | 00:00:15 - 00:05:15, 00:05:15 - 00:10:15, etc. |
| 1h,20m | 00:20:00 - 01:20:00, 01:20:00 - 02:20:00, etc. |
The most common reasons why your query returns no data or partial data:
GROUP BY time() (partial data before now() returned)InfluxDB automatically queries data in a database’s default retention policy (configured as part of a DBRP mapping). If your data is associated another retention policy, you must specify the correct retention policy to get results.
An InfluxQL query requires at least one field key in the SELECT clause.
If the SELECT clause includes only tag keys, the query returns an empty response.
For more information, see
InfluxQL Data exploration.
GROUP BY time()If your SELECT query includes a GROUP BY time() clause,
only data points between 1677-09-21 00:12:43.145224194 and
now() are returned.
If any of your data points occur after now(), specify
an alternative upper bound
in your time interval.
Avoid using the same name for a tag and field key.
If you inadvertently add the same name for a tag and field key, and then query
both together, the query results show the second key queried (tag or field)
appended with _1. To query a tag or field key appended with _1,
you must drop the appended _1 and include the syntax ::tag or ::field.
For example:
-- Query duplicate keys using the correct syntax
SELECT "leaves"::tag, "leaves"::field FROM db.rp."grape"
name: grape
time leaves leaves_1
---- -------- ----------
1574128162128468000 species 6.00
1574128238044155000 5.00
GROUP BY time() queries return timestamps that occur after now()?SELECT statements without a time range defined in the WHERE clause have a
default time range of 1677-09-21 00:12:43.145224194 to 2262-04-11T23:47:16.854775806Z UTC.
For SELECT statements that don't specify a time range but have a
GROUP BY time() clause,
the default time range is 1677-09-21 00:12:43.145224194 UTC to now().
To query data with timestamps that occur after now(), SELECT statements with
a GROUP BY time() clause must provide an alternative upper bound in the
WHERE clause.
For example:
SELECT MEAN("boards") FROM "hillvalley"
WHERE time >= '2022-01-01T00:00:00Z' AND time <= now() + 10d
GROUP BY time(12m) fill(none)
Note that the WHERE clause must provide an alternative upper bound to
override the default now() upper bound. The following query merely resets
the lower bound to now() such that the query's time range is between
now() and now():
SELECT MEAN("boards") FROM "hillvalley"
WHERE time >= now()
GROUP BY time(12m) fill(none)
For for more on time syntax in queries, see InfluxQL data Exploration.
InfluxQL does not support mathematical operators against timestamp values. Most time calculations must be carried out by the client receiving the query results.
There is limited support for using InfluxQL functions against timestamp values. The ELAPSED() function returns the difference between subsequent timestamps in a single field.
InfluxDB stores all timestamps as nanosecond values, regardless of the write precision supplied. InfluxQL silently drops trailing zeros from timestamps which obscures the initial write precision. Because InfluxDB silently drops trailing zeros on returned timestamps, the write precision is not recognizable in the returned timestamps.
Follow these general rules for quotes in InfluxQL queries:
[A-z,0-9,_],
or that are an InfluxQL keyword.
We generally recommend using double quotes on all identifiers, even if they
don't meet these criteria.-- Correctly quote usage
SELECT bikes_available FROM bikes WHERE station_id='9'
SELECT "bikes_available" FROM "bikes" WHERE "station_id"='9'
SELECT MIN("avgrq-sz") AS "min_avgrq-sz" FROM telegraf
SELECT * from "cr@zy" where "p^e"='2'
SELECT "water_level" FROM "h2o_feet" WHERE time > '2015-08-18T23:00:01.232000000Z' AND time < '2015-09-19'
-- Incorrect quote usage
SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"
SELECT * from cr@zy where p^e='2'
SELECT "water_level" FROM "h2o_feet" WHERE time > "2015-08-18T23:00:01.232000000Z" AND time < "2015-09-19"
WHERE OR time clause returning empty results?InfluxQL does not support using OR in the WHERE clause to specify multiple
time ranges and returns an empty response if multiple are specified.
For example, the following query will return an empty response:
SELECT * FROM "absolutismus"
WHERE time = '2016-07-31T20:07:00Z' OR time = '2016-07-31T23:07:17Z'
fill(previous) return empty results?fill(previous) doesn't fill a null value if there is no previous value inside
the queried time range.
Use the :: syntax to specify if the key is a field key or tag key. For example:
SELECT * FROM "candied" WHERE "almonds"::field > 51
SELECT * FROM "candied" WHERE "almonds"::tag='true'
InfluxQL does not support querying multiple measurements All data must be under a single measurement to query it together. To perform cross-measurement queries, use Flux.
No, it doesn't. There is a only a negligible difference between the following queries:
SELECT ... FROM ... WHERE time > 'timestamp1' AND time < 'timestamp2'
SELECT ... FROM ... WHERE time < 'timestamp2' AND time > 'timestamp1'
In your WHERE clause, specify an empty or null tag value with ''. For example:
SELECT * FROM "vases" WHERE priceless=''
{{% show-in "cloud,cloud-serverless" %}}
This error indicates you are exceeding the Total query time global limit for your organization. Potential causes include:
If you are encountering this error due to a single long-running query, the query and potentially your schema should be analyzed for optimization. The following resources may help:
If you are encountering this error due to the number of concurrent queries, try delaying or staggering queries so they don't all run at the same time.
{{% /show-in %}}
{{% show-in "v2" %}}
No. InfluxDB {{< current-version >}} does not support deleting data by field.
{{% /show-in %}}
{{% show-in "cloud,cloud-serverless" %}}
Yes. InfluxDB Cloud supports deleting data by field.
Use the _field label in your delete predicate
to identify the field to delete.
_field == "example-field"
{{% /show-in %}}
Yes. InfluxDB {{< current-version >}} supports deleting data by measurement.
Use the _measurement label in your delete predicate
to identify the measurement to delete.
_measurement == "example-measurement"
No. InfluxDB {{< current-version >}} does not support deleting multiple measurements in a single delete request. To delete multiple measurements, issue a delete request for each measurement.
It is not necessary to verify delete operations once they have been submitted to the queue.
The /api/v2/delete endpoint returns a 204 response when the delete request has been added to the queue.
{{% show-in "cloud,cloud-serverless" %}}Because the delete queue executes asynchronously, there isn't a way to accurately
predict when the delete operation will be performed at the storage layer.{{% /show-in %}}
If you wish to verify a delete has occurred, try to query the deleted data. If the query returns results, the data has not been fully deleted.
When you retry a task that uses relative time ranges, it will query the original
time range of the task execution (run).
Whenever a task executes, InfluxDB sets the now option
in the task to the scheduled execution time of the task.
When using range()
or other functions that support relative duration values, these duration values
are relative to now(), which returns the
value of the now option. Every task run has a unique now option based on
the time the run was scheduled to execute.
Series cardinality is the total number of unique {{% show-in "cloud,cloud-serverless" %}}measurement, tag set, and field key combinations{{% /show-in %}} {{% show-in "v2" %}}measurement and tag set combinations{{% /show-in %}} (series) stored on disk and indexed in memory.
{{% show-in "v2" %}}
InfluxDB maintains an in-memory index of every series. As the number of unique series grows, so does the memory usage. High series cardinality can force the host operating system to kill the InfluxDB process with an out of memory (OOM) exception.
{{% /show-in %}}
{{% show-in "cloud,cloud-serverless" %}}
InfluxDB maintains an in-memory index of every series. As the number of unique series grows, it can negatively affect query performance. Each InfluxDB Cloud organization has a series cardinality limit to prevent runaway cardinality. For information about adjusting cardinality limits, see How do I increase my organization’s rate limits and quotas?.
{{% /show-in %}}
Use influxdb.cardinality() in Flux
or SHOW SERIES CARDINALITY
in InfluxQL to measure the series cardinality in a bucket.
See Resolve high series cardinality
for information about reducing series cardinality.
{{% show-in "v2" %}}
To remove a series from an index:
influx CLI or InfluxDB {{< current-version >}} API to delete points
associated with the series. See Delete data
for more information.influxd inspect build-tsi tool
to rebuild your index.{{% /show-in %}}