# Fail to update index data on Elasticsearch **URL:** \ **Category:** Elasticsearch\ **Tags:** language-clients\ **Created:** [September 12, 2023, 11:32am UTC](https://discuss.elastic.co/t/fail-to-update-index-data-on-elasticsearch/342825 "2023-09-12T11:32:47Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Antra](https://avatars.discourse-cdn.com/v4/letter/a/57b2e6/32.png) [@Antra](https://discuss.elastic.co/u/Antra)\ **Post date:** [September 12, 2023, 11:32am UTC](https://discuss.elastic.co/t/fail-to-update-index-data-on-elasticsearch/342825/1 "2023-09-12T11:32:47Z")
Hi team, I am facing an issue while using an Elasticsearch update query. I have given the detailed description of the issue below: _Version of Elasticsearch: 7.17.0_ **Problem Description:** My application has different teams. For each team, there is some data that is stored on elasticsearch with an index name format as given below: [data-name]-[team-id] Eg. attributes-2eXX7a00-XXdf-48e9-XXCXXXXX Now, in order to keep the data on elasticsearch against each team in sync with the database, we run a cron once every 24 hours. This cron basically does the following: 1. Runs for each team of the application in a loop 2. For each team, it first deletes the existing index from elasticsearch 3. Then create a brand new index for that team 4. Then updates the index, for each nested records or documents While the above process is running, sometimes it does not complete the whole process for a team, and gets stuck while either creating the new index or updating the data of that index. While monitoring the logs received, we could find following logs that seemed to have some relation with above issue: Log 1: `(node:9960) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 abort listeners added to [EventEmitter]. Use emitter.setMaxListeners() to increase limit (Use `node --trace-warnings ...` to show where the warning was created)` Log 2: ```auto Root causes: validation_exception: Validation Failed: 1: this action would add [2] shards, but this cluster currently has [999]/[1000] maximum normal shards open; ``` Log 3: ```auto RequestAbortedError: Request aborted at SniffingTransport.request (/home/netzwelt/Documents/projects/internal/project1/server/node_modules/@elastic/transport/lib/Transport.js:502:46) at processTicksAndRejections (node:internal/process/task_queues:95:5) at runNextTicks (node:internal/process/task_queues:64:3) at listOnTimeout (node:internal/timers:538:9) at process.processTimers (node:internal/timers:512:7) at async Client.UpdateApi [as update] (/home/netzwelt/Documents/projects/internal/project1/server/node_modules/@elastic/elasticsearch/lib/api/api/update.js:50:12) at async setESIndex (/home/netzwelt/Documents/projects/internal/project1/server/src/services/elastic-search/elastic-search.js:66:21) at async /home/netzwelt/Documents/projects/internal/project1/server/src/helpers/elastic-search.js:339:26 { meta: { body: undefined, statusCode: 0, headers: {}, meta: { context: null, request: [Object], name: 'elasticsearch-js', connection: [Object], attempts: 0, aborted: true }, warnings: [Getter] } } ``` The process mentioned above fails sometimes, and mostly for specific teams, having very large data associated with them. Few things to note here are: 1. Other teams having similar size data never have any problem completing the above process successfully. 2. Elasticsearch logs that we get right now are not descriptive enough to figure out the actual problem. 3. But once the request fails for one team, other teams are also not indexed properly. Any guidance or direction to find the root cause of this issue will be highly appreciable. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [September 12, 2023, 1:22pm UTC](https://discuss.elastic.co/t/fail-to-update-index-data-on-elasticsearch/342825/2 "2023-09-12T13:22:50Z")
What is the output of: ```auto GET / GET /_cat/nodes?v GET /_cat/health?v GET /_cat/indices?v ``` If some outputs are too big, please share them on [gist.github.com](http://gist.github.com) and link them here. ---
**Author:** ![Antra](https://avatars.discourse-cdn.com/v4/letter/a/57b2e6/32.png) [@Antra](https://discuss.elastic.co/u/Antra)\ **Post date:** [September 13, 2023, 6:28am UTC](https://discuss.elastic.co/t/fail-to-update-index-data-on-elasticsearch/342825/3 "2023-09-13T06:28:57Z")
Thank you for the response. Sharing the required information in the gist link below: [https://gist.github.com/developer-vtnetzwelt/371d9134fd5cbfc80b169815a416585d](https://gist.github.com/developer-vtnetzwelt/371d9134fd5cbfc80b169815a416585d) ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [September 14, 2023, 5:56pm UTC](https://discuss.elastic.co/t/fail-to-update-index-data-on-elasticsearch/342825/4 "2023-09-14T17:56:05Z")
As you have only one node, I'd suggest to change the number of replicas to 0 for all the indices. But as you have a lot of very tiny indices, may I suggest you look at the following resource about sizing: > **[Size your shards | Elasticsearch Guide \[8.10\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/size-your-shards.html)** You have too many small indices IMO. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [October 12, 2023, 5:56pm UTC](https://discuss.elastic.co/t/fail-to-update-index-data-on-elasticsearch/342825/5 "2023-10-12T17:56:30Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.