Tag Archives: Elasticsearch Error

[Solved] Elasticsearch Error: maybe these locations are not writable or multiple nodes were started without increasing [node.max_local_storage_nodes] (was [1])?

Leave a reply

1. Start elasticsearch and report an error, as shown below:

 1 [elsearch@master elasticsearch-7.2.1]$ ./bin/elasticsearch
 2 OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
 3 [2021-08-13T11:02:10,661][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [master] uncaught exception in thread [main]
 4 org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: failed to obtain node locks, tried [[/data/elasticsearch-7.2.1/data]] with lock id [0]; maybe these locations are not writable or multiple nodes were started without increasing [node.max_local_storage_nodes] (was [1])?
 5     at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:163) ~[elasticsearch-7.2.1.jar:7.2.1]
 6     at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:150) ~[elasticsearch-7.2.1.jar:7.2.1]
 7     at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) ~[elasticsearch-7.2.1.jar:7.2.1]
 8     at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124) ~[elasticsearch-cli-7.2.1.jar:7.2.1]
 9     at org.elasticsearch.cli.Command.main(Command.java:90) ~[elasticsearch-cli-7.2.1.jar:7.2.1]
10     at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:115) ~[elasticsearch-7.2.1.jar:7.2.1]
11     at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92) ~[elasticsearch-7.2.1.jar:7.2.1]
12 Caused by: java.lang.IllegalStateException: failed to obtain node locks, tried [[/data/elasticsearch-7.2.1/data]] with lock id [0]; maybe these locations are not writable or multiple nodes were started without increasing [node.max_local_storage_nodes] (was [1])?
13     at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:298) ~[elasticsearch-7.2.1.jar:7.2.1]
14     at org.elasticsearch.node.Node.<init>(Node.java:271) ~[elasticsearch-7.2.1.jar:7.2.1]
15     at org.elasticsearch.node.Node.<init>(Node.java:251) ~[elasticsearch-7.2.1.jar:7.2.1]
16     at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:221) ~[elasticsearch-7.2.1.jar:7.2.1]
17     at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:221) ~[elasticsearch-7.2.1.jar:7.2.1]
18     at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:349) ~[elasticsearch-7.2.1.jar:7.2.1]
19     at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:159) ~[elasticsearch-7.2.1.jar:7.2.1]
20     ... 6 more

Scenario description. Before starting elastichsearch, I used the root account to start. After the startup failed, I directly used the account created by elsearch to start es. An error was reported. The solution is to delete all the nodes under the data directory under the es installation directory and restart it. Use elsearch to start es.

[Solved] reason”: “Root mapping definition has unsupported parameters:

Leave a reply

1. An error was reported when Kibana created the index, and the elasticsearch version used was version 7.2.1.

 1 PUT /person
 2 {
 3   "settings": {
 4     "number_of_shards": "10",
 5     "number_of_replicas": "0",
 6     "refresh_interval": "-1"
 7   },
 8   "mappings": {
 9     "properties": {
10       "update_time": {
11         "format": "yyyy-MM-dd HH:mm:ss",
12         "type": "date"
13       },
14       "username": {
15         "type": "keyword"
16       },
17       "address": {
18         "type": "keyword"
19       }
20     }
21   }
 22 }

Report an error as follows:

 1 {
 2     "error": {
 3         "root_cause": [{
 4             "type": "mapper_parsing_exception",
 5             "reason": "Root mapping definition has unsupported parameters:  [project_evaluate : {properties={update_time={format=yyyy-MM-dd HH:mm:ss, type=date}, username={type=keyword}, address={type=keyword}}}]"
 6         }],
 7         "type": "mapper_parsing_exception",
 8         "reason": "Failed to parse mapping [_doc]: Root mapping definition has unsupported parameters:  [project_evaluate : {properties={update_time={format=yyyy-MM-dd HH:mm:ss, type=date}, username={type=keyword}, address={type=keyword}}}]",
 9         "caused_by": {
10             "type": "mapper_parsing_exception",
11             "reason": "Root mapping definition has unsupported parameters:  [project_evaluate : {properties={update_time={format=yyyy-MM-dd HH:mm:ss, type=date}, username={type=keyword}, address={type=keyword}}}]"
12         }
13     },
14     "status": 400
15 }

The specific reason is that ElasticSearch 7.x no longer supports the specified index type by default. Therefore, the index type is not specified in ElasticSearch 7.x, and the index creation is successful.

However, there is no problem when ElasticSearch 6.x is executed. Elasticsearch7 does not support the specified index type by default. The default index type is _doc. The index is no longer recommended to create an index type, just use the default. Because elasticsearch8 will not provide this field.

[Solved] Elasticsearch Error: “java.lang.IllegalArgumentException: Rejecting mapping update to [xxx] as the final mapping would have more than 1 type: [_doc, log]””

Leave a reply

One day, I was studying the index life cycle function of kibana, and I felt that it was quite useful for our thousands of indexes. Before, I wrote a deletion script and put it in a scheduled task for deletion.

By creating a new life later strategy, setting the date on the 15th, and matching the index template to the test index, the next day, it was found that the index had no data. The index size was 283B and the number of documents was 0. It seems that data is not accepted.

By viewing the logs_server.json log of elasticsearch, the following error was found:

 

 

Through various search materials, we can see that from ES 7.0, Type is obsolete
in 7.0 and later versions. There is only one default type in an index, namely _doc.

It just so happens that when my colleague used logstash to output to elasticsearch, he defined a configuration item with document_type as log, decisively commented out the configuration item, restarted logstash, restarted elasticsearch, and found that the value of the _type column of the index content I tested was _ doc, the log displayed before should conflict with the default.

 

 

After that, the index can be generated with a normal number of documents, and the _type in the content is all _doc, as shown in the figure, it automatically returns to normal, there is normal data, wait to observe the life cycle policy effect, if the test index can be deleted normally, you can change The scope is extended to all indexes. .