# Occasionally shards failing during scroll API (Scroll request has only succeeded on 270 (+0 skipped) shards out of 280) **URL:** \ **Category:** Elasticsearch\ **Created:** [June 21, 2024, 9:38am UTC](https://discuss.elastic.co/t/occasionally-shards-failing-during-scroll-api-scroll-request-has-only-succeeded-on-270-0-skipped-shards-out-of-280/361841 "2024-06-21T09:38:10Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Thijsvdp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thijsvdp/32/146696_2.png) [@Thijsvdp](https://discuss.elastic.co/u/Thijsvdp)\ **Post date:** [June 21, 2024, 9:38am UTC](https://discuss.elastic.co/t/occasionally-shards-failing-during-scroll-api-scroll-request-has-only-succeeded-on-270-0-skipped-shards-out-of-280/361841/1 "2024-06-21T09:38:10Z")
Hi, I am facing some weird errors on our Elasticsearch cluster using `scroll` API. For some data pipeline that I created I need to use the `scroll` API. Everything worked fine, but recently I have been encountering the following types of errors: ```auto Scroll request has only succeeded on 270 (+0 skipped) shards out of 280. ``` My index is green, and all shards are green. So I am not entirely sure what could be causing this. I have a special setup that may be of interest for debugging this problem: **Resources** - 10 Nodes: 5 nodes belong to group 1 (g1), and 5 nodes belong to group 2 (g2) - For each node: - 256GB RAM (32GB Heap) - 64 vCPU **Development Index** - Indexed on g1 - 10.7 TB (280 shards, primary only) - 1.6b documents **Production Index** - Indexed on g2 - 21.5 TB (280 primary shards and x1 replica) - 1.6b documents It is good to note that the data on the development index and the production index should be the same. We sometimes switch the development and production indices for maintenance purposes. Recently the production index started to fail with the above scroll error (`Scroll request has only succeeded on 270 (+0 skipped) shards out of 280.`). The development index happily continues without a problem. Again, everything seems green and we do not have any issues with normal queries. It seems to be only with `scroll`. I have investigated the segments on both of the indices and found the following: - There is about 2 times as many segments on our production index (counting only on primaries). - Development index has 9738 segments - Production index has 15049 segments I would expect it to have roughly the same number of segments as Elasticsearch should automatically merge segments at some point. I created a histogram of the segment sizes, and they look fairly similar distributed in both indices: **Development index** ![segments_dev](https://us1.discourse-cdn.com/elastic/original/3X/6/8/68be7ed17723aaa6d28d7a6a55263adf4659b6e0.png) **Production index** ![segments_prod](https://us1.discourse-cdn.com/elastic/original/3X/2/2/22f0837ea08971cdf7edc60ac42885eba01bf1a9.png) Any suggestions or ideas of what is going on? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [June 21, 2024, 9:53am UTC](https://discuss.elastic.co/t/occasionally-shards-failing-during-scroll-api-scroll-request-has-only-succeeded-on-270-0-skipped-shards-out-of-280/361841/2 "2024-06-21T09:53:02Z")
Whish version of Elasticsearch are you using? ---
**Author:** ![Thijsvdp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thijsvdp/32/146696_2.png) [@Thijsvdp](https://discuss.elastic.co/u/Thijsvdp)\ **Post date:** [June 21, 2024, 9:55am UTC](https://discuss.elastic.co/t/occasionally-shards-failing-during-scroll-api-scroll-request-has-only-succeeded-on-270-0-skipped-shards-out-of-280/361841/3 "2024-06-21T09:55:00Z")
@Christian_Dahlqvist I am using the latest version. Just upgraded a few days ago to 8.14.0. ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [June 21, 2024, 10:00am UTC](https://discuss.elastic.co/t/occasionally-shards-failing-during-scroll-api-scroll-request-has-only-succeeded-on-270-0-skipped-shards-out-of-280/361841/4 "2024-06-21T10:00:34Z")
Why are you using the scroll API instead of search after with PIT [as recommended in the documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/scroll-api.html)? ---
**Author:** ![Thijsvdp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thijsvdp/32/146696_2.png) [@Thijsvdp](https://discuss.elastic.co/u/Thijsvdp)\ **Post date:** [June 21, 2024, 10:12am UTC](https://discuss.elastic.co/t/occasionally-shards-failing-during-scroll-api-scroll-request-has-only-succeeded-on-270-0-skipped-shards-out-of-280/361841/5 "2024-06-21T10:12:51Z")
I am using the `.scan()` method in the `elasticsearch-py` client. I did not realize that it was actually advised against to use scroll. I will implement it with PIT, and check if that helps. I also thought it was a matter of efficiency to not use scroll. Is there any particular reason to not use scroll? ---
**Author:** ![Thijsvdp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thijsvdp/32/146696_2.png) [@Thijsvdp](https://discuss.elastic.co/u/Thijsvdp)\ **Post date:** [June 21, 2024, 12:33pm UTC](https://discuss.elastic.co/t/occasionally-shards-failing-during-scroll-api-scroll-request-has-only-succeeded-on-270-0-skipped-shards-out-of-280/361841/6 "2024-06-21T12:33:07Z")
Thanks a lot. It did solve the issues!