# Unable to delete documents from full index

**URL:** <https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266>\
**Category:** Elasticsearch\
**Tags:** reindex\
**Created:** [June 17, 2025, 8:48pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266 "2025-06-17T20:48:32Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\
**Post date:** [June 17, 2025, 8:48pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/1 "2025-06-17T20:48:32Z")

</div>

Hi;

I have an application with one build-in Elasticsearch node used for collecting log events into 3 indices. The application is deployed at several sites.

At some point in the future the implementation is going to be changed to data streams with polices, but for the moment the oldest documents are delete with a delete by query request executed by a Tomcat job.

However, in one specific deployment an index has reached the Lucene limit for number of documents in an index and the error

`Number of documents in the index can't exceed [2147483519`

is logged by Logstash.

I have tried with a script to delete the oldest documents with delete by query requests, but this does not work when the index is full. The delete by query request is just ignored and no documents are deleted. For the other indices which are not full the script works as expected.

I now want to try to re-index the oldest documents into a new index and then delete them.

My question is if the is possible to re-index, when the index is full?

Best regards  
@fgjensen

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [June 17, 2025, 9:07pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/2 "2025-06-17T21:07:16Z")

</div>

look at

> [@Delete\_by\_query number of documents Error](https://discuss.elastic.co/t/delete-by-query-number-of-documents-error/257737):
>
> Hi, I run this code: POST topf/\_delete\_by\_query?conflicts=proceed&max\_docs=500000 { "query": { "range": { "time": { "gte": "2020-09-18T03:00:00", "lte": "2020-09-18T04:00:00" } } } } I get this response: { "took": 197, "timed\_out": false, "total": 500000, "deleted": 0, "batches": 1, "version\_conflicts": 0, "noops": 0, "retries": { "bulk": 0, "search": 0 }, "throttled\_millis": 0, "requests\_per\_second": -1, "throttled\_until…

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [June 18, 2025, 1:47am UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/3 "2025-06-18T01:47:35Z")

</div>

What version of elasticsearch?

Please show the get cat indices for that index

`GET _cat/indices/indexname?v`

---

<div class="post-metadata">

**Author:** ![Tortoise](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tortoise/32/147587_2.png) [@Tortoise](https://discuss.elastic.co/u/Tortoise)\
**Post date:** [June 18, 2025, 4:02am UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/4 "2025-06-18T04:02:39Z")

</div>

Hello @fgjensen

Looking at the blogs seems your version must be 7.3.2 , could you please confirm?

> [@Node crashes due to max number of docs exceeded, but ILM should've not let it happen](https://discuss.elastic.co/t/node-crashes-due-to-max-number-of-docs-exceeded-but-ilm-shouldve-not-let-it-happen/201499/3):
>
> We have been running 7.3 for a month now, and looking at ILM explain results, it is seen that the indices were getting rolled over at 50GB everytime. Even the last index, metricbeat-7.3.0-0000050 rolled over correctly from 49. The 51st rollover also worked as expected. I can't do a dry run on that index now as I had to delete it to get the nodes started. But given that previous rollovers were successful, it might not be a problem with rollover itself? After deleting the old 51 Index, I created…

I believe split API can be used as per the below link & i have tried but for smaller index :

> <https://github.com/opensearch-project/OpenSearch/issues/3104>
>
> \*\*Is your feature request related to a problem? Please describe.\*\*
> OpenSearch s…hards have a 2147483519 doc limit. This is driven by a \[hard Lucene limit\](https://issues.apache.org/jira/browse/LUCENE-5843) on the number of documents that can exist in a Lucene index.
> 
> Once an OpenSearch shard has reached the maximum number of documents, the index begins rejecting document deletions:
> 
> \`\`\`
> GET /\_cat/indices/\<my index\>?v
> health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
> green open \<my index\> ne6hnbXiQSOdpxg6zsqPgw 1 1 2147483519 0 569.2gb 284.2gb
> 
> DELETE /\<my index\>/\_doc/zpi-oH0Bo4VEviPH9aZC
> {
> "error" : {
> "root\_cause" : \[
> {
> "type" : "illegal\_argument\_exception",
> "reason" : "number of documents in the index cannot exceed 2147483519"
> }
> \],
> "type" : "illegal\_argument\_exception",
> "reason" : "number of documents in the index cannot exceed 2147483519"
> },
> "status" : 400
> }
> \`\`\`
> 
> \*\*Describe the solution you'd like\*\*
> The ability to delete some docs within the index to free up space. Not sure if there's a Lucene-level limitation that prevents this behavior. 
> 
> \*\*Describe alternatives you've considered\*\*
> N/A
> 
> \*\*Additional context\*\*
> N/A

```auto

GET kibana_logs_success/_count #14074

PUT /kibana_logs_success/_block/write

POST /kibana_logs_success/_split/kibana_sample_logs_split
{
  "settings": {
    "index.number_of_shards": 10
  }
}

GET kibana_sample_logs_split/_count

```

I used 10 primary shards you can consider a lower number :

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/2/1/217ff9223e6e26dbaad57f0bfb17e3fc5f3bd8e7.png)

Thanks!!

---

<div class="post-metadata">

**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\
**Post date:** [June 18, 2025, 5:18am UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/5 "2025-06-18T05:18:24Z")

</div>

Hi

The version of Elasticsearch is 8.18.

We are maintaining the application but has not changed this part of the application yet except from upgradering to the latest version of Logstash and Elasticsearch. The application does not use Kibana.

The delete\_by\_query is similar to the one stated above except from I delete 100.000 documents per batch. When an index is not full it takes around 100 seconds per batch.

There are only one Elasticsearch node and one shard per index.

BR Flemming

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [June 18, 2025, 5:30am UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/6 "2025-06-18T05:30:41Z")

</div>

@fgjensen

Please show the cat indices.... There is a reason I'm asking for that.

`GET _cat/indices/indexname?v`

---

<div class="post-metadata">

**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\
**Post date:** [June 18, 2025, 1:21pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/7 "2025-06-18T13:21:10Z")

</div>

Hi @stephenb

There you have the output from \_cat. I do not have access to the server on which Elasticsearch runs, so I have to do all work by exchanging scripts and documents.

It is part of the script which performs the delete by query post to perform a \_cat indices request.

```auto
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size dataset.size
yellow open apclient_log_entry_v1 TL7gZYUfSGG1mzQqwPpcjQ 1 1 520413 64601 182025 182025 182025
yellow open audit_entry_v1 uwuExeL1TXS5Y7tDliMbbg 1 1 1240849 134926 675169 675169 675169
yellow open rest_log_entry cNSInhLPT9KFelhbBHxNmA 1 1 2147483519 0 240451302 240451302 240451302
yellow open rest_log_entry_v1 hrkgT7-kQIq4UuD7LR578w 1 1 0 0 0 0 0

```

Thank's for your help.

@fgjensen

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [June 18, 2025, 1:31pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/8 "2025-06-18T13:31:17Z")

</div>

Thanks I was hoping that there was still deleted docs in the index then you could expunge them in. The total number would come down but.... Unfortunately, you've already hit the limit and there are no deleted docs left in me index.

> [@fgjensen](#):
>
> I have tried with a script to delete the oldest documents with delete by query requests, but this does not work when the index is full. The delete by query request is just ignored and no documents are deleted.

If you just run a query with no delete does it find documents?

as @Tortoise suggested

I think you're going to need split the index into more than 1 shard to work with it.. The limit is actually at the shard level and since you only have one primary shard that's why you are limited.

If you split it into several shards you should be able to go back to working with it.

Need to think about a longer-term strategy about these indices more than one shard otherwise you're going to keep running into this limit

---

<div class="post-metadata">

**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\
**Post date:** [June 18, 2025, 2:07pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/9 "2025-06-18T14:07:14Z")

</div>

Hi @stephenb

The business rule that I am trying to achieve on short term is to be able to insert new documents in the rest\_log\_entry index by deleting the oldest documents. No index must contain documents older than 13 months. Since the two first indices are not full it works to delete the oldest documents with both the script and the Tomcat job (when the Tomcat job are deployed to this server).

The query the script runs for the moment is to find the oldest and youngest documents in each index.

Since I cannot delete from the full index my plan is to reindex the oldest documents into at second index. I'll take a look into splitting the index into several shards if it works for a full index?

On the term I'll change the to datastreams and index policies in order for Elasticsearch to take care of deleting the oldest documents.

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [June 18, 2025, 2:12pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/10 "2025-06-18T14:12:42Z")

</div>

> [@fgjensen](#):
>
> Since I cannot delete from the full index my plan is to reindex the oldest documents into at second index.

Not sure exactly what that solves since the old docs will still be in you main index. But you seem to have a handle on your problem.

> [@fgjensen](#):
>
> I'll take a look into splitting the index into several shards if it works for a full index?

It will. Then you should be able to delete.

> [@fgjensen](#):
>
> On the term I'll change the to datastreams and index policies in order for Elasticsearch to take care of deleting the oldest documents.

Yes this will solve many issues for you....

Good luck, let us know how it goes.

---

<div class="post-metadata">

**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\
**Post date:** [June 18, 2025, 2:26pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/11 "2025-06-18T14:26:12Z")

</div>

Hi @stephenb

Thanks for a swift answer.

I understand splitting is the shortest way to be able to delete the oldest documents, so I will try that solution.

Thanks to all who have posted to this question.

BR @fgjensen

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [June 18, 2025, 2:34pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/12 "2025-06-18T14:34:44Z")

</div>

How much of the data is "older than 13 months" ? 1% 10% 95% ?

Splitting the index will write all the documents out to N new shards

re-indexing can select only the newer documents, also writing to a new index with however many shards you choose.

--\> depending on the numbers re-index-ing-only-what-you need _might_ be quicker.

(don't forget to check disk space availability)

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [June 18, 2025, 2:52pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/13 "2025-06-18T14:52:53Z")

</div>

> [@RainTown](#):
>
> How much of the data is "older than 13 months" ? 1% 10% 95% ?

I am going to take a mad guess and say..... 1/13th of the data 🙂

But yes worth checking...

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [June 18, 2025, 2:56pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/14 "2025-06-18T14:56:35Z")

</div>

Actually, scratch that, the split API will be quicker in vast majority of cases, as it should just be hard linking a bunch of files.

The deleting of 1/13th (or however much there is) of data will take longer, but in that time the (new) index is usable.

---

<div class="post-metadata">

**Author:** ![fgjensen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fgjensen/32/62320_2.png) [@fgjensen](https://discuss.elastic.co/u/fgjensen)\
**Post date:** [June 18, 2025, 3:02pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/15 "2025-06-18T15:02:06Z")

</div>

The number of documents in each index is growing per month , since the application load is increasing. But that a side it says in split documentation:

```auto
* Before you can split an index:
* The index must be read-only.
* The cluster health status must be green

```

We can handle the read-only requirement, but this is a single node cluster so it will never turn green

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [June 18, 2025, 3:05pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/16 "2025-06-18T15:05:11Z")

</div>

> [@fgjensen](#):
>
> We can handle the read-only requirement, but this is a single node cluster so it will never turn green

Set Replicas to 0 and cluster will be green  
Having replicas set above 0 on a single node will always result in a yellow cluster

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [June 18, 2025, 3:05pm UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/17 "2025-06-18T15:05:56Z")

</div>

A single node cluster can be green. I have one right here on there Mac I'm using right now.

```auto
{
  "cluster_name": "elasticsearch",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 316,
  "active_shards": 316,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "unassigned_primary_shards": 0,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 100.0
}

```

Possibly you have indices with number\_of\_replicas set to 1, and nowhere to put them? Set to zero?

---

<div class="post-metadata">

**Author:** ![esijati](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/esijati/32/122104_2.png) [@esijati](https://discuss.elastic.co/u/esijati)\
**Post date:** [June 20, 2025, 5:37am UTC](https://discuss.elastic.co/t/unable-to-delete-documents-from-full-index/379266/18 "2025-06-20T05:37:42Z")

</div>

You can also update the index setting "index.merge.policy.deletes\_pct\_allowed" to below 20%  
This will auto manange the retention of deleted docs during merge operations