FAQ

更新时间:
复制 MD 格式

This topic describes common TSDB For InfluxDB® error messages and provides solutions.

How to handle the "database name required" error?

The error database name required occurs when a query that includes SHOW does not specify a database. To specify a database, you can use the ON clause in the SHOW query, use USE <database_name> in the command-line interface (CLI), or use the db parameter in an HTTP API request.

The SHOW queries that can cause this error include SHOW RETENTION POLICIES, SHOW SERIES, SHOW MEASUREMENTS, SHOW TAG KEYS, SHOW TAG VALUES, and SHOW FIELD KEYS.

How to handle the "max series per database exceeded: < >" error?

The error max series per database exceeded occurs when a write operation causes the number of series in a database to exceed the maximum allowed limit. The maximum number of series allowed per database is determined by your instance type.

The information within < > shows the measurement and tag set of the series that exceeded the max-series-per-database limit.

How to handle the "found < >, expected identifier at line < >, char < >" error?

  • InfluxQL syntax

    The error expected identifier occurs when TSDB For InfluxDB® cannot find an expected identifier in a query. Identifiers are names for continuous queries, databases, field keys, measurements, retention policies, subscriptions, tag keys, and usernames. This error usually indicates a problem with your query syntax.

    Example:

    > SELECT * FROM WHERE "blue"= true
    ERR: error parsing query: found WHERE, expected identifier at line 1, char 15

    This query is missing a measurement name between FROM and WHERE.

  • InfluxQL keywords

    In some cases, the expected identifier error occurs when an identifier in a query is an InfluxQL keyword. To query an identifier that is also an InfluxQL keyword, enclose the identifier in double quotation marks.

    The expected identifier error can occur when an identifier in a query is an InfluxQL keyword. To query such an identifier, enclose it in double quotation marks.

    Example

    > SELECT duration FROM runs
    ERR: error parsing query: found DURATION, expected identifier, string, number, bool at line 1, char 8

    In the query, the field key duration is an InfluxQL keyword. To avoid the error, enclose duration in double quotation marks:

    > SELECT "duration" FROM runs

How to handle the "found < >, expected string at line < >, char < >" error?

The error expected string occurs when TSDB For InfluxDB® expects a string value in a query but does not find one.

How to handle the "mixing aggregate and non-aggregate queries is not supported" error?

The error mixing aggregate and non-aggregate occurs when a SELECT statement includes both an aggregate function and a non-aggregated field key or tag key.

An aggregate function returns a single calculated result. For fields or tags that are not aggregated, there is no single, obvious value to return.

Example

Raw data: The measurement peg has two fields (square and round) and one tag (force):

name: peg
---------
time                   square   round   force
2016-10-07T18:50:00Z281
2016-10-07T18:50:10Z4122
2016-10-07T18:50:20Z6144
2016-10-07T18:50:30Z7153

Query 1:

> SELECT mean("square"),"round" FROM "peg"
ERR: error parsing query: mixing aggregate and non-aggregate queries is not supported

Query 1 includes an aggregate function and a separate field.

mean("square") returns an aggregate value, which is the average value of the four square values in the peg measurement. However, there is no single, obvious value to return for the four non-aggregated field values of the round field.

Query 2:

> SELECT mean("square"),"force" FROM "peg"
ERR: error parsing query: mixing aggregate and non-aggregate queries is not supported

Query 2 includes an aggregate function and a separate tag.

mean("square") returns an aggregate value, which is the average value of the four square values in the peg measurement. However, there is no single, obvious value to return for the four non-aggregated tag values of the force tag.

How to handle the "time and *influxql.VarRef are not compatible" error?

The error time and \*influxql.VarRef are not compatible occurs when you enclose a date and time string in double quotation marks in a query. Date and time strings must be enclosed in single quotation marks.

Example

Enclosing a date and time string in double quotation marks:

> SELECT "water_level" FROM "h2o_feet" WHERE "location"='santa_monica' AND time >="2015-08-18T00:00:00Z" AND time <="2015-08-18T00:12:00Z"
ERR: invalid operation: time and *influxql.VarRef are not compatible

Enclosing a date and time string in single quotation marks:

> SELECT "water_level" FROM "h2o_feet" WHERE "location"='santa_monica' AND time >='2015-08-18T00:00:00Z' AND time <='2015-08-18T00:12:00Z'

name: h2o_feet
time                   water_level
---------------
2015-08-18T00:00:00Z2.064
2015-08-18T00:06:00Z2.116
2015-08-18T00:12:00Z2.028

How to handle the "bad timestamp" error?

  • Time syntax

    The error bad timestamp occurs when the line protocol includes a timestamp that is not in the UNIX timestamp format.

    Example

    > INSERT pineapple value=1'2015-08-18T23:00:00Z'
    ERR:{"error":"unable to parse 'pineapple value=1 '2015-08-18T23:00:00Z'': bad timestamp"}

    The preceding line protocol uses a timestamp in RFC3339 format. To avoid the error and successfully write the data point to TSDB For InfluxDB®, replace the timestamp with a UNIX timestamp:

    > INSERT pineapple,fresh=true value=11439938800000000000
  • Line protocol syntax

    In some cases, the bad timestamp error occurs when there is a more general syntax error in the line protocol.

    Example

    Write 1:

    > INSERT hens location=2 value=9
    ERR:{"error":"unable to parse 'hens location=2 value=9': bad timestamp"}

    In Write 1, the line protocol uses a space instead of a comma to separate the measurement hen and the tag location=2. TSDB For InfluxDB® interprets the field value=9 as the timestamp and returns an error.

    To avoid the error, use a comma instead of a space to separate the measurement and the tag:

    > INSERT hens,location=2 value=9

    Write 2:

    > INSERT cows,name=daisy milk_prod=3 happy=3
    ERR:{"error":"unable to parse 'cows,name=daisy milk_prod=3 happy=3': bad timestamp"}

    In Write 2, the line protocol uses a space instead of a comma to separate the milk_prod=3 and happy=3 fields. Consequently, TSDB For InfluxDB® interprets happy=3 as the timestamp and returns an error.

    To avoid the error, separate the two fields with a comma instead of a space:

    > INSERT cows,name=daisy milk_prod=3,happy=3

    For more information, see Line Protocol Tutorial and Line Protocol Reference.

How to handle the "time outside range" error?

The error time outside range occurs when the timestamp in the line protocol is outside the valid time range for TSDB For InfluxDB®.

The minimum valid timestamp is -9223372036854775806 or 1677-09-21T00:12:43.145224194Z, and the maximum valid timestamp is 9223372036854775806 or 2262-04-11T23:47:16.854775806Z.

How to handle the "engine: cache maximum memory size exceeded" error?

The error cache maximum memory size exceeded occurs when a high write speed causes the server-side cache size to temporarily exceed the preset threshold. The preset threshold is determined by your instance type.