FAQ - Time Series Database - Centre de documentation Alibaba Cloud

Cette rubrique décrit les messages d'erreur courants de TSDB For InfluxDB® et propose des solutions.

Comment résoudre l'erreur « database name required » ?

L'erreur database name required survient lorsqu'une requête contenant SHOW ne spécifie pas de base de données. Spécifiez la base de données en utilisant la clause ON dans la requête SHOW, en exécutant USE <database_name> dans l'interface de ligne de commande (CLI) ou en utilisant le paramètre db dans une requête HTTP API.

Les requêtes SHOW susceptibles de provoquer cette erreur incluent SHOW RETENTION POLICIES, SHOW SERIES, SHOW MEASUREMENTS, SHOW TAG KEYS, SHOW TAG VALUES et SHOW FIELD KEYS.

Comment résoudre l'erreur « max series per database exceeded: < > » ?

L'erreur max series per database exceeded se produit lorsqu'une opération d'écriture fait dépasser au nombre de séries d'une base de données la limite maximale autorisée. Le nombre maximal de séries autorisé par base de données dépend du type de votre instance.

Les informations entre < > indiquent la mesure et l'ensemble de tags de la série ayant dépassé la limite max-series-per-database.

Comment résoudre l'erreur « found < >, expected identifier at line < >, char < > » ?

Syntaxe InfluxQL

L'erreur expected identifier apparaît lorsque TSDB For InfluxDB® ne trouve pas l'identifiant attendu dans une requête. Les identifiants correspondent aux noms des requêtes continues, des bases de données, des clés de champ, des mesures, des politiques de rétention, des abonnements, des clés de tag et des noms d'utilisateur. Cette erreur signale généralement un problème de syntaxe dans votre requête.

Exemple :
```
> SELECT * FROM WHERE "blue"= true
ERR: error parsing query: found WHERE, expected identifier at line 1, char 15
```
Il manque un nom de mesure entre FROM et WHERE dans cette requête.
Mots-clés InfluxQL

Dans certains cas, l'erreur expected identifier survient lorsqu'un identifiant utilisé dans une requête est un mot-clé InfluxQL. Pour interroger un tel identifiant, entourez-le de guillemets doubles.

L'erreur expected identifier peut se produire si un identifiant de la requête correspond à un mot-clé InfluxQL. Pour interroger cet identifiant, placez-le entre guillemets doubles.

Exemple
```
> SELECT duration FROM runs
ERR: error parsing query: found DURATION, expected identifier, string, number, bool at line 1, char 8
```
Dans la requête, la clé de champ duration est un mot-clé InfluxQL. Pour éviter l'erreur, entourez duration de guillemets doubles :
```
> SELECT "duration" FROM runs
```

Comment résoudre l'erreur « found < >, expected string at line < >, char < > » ?

L'erreur expected string se produit lorsque TSDB For InfluxDB® attend une valeur de type chaîne dans une requête mais n'en trouve aucune.

Comment résoudre l'erreur « mixing aggregate and non-aggregate queries is not supported » ?

L'erreur mixing aggregate and non-aggregate survient lorsqu'une instruction SELECT combine une fonction d'agrégation et une clé de champ ou de tag non agrégée.

Une fonction d'agrégation renvoie un seul résultat calculé. Pour les champs ou tags non agrégés, il n'existe pas de valeur unique évidente à retourner.

Exemple

Données brutes : La mesure peg comporte deux champs (square et round) et un 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

Requête 1 :

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

La requête 1 associe une fonction d'agrégation et un champ distinct.

mean("square") renvoie une valeur agrégée, à savoir la moyenne des quatre valeurs square de la mesure peg. En revanche, il n'existe pas de valeur unique évidente à retourner pour les quatre valeurs non agrégées du champ round.

Requête 2 :

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

La requête 2 associe une fonction d'agrégation et un tag distinct.

mean("square") renvoie une valeur agrégée, correspondant à la moyenne des quatre valeurs square de la mesure peg. Toutefois, il n'y a pas de valeur unique évidente à retourner pour les quatre valeurs non agrégées du tag force.

Comment résoudre l'erreur « time and *influxql.VarRef are not compatible » ?

L'erreur time and \*influxql.VarRef are not compatible survient lorsque vous entourez une chaîne de date et d'heure de guillemets doubles dans une requête. Les chaînes de date et d'heure doivent être placées entre guillemets simples.

Exemple

Utilisation de guillemets doubles autour d'une chaîne de date et d'heure :

> 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

Utilisation de guillemets simples autour d'une chaîne de date et d'heure :

> 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

Comment résoudre l'erreur « bad timestamp » ?

Syntaxe temporelle

L'erreur bad timestamp apparaît lorsque le protocole de ligne inclut un horodatage qui n'est pas au format UNIX.

Exemple
```
> INSERT pineapple value=1'2015-08-18T23:00:00Z'
ERR:{"error":"unable to parse 'pineapple value=1 '2015-08-18T23:00:00Z'': bad timestamp"}
```
Le protocole de ligne ci-dessus utilise un horodatage au format RFC3339. Pour éviter l'erreur et écrire correctement le point de données dans TSDB For InfluxDB®, remplacez l'horodatage par un horodatage UNIX :
```
> INSERT pineapple,fresh=true value=11439938800000000000
```
Syntaxe du protocole de ligne

Dans certains cas, l'erreur bad timestamp résulte d'une erreur de syntaxe plus générale dans le protocole de ligne.

Exemple

Écriture 1 :
```
> INSERT hens location=2 value=9
ERR:{"error":"unable to parse 'hens location=2 value=9': bad timestamp"}
```
Dans l'écriture 1, le protocole de ligne utilise un espace au lieu d'une virgule pour séparer la mesure hen et le tag location=2. TSDB For InfluxDB® interprète le champ value=9 comme l'horodatage et renvoie une erreur.

Pour éviter l'erreur, utilisez une virgule plutôt qu'un espace pour séparer la mesure et le tag :
```
> INSERT hens,location=2 value=9
```
Écriture 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"}
```
Dans l'écriture 2, le protocole de ligne utilise un espace au lieu d'une virgule pour séparer les champs milk_prod=3 et happy=3. Par conséquent, TSDB For InfluxDB® interprète happy=3 comme l'horodatage et renvoie une erreur.

Pour éviter l'erreur, séparez les deux champs par une virgule plutôt que par un espace :
```
> INSERT cows,name=daisy milk_prod=3,happy=3
```

Comment résoudre l'erreur « time outside range » ?

L'erreur time outside range se produit lorsque l'horodatage du protocole de ligne sort de la plage de temps valide pour TSDB For InfluxDB®.

L'horodatage minimal valide est -9223372036854775806 ou 1677-09-21T00:12:43.145224194Z, et l'horodatage maximal valide est 9223372036854775806 ou 2262-04-11T23:47:16.854775806Z.

Comment résoudre l'erreur « engine: cache maximum memory size exceeded » ?

L'erreur cache maximum memory size exceeded survient lorsqu'une vitesse d'écriture élevée fait temporairement dépasser au cache côté serveur le seuil prédéfini. Ce seuil dépend du type de votre instance.