# Replica segments not merged upon bulk indexing **URL:** \ **Category:** Elasticsearch\ **Created:** [January 23, 2013, 4:31pm UTC](https://discuss.elastic.co/t/replica-segments-not-merged-upon-bulk-indexing/10477 "2013-01-23T16:31:43Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![colinsurprenant](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/colinsurprenant/32/14776_2.png) [@colinsurprenant](https://discuss.elastic.co/u/colinsurprenant)\ **Post date:** [January 23, 2013, 4:31pm UTC](https://discuss.elastic.co/t/replica-segments-not-merged-upon-bulk-indexing/10477/1 "2013-01-23T16:31:43Z")
Hi, We just created a 2 nodes benchmarking cluster (ES 0.20.1, Ubuntu 10.04, 2.6.32-41) using a single index with 1 shard and 1 replica. We started bulk indexing, and at about 75M documents, the seconds node with the replica, busted with a filesystem inodes exhaustion. In fact, there were about 7700 segments created on the replica node, while there was about 60 segments on the shard node. All settings we pretty much to default values (in particular for the merging parameters) except for the refresh\_interval to -1. The question is, how come the replica node ended up with so many segments? It looks like it did not respect the index merging policy? - I know that the performance "best practice" for bulk indexing is not to use any replica then add replicas after bulk. But regardless of this, isn't this huge segmentation difference between the shard and the replica a problem? Thanks, Colin -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:54am UTC](https://discuss.elastic.co/t/replica-segments-not-merged-upon-bulk-indexing/10477/2 "2017-07-06T02:54:58Z")