ES version: 2.4.1
I was given a username and password for an Elasticsearch cluster (hosted on elastic.co). When I run:
GET /_cat/indices?v
it returns:
{
"error": {
"root_cause": [
{
"type": "index_not_found_exception",
"reason": "no such index",
"index": "_all"
}
],
"type": "index_not_found_exception",
"reason": "no such index",
"index": "_all"
},
"status": 404
}
Is it because of my assigned user role?
UPDATE:
I tried all the endpoints mentioned in the answers at list all indexes on ElasticSearch server? and this one worked:
GET /_cluster/health?level=indices
But I am at a loss as to why other queries don't work.
Related
I have two instances of the same version of elasticsearch with the same data.
I am now trying to _reindex an index with:
curl -X POST -H 'Content-Type: application/json' 'localhost:9200/_reindex' -d '{"source": {"index": "my_index_v1"}, "dest": { "index": "my_index_v2" }}' | jq
On one of the machines, it works correctly and a new index is correctly created. However on second machine, it ends with:
{
"error": {
"root_cause": [
{
"type": "index_not_found_exception",
"reason": "no such index [my_index_v2] and [action.auto_create_index] ([.watches,.triggered_watches,.watcher-history-*,.monitoring-*]) doesn't match",
"index_uuid": "_na_",
"index": "my_index_v2"
}
],
"type": "index_not_found_exception",
"reason": "no such index [my_index_v2] and [action.auto_create_index] ([.watches,.triggered_watches,.watcher-history-*,.monitoring-*]) doesn't match",
"index_uuid": "_na_",
"index": "my_index_v2"
},
"status": 404
}
I checked the elasticsearch.yml and the file is completely equal on both machines and contains following:
action.auto_create_index: .watches,.triggered_watches,.watcher-history-*,.monitoring-*
I have no idea why this happens.
To be clear, the index really exists.
EDIT:
working machine
elastic version: 7.17.4
settings.json: https://gist.github.com/knyttl/90f5d0f5de194be534160ab729c5a83b
non-working machine
elastic version: 7.17.4
settings.json: https://gist.github.com/knyttl/fcb94cd5739d3626f4545a9b9c5cceef
From the diff it seems that the working machine contains also:
{
"persistent": {
"action": {
"auto_create_index": "true"
},
…
}
}
So I guess that can be the culprit.
Update auto_create_index in second machine as,
{
"persistent": {
"action": {
"auto_create_index": "true"
}
}
}
instead of
action.auto_create_index: .watches,.triggered_watches,.watcher-history-*,.monitoring-*
could likely fix the issue.
I use tasks API for Elasticsearch 6.8. reindex process for my project. Sometimes I face the issue when in some of elastic search installations this API doesn't work properly. For example I create reindex task by command:
POST _reindex?wait_for_completion=false
{
"source": {
"index": "index1"
},
"dest": {
"index": "index2"
}
}
As response I get task Id.
But when I try to check status of this tasks by command
GET _tasks/{task-id}
instead of task status like in normal case I recieve the following:
"error": {
"root_cause": [{
"type": "index_not_found_exception",
"reason": "no such index",
"resource.type": "index_expression",
"resource.id - Registered at Namecheap.com ": ".tasks",
"index_uuid": "na",
"index": ".tasks"
}
],
"type": "resource_not_found_exception",
"reason": "task [epsVDuiBRO-IJBqCB2zHXQ:974632] isn't running and hasn't stored its results",
"caused_by": {
"type": "index_not_found_exception",
"reason": "no such index",
"resource.type": "index_expression",
"resource.id - Registered at Namecheap.com ": ".tasks",
"index_uuid": "na",
"index": ".tasks"
}
},
"status": 404
}
Is there any way to recover tasks API without reinstalling Elastic? I haven't succeed to find it in documentation.
Thanks in advance.
Problem solved. The issue was related to our own mapping with index patterns "*". It seems that by default elasticsearch doesn't create .tasks index. It creates it only when first command using tasks API performed adding new task document to this index. In my case it ElasticSearch couldn't add first .tasks document because some of fields of this document conflicted with the same fields from our own mapping. Solution is to change pattern of our mapping, or explicitly create mapping for .tasks index before putting our own mapping.
i have a local ES container running http://elasticsearch.net:9202 and i see a cluster by the name elasticsearch-dev with 1 node in it .
When i make a Postman call to it like the following http://elasticsearch.localnet:9202/elasticsearch-dev/*/_search?q=order_number:102811901637201
I get
{
"error": {
"root_cause": [
{
"type": "index_not_found_exception",
"reason": "no such index",
"resource.type": "index_or_alias",
"resource.id": "elasticsearch-dev",
"index_uuid": "_na_",
"index": "elasticsearch-dev" --------------------------- cluster name is reported back in as index name.
}
],
"type": "index_not_found_exception",
"reason": "no such index",
"resource.type": "index_or_alias",
"resource.id": "elasticsearch-dev",
"index_uuid": "_na_",
"index": "elasticsearch-dev"
},
"status": 404
}
But if i query like http://elasticsearch.localnet:9202/*/_search?q=order_number:102811901637201. without the cluster name it works fine (200 response) .
Does ES cluster deployed locally (1 node )have a different URL pattern ?
When you are running elasticsearch in your local system, the URL for index or search API is in the below format
http://{{hostname}}:{{es-port}}/{{index-name}}/_search
When running Elasticsearch in AWS EC2 instance, in that case also you can use this URL :
http://{{public-ip-of-cluster}}:{{es-port}}/{{index-name}}/_search
Elasticsearch version: 7.6.2
JVM：13.0.2
OS version：centeros7
This is my code
POST recommend_index/_update_by_query
{
"script": {
"source": "ctx._source.rec_doctor_id = 1"
},
"query": {
"bool": {
"must": [{
"terms": {
"id": ["22222"]
}
}]
}
}
}
This code does not return the result correctly,The error message is
{
"error": {
"root_cause": [
{
"type": "exception",
"reason": "Trying to create too many scroll contexts. Must be less than or equal to: [5000]. This limit can be set by changing the [search.max_open_scroll_context] setting."
}
],
"type": "search_phase_execution_exception",
"reason": "Partial shards failure",
"phase": "query",
"grouped": true,
"failed_shards": [
{
"shard": 1,
"index": "recommend_index",
"node": "XXX",
"reason": {
"type": "exception",
"reason": "Trying to create too many scroll contexts. Must be less than or equal to: [5000]. This limit can be set by changing the [search.max_open_scroll_context] setting."
}
}
]
},
"status": 500
}
I'm sure the current scroll is 0
When I replace _UPDATE_BY_QUERY with _UPDATE, it updates normally
No change has been made in ES since last Friday, and suddenly an error is reported
No configuration changes have been made to the ES server
follow-up:
I set the search.max_open_scroll_context parameter to 5000 and found nothing to do with it.
I looked up the 7.6.2 release and found that someone was having the same problem as me.Link on this
here #71354 #56202
I guess this is due to scrolling triggering the 7.6.2 bug.I restarted the cluster node without upgrading and found that it worked!!
We have a requirement where in we need to query across multiple indices as follows
We are using ElasticSearch 5.1.1.
http://localhost:9200/index1,index2,index3/type1,type2/_search
query:
{
"query": {
"multi_match": {
"query": "data",
"fields": ["status"]
}
}
}
However we may not know in advance if the index is present or not , we get following error if either of above indices is not present.
{
"error": {
"root_cause": [
{
"type": "index_not_found_exception",
"reason": "no such index",
"resource.type": "index_or_alias",
"resource.id": "index3",
"index_uuid": "_na_",
"index": "index3"
}
],
"type": "index_not_found_exception",
"reason": "no such index",
"resource.type": "index_or_alias",
"resource.id": "index3",
"index_uuid": "_na_",
"index": "index3"
},
"status": 404
}
One obvious way is to check if index is already present or not but I would like to avoid that extra call.
Note: At least 1 index will always be present
Is it possible to avoid this Exception ?
Thanks in advance !!
"ignore_unavailable" is the solution for this. Pass this as a query parameter in search url.
Exa. http://localhost:9200/index1,index2/type/_search?ignore_unavailable
This will not give 404 even if either of the indices are not present