All Products
Search
Document Center

Troubleshooting

Last Updated: Apr 08, 2021

This topic describes common error messages in TSDB for InfluxDB® and the corresponding solutions that you can use if applicable.

How to deal with "database name required" reporting errors?

The error message database name required occurs if no database is specified for a SHOW query. To specify a database, use the ON clause in the SHOW statement, the USE<database_name> statement in the CLI, or the db parameter in an HTTP API request.

SHOW queries include SHOW RETENTION POLICIESSHOW SERIESSHOW MEASUREMENTSSHOW TAG KEYSSHOW TAG VALUES, and SHOW FIELD KEYS.

How to Deal with Error Reporting "max series per database exceeded: <> "?

The error message max series per database exceeded occurs if a write request causes the number of series in a database to exceed the maximum number of series per database. The maximum number of series per database depends on the instance type that you purchase.

The information in the angle brackets (<>) shows the measurements and the tag sets of the series that exceed the upper limit specified by max-series-per-database.

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

  • InfluxQL syntax

    The error message expected identifier occurs if TSDB for InfluxDB® fails to find the expected identifier in a query. Identifiers can be continuous query names, database names, field keys, measurement names, retention policy names, subscription names, tag keys, or usernames. This error message prompts you to check your query syntax.

    Example:

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

    In this query, a measurement name is missing between FROM and WHERE.

  • InfluxQL keyword

    The error message expected identifier may occur if one of the identifiers in a query is an InfluxQL keyword. If an identifier in your query is an InfluxQL keyword, enclose the identifier in double quotation marks (“).

    Examples

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

    In this query, the duration field key is an InfluxQL keyword. To avoid the error, you can enclose the duration tag key in double quotation marks (“) .

    > SELECT "duration" FROM runs

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

The error message expected string occurs if TSDB for InfluxDB® fails to find the expected string in a query.

How to deal with "mixing aggregate and non-aggregate queries is not supported" reporting errors?

The error message mixing aggregate and non-aggregate occurs if the SELECT statement includes both an aggregate function and a standalone field key or tag key.

The aggregate function returns a single value, but no single value can be returned for the fields or tags that are not aggregated.

Examples

Raw data: The peg measurement includes the square and round fields and the force tag.

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

This query includes an aggregate function and a standalone field key.

The mean("square") function returns a single aggregated value, which is the average value of the four values of square in the peg measurement. However, no single value can be returned for the four unaggregated 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

This query includes an aggregate function and a standalone tag key.

The mean("square") function returns a single aggregated value, which is the average value of the four values of square in the peg measurement. However, no single value can be returned for the four unaggregated values of the force tag.

How to deal with "time and *influxql.VarRef are not compatible" reporting errors?

The error message time and \*influxql.VarRef are not compatible occurs if date and time strings are enclosed in double quotation marks (“) in a query. You must enclose the date and time strings in single quotation marks (‘).

Examples

Enclose the date and time strings 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

Enclose the date and time strings 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 deal with the error "bad timestamp"?

  • Timestamp syntax

    The error message bad timestamp occurs if the line protocol includes a timestamp that does not use the Unix timestamp format.

    Examples

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

    In this example, the line protocol uses an RFC 3339 timestamp. To avoid the error and write the point to TSDB for InfluxDB®, you can replace the current timestamp with a Unix timestamp.

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

    The error message bad timestamp may occur if the line protocol includes general syntax errors.

    Examples

    Write request 1:

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

    In write request 1, the line protocol separates the hen measurement and the location=2 tag by using a space instead of a comma (,). As a result, TSDB for InfluxDB® considers the value=9 field as a timestamp and returns the error.

    To avoid the error, you can use a comma (,) to separate the measurement and the tag.

    > INSERT hens,location=2 value=9

    Write request 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 request 2, the line protocol separates the milk_prod=3 field and the happy=3 field by using a space instead of a comma (,). As a result, TSDB for InfluxDB® considers the happy=3 field as a timestamp and returns the error.

    To avoid the error, use a comma (,) to separate the two fields.

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

How to deal with "time outside range" reporting errors?

The error message time outside range occurs if the timestamp in the line protocol falls out of the valid time range of TSDB for InfluxDB®. The minimum valid timestamp is -9223372036854775806 or 1677-09-21T00:12:43.145224194Z. The maximum valid timestamp is 9223372036854775806 or 2262-04-11T23:47:16.854775806Z.

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

The error message cache maximum memory size exceeded occurs if the cached memory size in a server exceeds the preset threshold in a short period. This is because data is written at an excessively high speed. The preset threshold depends on the instance type that you purchase.