FAQ

Series and series cardinality

• How do I perform modeling and what are the precautions?

• Why is series cardinality important?

Administration

• What should I note for system stability?

• How do I view the disk usage for a measurement?

• How do I delete data efficiently and securely?

• Why does a modified retention policy not take effect?

• Why are services frequently interrupted?

• Why is memory usage high and do I need to upgrade?

• Is storage scale-in supported?

• Does expanding a disk cause a restart?

• How long does a restart take?

• Is the built-in Grafana for InfluxDB supported?

• Why do I get an ip block error on access?

• How do I identify the version of TSDB for InfluxDB®?

• What is the relationship between a shard group duration and a retention policy?

• Why is no data lost after I change a retention policy?

• Why can TSDB for InfluxDB® not parse the microsecond unit?

Data query

• How do I troubleshoot slow queries?

• What determines the time interval returned by a GROUP BY time() query?

• Why does a query return no data or only partial data?

• Why does a GROUP BY time() query not return timestamps that occur after now()?

• Can I perform mathematical operations on timestamps?

• Can I identify the write precision from returned timestamps?

• When should I use single quotation marks and double quotation marks when I query data?

• Why is data lost after I create a new DEFAULT retention policy?

• Why does a query with a WHERE OR time clause return an empty result?

• Why does fill(previous) return an empty result?

• Why does an INTO query lose data?

• How do I query data when a tag key and a field key have the same name?

• How do I query data across measurements?

• Is the order of timestamps important?

• How do I SELECT data that has a tag but no tag value?

Data writing

• Why does write jitter occur periodically?

• Precautions for line protocol writes

• Why is data not visible after it is written?

• Why does writing not resume after disk space is freed up from a full state?

• How do I write an integer field value?

• How does TSDB for InfluxDB® handle duplicate data points?

• What line feed does the HTTP API require?

• What words and characters should I avoid when I write data to TSDB for InfluxDB®?

• When should I use single quotation marks and double quotation marks when I write data?

• Is timestamp precision important?

Command-line interface (Influx CLI)

• Why can I not connect to TSDB for InfluxDB® using the command-line interface?

• How do I make the Influx CLI for TSDB for InfluxDB® return human-readable timestamps?

• How can a non-admin user use USE to specify a database?

• How do I use the Influx CLI for TSDB for InfluxDB® to write data to a non-default retention policy?

Data types

• Why can I not query a Boolean field value?

• How does TSDB for InfluxDB® handle field type discrepancies across shards?

• What are the minimum and maximum integers that TSDB for InfluxDB® can store?

• What are the minimum and maximum timestamps that TSDB for InfluxDB® can store?

• How do I know the data type stored in a field?

• Can I change the data type of a field?

InfluxQL functions

• How do I perform mathematical operations in functions?

• Why does a query return epoch 0 as a timestamp?

• Which InfluxQL functions support nesting?

InfluxDB data migration

• How do I migrate a self-managed InfluxDB to the cloud?

• How do I migrate data between different InfluxDB instances in the cloud?

• How do I migrate data from InfluxDB to LindormTSDB?

Why is series cardinality important?

TSDB for InfluxDB® maintains an in-memory index per series. As series count grows, so does RAM usage. Excessively high cardinality can trigger an out-of-memory (OOM) exception that terminates the process. See InfluxQL Reference for InfluxQL commands related to series cardinality.

How do I perform modeling and what are the precautions?

Keep the number of time series under one million. For massive time series scenarios, use Introduction to LindormTSDB. Review the InfluxDB schema and data layout guide. InfluxDB indexes tags to speed up queries, but too many tags cause series inflation that slows reads and writes. Key considerations:

• Avoid using tags with high cardinality values, such as IDs, hash values, and random strings.

• Do not store data in measurement names or tag names. Store data in tags and fields.

• Do not store multiple pieces of information in one tag. Split the information into multiple tags.

• If you frequently use a field in a GROUP BY clause, model it as a tag.

How do I identify the version of TSDB for InfluxDB®?

Use one of the following methods:

• curl /ping

  $ curl -i 'https://<endpoint>:3242/ping?u=<username>&p=<password>'
  HTTP/1.1 204 No Content
  Content-Type: application/json
  X-Influxdb-Build: OSS
  X-Influxdb-Version: 1.7.x

• Start the command-line interface for TSDB for InfluxDB®

  $ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242
  
  Connected to https://<endpoint>:3242 version 1.7.x

What is the relationship between a shard group duration and a retention policy?

TSDB for InfluxDB® stores data in shard groups. A shard group covers a specific time interval. TSDB for InfluxDB® determines the time interval by checking the DURATION of the relevant retention policy (RP). The following table lists the default relationship between the DURATION of an RP and the time interval of a shard group:

Use SHOW RETENTION POLICIES to view the shard group duration of a retention policy.

Why is no data lost after I change a retention policy?

Data may not be lost immediately after you change a retention policy for the following reasons:

• First possible reason (most likely scenario): By default, TSDB for InfluxDB® checks and enforces RPs every 30 minutes. You may need to wait for the next RP check before TSDB for InfluxDB® deletes data that is outside the new DURATION of the RP.

• Second possible reason: Changing the DURATION and SHARD DURATION of an RP can lead to unexpected data retention. TSDB for InfluxDB® stores data in shard groups. Each shard group covers a specific RP and time interval. When TSDB for InfluxDB® enforces an RP, it deletes the entire shard group, not individual data points. TSDB for InfluxDB® cannot split shard groups. If the new DURATION of the RP is less than the old SHARD DURATION, and TSDB for InfluxDB® is writing data to an old shard group with a longer DURATION, the system is forced to store all data in that shard group. This happens even if some data in the shard group is outside the new DURATION. Once all data in the shard group is outside the new DURATION, TSDB for InfluxDB® deletes the entire shard group. The system then starts writing data to shard groups with the new, shorter SHARD DURATION. This avoids further unexpected data retention.

Why can TSDB for InfluxDB® not parse the microsecond unit?

The syntax for specifying the microsecond time unit differs for writing, querying, and setting precision in the TSDB for InfluxDB® command-line interface (Influx CLI). The following table shows the supported syntax for each category:

How do I troubleshoot slow queries?

Slow queries typically result from scanning too many time series or too much raw data. Add tag and time range filters to every query. Use the EXPLAIN ANALYZE command to diagnose performance: execution_time reflects data reading and computation, while planning_time reflects series scanning.

What determines the time interval returned by a GROUP BY time() query?

The time interval returned by a GROUP BY time() query matches the preset time buckets of TSDB for InfluxDB® or a user-specified offset interval. See the following examples:

• Preset time buckets

  The following query calculates the average of sunflowers between 6:15 PM and 7:45 PM and groups the averages by one hour:

  SELECT mean("sunflowers")
  FROM "flower_orders"
  WHERE time >='2016-08-29T18:15:00Z' AND time <='2016-08-29T19:45:00Z' GROUP BY time(1h)

  The following results show how TSDB for InfluxDB® maintains its preset time buckets.

  In this example, 6 PM is a preset time bucket, and 7 PM is also a preset time bucket. Because the WHERE clause specifies the query's time range, data before 6:15 PM is not included when calculating the average for the 6 PM time bucket. However, the data used to calculate the average for the 6 PM time bucket must occur within the 6 PM hour. The same applies to the 7 PM time bucket. The data used to calculate the average for the 7 PM time bucket must occur within the 7 PM hour. The dashed lines show the data points used to calculate each average.

  Note that although the first timestamp in the result is 2016-08-29T18:00:00Z, the query result for that time bucket does not include data that occurs before 2016-08-29T18:15:00Z, which is the start time specified in the WHERE clause.

  Raw data:

  name: flower_orders                                name: flower_orders
  —————————-------------------
  time                    sunflowers                 time                  mean
  2016-08-29T18:00:00Z    34                         2016-08-29T18:00:00Z    22.332
  |--|                                               2016-08-29T19:00:00Z    62.75
  2016-08-29T18:15:00Z    |28|
  2016-08-29T18:30:00Z    |19|
  2016-08-29T18:45:00Z    |20|
  |--|
  |--|
  2016-08-29T19:00:00Z    |56|
  2016-08-29T19:15:00Z    |76|
  2016-08-29T19:30:00Z    |29|
  2016-08-29T19:45:00Z    |90|
  |--|
  2016-08-29T20:00:00Z    70

• Offset interval

  The following query calculates the average of sunflowers between 6:15 PM and 7:45 PM and groups the averages by one hour. The query also offsets the preset time buckets of TSDB for InfluxDB® 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

  In this example, the user-specified offset interval shifts the preset time buckets of TSDB for InfluxDB® forward by 15 minutes. Now, the average for the 6 PM time bucket includes data between 6:15 PM and 7:15 PM. The average for the 7 PM time bucket includes data between 7:15 PM and 8:15 PM. The dashed lines show the data points used to calculate each average.

  Note that the first timestamp in the result is now 2016-08-29T18:15:00Z, not 2016-08-29T18:00:00Z.

  Raw data and results:

  name: flower_orders                                name: flower_orders
  —————————-------------------
  time                    sunflowers                 time                  mean
  2016-08-29T18:00:00Z    34                         2016-08-29T18:15:00Z    30.75
  |--|                                               2016-08-29T19:15:00Z    65
  2016-08-29T18:15:00Z    |28|
  2016-08-29T18:30:00Z    |19|
  2016-08-29T18:45:00Z    |20|
  2016-08-29T19:00:00Z    |56|
  |--|
  |--|
  2016-08-29T19:15:00Z    |76|
  2016-08-29T19:30:00Z    |29|
  2016-08-29T19:45:00Z    |90|
  2016-08-29T20:00:00Z    |70|
  |--|

Why does a query return no data or only partial data?

Common reasons:

• Retention policy

  The first and most common explanation relates to retention policies (RPs). TSDB for InfluxDB® automatically queries data from the database's DEFAULT RP. If your data is not stored in the default RP, TSDB for InfluxDB® does not return any results unless you explicitly specify the RP to use.

• Tag key in the SELECT clause

  The SELECT clause must include at least one field key for the query to return data. If the SELECT clause contains only one or more tag keys, the query returns an empty result. For more information, see Data exploration.

• Query time range

  Another possible explanation is related to the time range of the query. By default, most SELECT queries cover the time range between 1677-09-21 00:12:43.145224194 UTC and 2262-04-11T23:47:16.854775806Z UTC. A SELECT query that includes a GROUP BY time() clause, however, covers a time range between 1677-09-21 00:12:43.145224194 and now(). If your data occurs after now(), the GROUP BY time() query does not cover data that occurs after now(). If a query statement includes a GROUP BY time() clause and has data that occurs after now(), you need to provide an upper bound for the time range.

• Identifier name

  The last common explanation relates to the schema, where a field and a tag have the same name. If a field key and a tag key are identical, the field is prioritized in all queries. In the query, you need to use the ::tag syntax to specify the tag key.

Why does a GROUP BY time() query not return timestamps that occur after now()?

The default time range for most SELECT statements is between 1677-09-21 00:12:43.145224194 UTC and 2262-04-11T23:47:16.854775806Z UTC. For SELECT statements with a GROUP BY time() clause, the default time range is between 1677-09-21 00:12:43.145224194 and now().

To query data with timestamps that occur after now(), a SELECT statement with a GROUP BY time() clause must provide an upper time bound in the WHERE clause.

In the following example, the first query covers data with timestamps between 2015-09-18T21:30:00Z and now(). The second query covers data with timestamps between 2015-09-18T21:30:00Z and 180 weeks after now().

> SELECT MEAN("boards") FROM "hillvalley" WHERE time >='2015-09-18T21:30:00Z' GROUP BY time(12m) fill(none)


> SELECT MEAN("boards") FROM "hillvalley" WHERE time >='2015-09-18T21:30:00Z' AND time <= now()+180w GROUP BY time(12m) fill(none)

Note that the WHERE clause must provide an upper time bound to override the default now() upper bound. The following query simply resets the lower bound to now(), making the query's time range between now() and now():

> SELECT MEAN("boards") FROM "hillvalley" WHERE time >= now() GROUP BY time(12m) fill(none)
>

Time syntax details: Data exploration.

Can I perform mathematical operations on timestamps?

TSDB for InfluxDB® does not support mathematical operations on timestamps. Perform time calculations on the client side.

TSDB for InfluxDB® offers limited support for using InfluxQL functions on timestamps. The ELAPSED() function returns the difference between timestamps in a single field.

Can I identify the write precision from returned timestamps?

TSDB for InfluxDB® stores all timestamps in nanoseconds, regardless of write precision. The database silently drops trailing zeros from returned timestamps, making it difficult to identify the original write precision.

In the following example, the tags precision_supplied and timestamp_supplied show the time precision and timestamp that the user provided when writing the data. Because TSDB for InfluxDB® silently drops the trailing zeros from the returned timestamp, it is difficult to identify the write precision from the returned timestamp.

name: trails
-------------
time                  value  precision_supplied  timestamp_supplied
1970-01-01T01:00:00Z  3      n                   3600000000000
1970-01-01T01:00:00Z  5      h                   1
1970-01-01T02:00:00Z  4      n                   7200000000000
1970-01-01T02:00:00Z  6      h                   2

When should I use single quotation marks and double quotation marks when I query data?

Use single quotation marks to enclose string values, such as tag values. Do not use single quotation marks to enclose identifiers. Identifiers include database names, retention policy names, usernames, measurement names, tag keys, and field keys.

Use double quotation marks to enclose identifiers if they start with a digit, contain characters other than [A-z,0-9,_], or are an InfluxQL keyword. If an identifier does not fall into one of these categories, you do not need to enclose it in double quotation marks. However, we recommend that you do so.

Examples:

Valid query: SELECT bikes_available FROM bikes WHERE station_id='9'

Valid query: SELECT "bikes_available" FROM "bikes" WHERE "station_id"='9'

Valid query: SELECT MIN("avgrq-sz") AS "min_avgrq-sz" FROM telegraf

Valid query: SELECT * from "cr@zy" where "p^e"='2'

Invalid query: SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"

Invalid query: SELECT * from cr@zy where p^e='2'

Use single quotation marks to enclose date time strings. If you use double quotation marks to enclose date time strings, TSDB for InfluxDB® returns an error (ERR: invalid operation: time and *influxql.VarRef are not compatible).

Example:

Valid query: SELECT "water_level" FROM "h2o_feet" WHERE time > '2015-08-18T23:00:01.232000000Z' AND time < '2015-09-19'

Invalid query: SELECT "water_level" FROM "h2o_feet" WHERE time > "2015-08-18T23:00:01.232000000Z" AND time < "2015-09-19"

Time syntax details: Data exploration.

Why is data lost after I create a new DEFAULT retention policy?

When you create a new default retention policy (RP) in a database, the data in the old default RP remains in the old RP. Queries that do not specify an RP will automatically query data from the new default RP, and all old data may appear to be lost. To query the old data, you must fully qualify the data in the query. See the following example:

All data in the measurement fleeting belongs to the default RP, which is named one_hour:

> SELECT count(flounders) FROM fleeting
name: fleeting
--------------
time                     count
1970-01-01T00:00:00Z     8

Now we create a new default RP (two_hour) and execute the same query:

> SELECT count(flounders) FROM fleeting
>

To query the old data, we must specify the old default RP by fully qualifying fleeting:

> SELECT count(flounders) FROM fish.one_hour.fleeting
name: fleeting
--------------
time                     count
1970-01-01T00:00:00Z     8

Why does a query with a WHERE OR time clause return an empty result?

TSDB for InfluxDB® does not support OR in the WHERE clause to specify multiple time ranges. If a query's WHERE clause uses OR to specify multiple time ranges, TSDB for InfluxDB® does not return any results.

Example:

> SELECT * FROM "absolutismus" WHERE time ='2016-07-31T20:07:00Z' OR time ='2016-07-31T23:07:17Z'
>

Why does fill(previous) return an empty result?

If the previous value is outside the query's time range, fill(previous) does not fill a value for that time bucket.

In the following example, TSDB for InfluxDB® does not fill a value for the time bucket 2016-07-12T16:50:20Z-2016-07-12T16:50:30Z with the value from the time bucket 2016-07-12T16:50:00Z-2016-07-12T16:50:10Z because the query's time range does not include the earlier time bucket.

Sample data:

> SELECT * FROM "cupcakes"
name: cupcakes
--------------
time                   chocolate
2016-07-12T16:50:00Z   3
2016-07-12T16:50:10Z   2
2016-07-12T16:50:40Z   12
2016-07-12T16:50:50Z   11

GROUP BY time() query:

> SELECT max("chocolate") FROM "cupcakes" WHERE time >='2016-07-12T16:50:20Z' AND time <='2016-07-12T16:51:10Z' GROUP BY time(20s) fill(previous)
name: cupcakes
--------------
time                   max
2016-07-12T16:50:20Z
2016-07-12T16:50:40Z   12
2016-07-12T16:51:00Z   12

Why does an INTO query lose data?

By default, an INTO query converts tags from the source data into fields in the newly written data. This can cause TSDB for InfluxDB® to overwrite data points that were previously differentiated by a tag. Include GROUP BY * in all INTO queries to preserve tags in the newly written data.

> SELECT * FROM "french_bulldogs"
name: french_bulldogs
---------------------
time                  color  name
2016-05-25T00:05:00Z  peach  nugget
2016-05-25T00:05:00Z  grey   rumple
2016-05-25T00:10:00Z  black  prince

• INTO query without GROUP BY *

  An INTO query without a GROUP BY * clause converts the tag color into a field in the newly written data. In the source data, the data points nugget and rumple are differentiated only by the tag color. Once color becomes a field, TSDB for InfluxDB® considers the data points nugget and rumple to be duplicates. It overwrites the data point nugget with the data point rumple.

  > SELECT * INTO "all_dogs" FROM "french_bulldogs"
  name: result
  ------------
  time                  written
  1970-01-01T00:00:00Z  3
  
  > SELECT * FROM "all_dogs"
  name: all_dogs
  --------------
  time                  color  name
  2016-05-25T00:05:00Z  grey   rumple                <---- no more nugget
  2016-05-25T00:10:00Z  black  prince

• INTO query with GROUP BY *

  An INTO query with a GROUP BY * clause preserves the tag color in the newly written data. In this case, the data points nugget and rumple remain distinct data points, and TSDB for InfluxDB® does not overwrite any data.

  > SELECT "name" INTO "all_dogs" FROM "french_bulldogs" GROUP BY *
  name: result
  ------------
  time                  written
  1970-01-01T00:00:00Z  3
  
  > SELECT * FROM "all_dogs"
  name: all_dogs
  --------------
  time                  color  name
  2016-05-25T00:05:00Z  peach  nugget
  2016-05-25T00:05:00Z  grey   rumple
  2016-05-25T00:10:00Z  black  prince

How do I query data when a tag key and a field key have the same name?

Use the :: syntax to specify whether a key is a field key or a tag key. Sample data:

> INSERT candied,almonds=true almonds=50,half_almonds=51 1465317610000000000
> INSERT candied,almonds=true almonds=55,half_almonds=56 1465317620000000000

> SELECT * FROM "candied"
name: candied
-------------
time                   almonds  almonds_1  half_almonds
2016-06-07T16:40:10Z   50       true       51
2016-06-07T16:40:20Z   55       true       56

• Specify the key is a field

  > SELECT * FROM "candied" WHERE "almonds"::field > 51
  name: candied
  -------------
  time                   almonds  almonds_1  half_almonds
  2016-06-07T16:40:20Z   55       true       56

• Specify the key is a tag

  > SELECT * FROM "candied" WHERE "almonds"::tag='true'
  name: candied
  -------------
  time                   almonds  almonds_1  half_almonds
  2016-06-07T16:40:10Z   50       true       51
  2016-06-07T16:40:20Z   55       true       56

How do I query data across measurements?

Cross-measurement math or grouping is not supported. All data must reside in the same measurement. TSDB for InfluxDB® is not a relational database — avoid mapping data across measurements.

Is the order of timestamps important?

No. Test results show that there is very little difference in the time it takes for TSDB for InfluxDB® to complete the following queries:

SELECT ... FROM ... WHERE time > 'timestamp1' AND time < 'timestamp2'
SELECT ... FROM ... WHERE time < 'timestamp2' AND time > 'timestamp1'

How do I SELECT data that has a tag but no tag value?

Use '' to specify an empty tag value. For example:

> SELECT * FROM "vases" WHERE priceless=''
name: vases
-----------
time                   origin   priceless
2016-07-20T18:42:00Z   8

How do I write an integer field value?

When writing an integer, append an i to the end of the field value. If you do not append an i, TSDB for InfluxDB® treats the field value as a floating-point number.

Write an integer: value=100i. Write a floating-point number: value=100.

How does TSDB for InfluxDB® handle duplicate data points?

A data point is uniquely identified by its measurement name, tag set, and timestamp. If you submit a data point that has the same measurement, tag set, and timestamp as an existing data point, but a different field set, the field set of the data point becomes the union of the old and new field sets. If any conflicts exist, the new field set takes precedence. This is the expected behavior.

For example:

Old data point: cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

New data point: cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000000

After you submit the new data point, TSDB for InfluxDB® overwrites the value of val_1 with the new field value, and the value of val_2 is retained:

> SELECT * FROM "cpu_load" WHERE time =1234567890000000
name: cpu_load
--------------
time                      az        hostname   val_1   val_2
1970-01-15T06:56:07.89Z   us_west   server02   5.247

To store both data points, you can:

• Introduce a new tag to ensure uniqueness.

  Old data point: cpu_load,hostname=server02,az=us_west,uniq=1 val_1=24.5,val_2=7 1234567890000000

  New data point: cpu_load,hostname=server02,az=us_west,uniq=2 val_1=5.24 1234567890000000

  After writing the new data point to TSDB for InfluxDB®:

  > SELECT * FROM "cpu_load" WHERE time =1234567890000000
  name: cpu_load
  --------------
  time                      az        hostname   uniq   val_1   val_2
  1970-01-15T06:56:07.89Z   us_west   server02   124.57
  1970-01-15T06:56:07.89Z   us_west   server02   25.24

• Increment the timestamp by one nanosecond.

  Old data point: cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

  New data point: cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000001

  After writing the new data point to TSDB for InfluxDB®:

  > SELECT * FROM "cpu_load" WHERE time >=1234567890000000 and time <=1234567890000001
  name: cpu_load
  --------------
  time                             az        hostname   val_1   val_2
  1970-01-15T06:56:07.89Z          us_west   server02   24.57
  1970-01-15T06:56:07.890000001Z   us_west   server02   5.24

What line feed does the HTTP API require?

The line protocol for TSDB for InfluxDB® depends on the line feed character (\n, which is ASCII 0x0A) to indicate the end of one line and the start of a new one. A file or data that uses a line feed character other than \n will cause a bad timestamp or unable to parse error.

Windows uses \r\n (carriage return + line feed), which is incompatible.

What words and characters should I avoid when I write data to TSDB for InfluxDB®?

• InfluxQL keywords

  If you use an InfluxQL keyword as an identifier, you must enclose that identifier in double quotation marks in every query. This will cause an error if you do not use double quotation marks. Identifiers are continuous query names, database names, field keys, measurement names, retention policy names, tag keys, and usernames.

• Time

  The keyword time is a special case. time can be a continuous query name, database name, measurement name, retention policy name, and username. In these cases, you do not need to enclose time in double quotation marks in a query. time cannot be a field key or a tag key. TSDB for InfluxDB® rejects writes for data that use time as a field key or tag key. For such writes, TSDB for InfluxDB® returns an error. See the following examples:

  • Write and query data with time as a measurement.

    > INSERT time value=1
    
    > SELECT * FROM time
    
    name: time
    time                            value
    ---------
    2017-02-07T18:28:27.349785384Z  1

    In TSDB for InfluxDB®, time is a valid measurement name.

  • Write and attempt to query data with time as a field key.

    > INSERT mymeas time=1
    ERR:{"error":"partial write: invalid field name: input field \"time\" on measurement \"mymeas\" is invalid dropped=1"}

    In TSDB for InfluxDB®, time is not a valid field key. The system cannot write the data point and returns a 400 error.

  • Write and attempt to query data with time as a tag key.

    > INSERT mymeas,time=1 value=1
    ERR:{"error":"partial write: invalid tag key: input tag \"time\" on measurement \"mymeas\" is invalid dropped=1"}

    In TSDB for InfluxDB®, time is not a valid tag key. The system cannot write the data point and returns a 400 error.

• Characters

  To maintain simple regular expressions and quoting, avoid using the following characters in identifiers: \ (backslash), ^ (caret), $ (dollar sign), ' (single quotation mark), " (double quotation mark), = (equal sign), and , (comma).

When should I use single quotation marks and double quotation marks when I write data?

• Avoid enclosing identifiers in quotation marks when writing with the line protocol — this complicates queries. Identifiers are continuous query names, database names, field keys, measurement names, retention policy names, subscription names, tag keys, and usernames.

  • Write a measurement with double quotation marks: INSERT "bikes" bikes_available=3. Applicable query: SELECT * FROM "\"bikes\""

  • Write a measurement with single quotation marks: INSERT 'bikes' bikes_available=3. Applicable query: SELECT * FROM "\'bikes\'"

  • Write a measurement without quotation marks: INSERT bikes bikes_available=3. Applicable query: SELECT * FROM "bikes"

• Use double quotation marks to enclose string field values.

  Write: INSERT bikes happiness="level 2". Applicable query: SELECT * FROM "bikes" WHERE "happiness"='level 2'

• Escape special characters with a backslash instead of enclosing them in quotation marks.

  Write: INSERT wacky va\"ue=4. Applicable query: SELECT "va\"ue" FROM "wacky"

Details: Line Protocol Reference.

Is timestamp precision important?

For optimal write performance, use the coarsest time precision possible.

In the following two examples, the first request uses the default precision (nanoseconds), while the second request sets the precision to seconds:

curl -i -XPOST "https://<endpoint>:3242/write?db=weather&u=<username>&p=<password>" --data-binary 'temperature,location=1 value=90 1472666050000000000'

curl -i -XPOST "https://<endpoint>:3242/write?db=weather&precision=s&u=<username>&p=<password>" --data-binary 'temperature,location=1 value=90 1472666050'

The trade-off: coarser precision increases the chance of duplicate timestamps, which may cause data overwrites.

Why can I not connect to TSDB for InfluxDB® using the command-line interface?

Confirm the following conditions one by one:

• You must have executable permissions. You can run the chmod +x ./influx command to add permissions.

• The -ssl option must be specified in the connection statement.

• For the -host option, specify only the connection string, such as ts-bp17j28j2y7pm****.influxdata.rds.aliyuncs.com. Do not add the protocol and port number.

How do I make the Influx CLI for TSDB for InfluxDB® return human-readable timestamps?

When you first connect to the Influx CLI, specify the rfc3339 precision:

$ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242 -precision rfc3339

Alternatively, specify the precision after connecting to the Influx CLI:

$ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242
Connected to https://<endpoint>:3242 version 1.7.x
> precision rfc3339

Details: Command-line interface (Influx CLI).

How can a non-admin user use USE to specify a database?

If a non-admin user has READ and WRITE permissions, or only READ permission, for a database, they can execute the USE <database_name> statement. If a non-admin user tries to use USE to specify a database for which they do not have READ and WRITE, or READ permission, the system returns an error:

ERR: Database <database_name> doesn't exist. Run SHOW DATABASES for a list of existing databases.

How do I use the Influx CLI for TSDB for InfluxDB® to write data to a non-default retention policy?

Use the syntax INSERT INTO [<database>.]<retention_policy> <line_protocol> to write data to a non-default retention policy. (This method of specifying the database and retention policy is only allowed in the Influx CLI. If you write data via HTTP, you must use the db and rp parameters to specify the database and retention policy, respectively. Specifying the retention policy is optional.) See the following example.

> INSERT INTO one_day mortality bool=true
Using retention policy one_day
> SELECT * FROM "mydb"."one_day"."mortality"
name: mortality
---------------
time                             bool
2016-09-13T22:29:43.229530864Z   true

You need to fully qualify the measurement to query data in a non-default retention policy. Use the following syntax to fully qualify a measurement:

"<database>"."<retention_policy>"."<measurement>"

Why can I not query a Boolean field value?

The syntax for writing and querying Boolean values is different.

For example, SELECT * FROM "hamlet" WHERE "bool"=True returns all data points where bool equals TRUE. However, SELECT * FROM "hamlet" WHERE "bool"=T does not return any results.

How does TSDB for InfluxDB® handle field type discrepancies across shards?

A field value can be a floating-point number, an integer, a string, or a Boolean value. Within a shard, the data type of a field value must be consistent. However, across different shards, the data type of a field value can be different.

• SELECT statement

  A SELECT statement returns all field values of the same data type by default. If the data type of a field value is not the same in different shards, TSDB for InfluxDB® first performs a type conversion, if applicable. Then, it returns all values in the following order of data types: floating-point number, integer, string, Boolean. If the type of a field value differs in your data, use the syntax <field_key>::<type> to query the different data types. See the following example:

  The measurement just_my_type has a field named my_field. my_field has four field values in four different shards, and the data type of each field value is different (floating-point number, integer, string, and Boolean, respectively).

  SELECT returns only the floating-point and integer field values. In the results, TSDB for InfluxDB® forces the integer to be converted to a floating-point number.

  > 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 data types. TSDB for InfluxDB® outputs data of each type into a separate column and uses an incrementing column name. Where possible, TSDB for InfluxDB® converts a field value to another data type. It converts the integer 7 to a floating-point number in the first column and the floating-point number 9.879034 to an integer in the second column. TSDB for InfluxDB® cannot convert a floating-point number or an integer to a string or a Boolean value.

  > 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:00Z9.870349
  2016-06-03T16:45:00Z77
  2016-06-03T17:45:00Z                         a string
  2016-06-03T18:45:00Z                                     true

• SHOW FIELD KEYS query

  SHOW FIELD KEYS returns every data type in each shard that corresponds to the field key. See the following example:

  The measurement just_my_type has a field named my_field. my_field has four field values in four different shards, and the data type of each field value is different (floating-point number, integer, string, and Boolean, respectively).

  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

What are the minimum and maximum integers that TSDB for InfluxDB® can store?

TSDB for InfluxDB® stores all integers as signed int64 data types. The minimum and maximum valid values for int64 are -9023372036854775808 and 9023372036854775807, respectively. Reference: Go builtins.

Using values that are close to the minimum or maximum integer but still within the limits may lead to unexpected results. Some functions and operators convert the int64 data type to float64 during calculation, which can cause overflow issues.

What are the minimum and maximum timestamps that TSDB for InfluxDB® can store?

The minimum timestamp is -9223372036854775806 or 1677-09-21T00:12:43.145224194Z, and the maximum timestamp is 9223372036854775806 or 2262-04-11T23:47:16.854775806Z. Timestamps outside this range return a parsing error.

How do I know the data type stored in a field?

The SHOW FIELD KEYS query also returns the data type of the field.

> SHOW FIELD KEYS FROM all_the_types
name: all_the_types
-------------------
fieldKey  fieldType
blue      string
green     boolean
orange    integer
yellow    float

Can I change the data type of a field?

TSDB for InfluxDB® offers very limited support for changing a field's data type. The syntax <field_key>::<type> supports converting a field value from an integer to a floating-point number or from a floating-point number to an integer. Conversion details are in Data exploration. You cannot convert a floating-point number or an integer to a string or a Boolean value, or vice versa.

Methods to change a field's data type:

• Write the data to a different field

  The simplest solution is to write the data with the new data type to a different field in the same series.

• Use the shard system

  Within a shard, the data type of a field value cannot be different. However, across different shards, the data type of a field value can be different.

  To change the data type of a field, a user can use the SHOW SHARDS query to identify the end_time of the current shard. If the timestamp of a data point occurs after the end_time, TSDB for InfluxDB® allows data of a different data type to be written to an existing field. For example, a field originally accepted integers, but after the end_time, the field can accept floating-point numbers.

  Note that this does not change the data type of the field in the original shard.

How do I perform mathematical operations in functions?

TSDB for InfluxDB® does not support mathematical operations within functions. Use subqueries as a workaround:

InfluxQL does not support the following syntax:

SELECT MEAN("dogs"-"cats") from "pet_daycare"

Instead, we can use a subquery to get the same result:

> SELECT MEAN("difference") FROM (SELECT "dogs"-"cat" AS "difference" FROM "pet_daycare")

Subquery details: Data exploration.

Why does a query return epoch 0 as a timestamp?

In TSDB for InfluxDB®, epoch 0 (1970-01-01T00:00:00Z) is often used as a null timestamp. If you request a query for which no timestamp can be returned, such as an aggregate function with no specified time range, TSDB for InfluxDB® returns epoch 0 as the timestamp.

Which InfluxQL functions support nesting?

The following InfluxQL functions support nesting:

• COUNT() with nested DISTINCT()

• CUMULATIVE_SUM()

• DERIVATIVE()

• DIFFERENCE()

• ELAPSED()

• MOVING_AVERAGE()

• NON_NEGATIVE_DERIVATIVE()

• HOLT_WINTERS() and HOLT_WINTERS_WITH_FIT()

For information about how to use subqueries instead of nested functions, see Data exploration.

How do I migrate a self-managed InfluxDB to the cloud?

Use the official InfluxDB influx_inspect tool to export line protocol files from your self-managed InfluxDB server. Then, use the command-line interface (Influx CLI) to import the files into TSDB for InfluxDB®.

How do I migrate data between different InfluxDB instances in the cloud?

No built-in migration tool exists between InfluxDB instances. Export data with queries and import manually. Use time and tag filters to batch the migration and avoid large queries that affect stability.

How do I migrate data from InfluxDB to LindormTSDB?

Import full data from your TSDB for InfluxDB® instance to LindormTSDB. TSDB for InfluxDB® historical data migration solutions.