# Would rolling restart cause continuous bulk data lost? **URL:** \ **Category:** Elasticsearch\ **Created:** [May 15, 2020, 3:08am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739 "2020-05-15T03:08:20Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![hackerwin7](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hackerwin7/32/43223_2.png) [@hackerwin7](https://discuss.elastic.co/u/hackerwin7)\ **Post date:** [May 15, 2020, 3:08am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/1 "2020-05-15T03:08:21Z")
Hi, According to [this](https://www.elastic.co/guide/en/elasticsearch/reference/6.8/docs-index_.html#index-wait-for-active-shards) if default settings is only 1 primary shard is active, when rolling restart, the indexing write primary shard is down. primary have latest data, replicas haven't sync these latest data, when rolling restart cause primary shard own, the one shard of replica would be promoted to be primary, however it don't have latest data synced. would this case cause data lost? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [May 15, 2020, 4:51am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/2 "2020-05-15T04:51:27Z")
> [@hackerwin7](#): > > would this case cause data lost? No, Elasticsearch makes sure that doesn't happen. ---
**Author:** ![hackerwin7](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hackerwin7/32/43223_2.png) [@hackerwin7](https://discuss.elastic.co/u/hackerwin7)\ **Post date:** [May 15, 2020, 5:23am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/3 "2020-05-15T05:23:30Z")
Thanks for reply Is there any issues or sources related to this ensures? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [May 15, 2020, 5:35am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/4 "2020-05-15T05:35:59Z")
> [@hackerwin7](#): > > Is there any issues or sources related to this ensures? Sorry I do not understand the question. ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 15, 2020, 5:37am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/5 "2020-05-15T05:37:01Z")
I think they're after documentation on how Elasticsearch prevents this. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [May 15, 2020, 5:44am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/6 "2020-05-15T05:44:51Z")
It's kinda complicated, but maybe this blog post helps? > **[Elasticsearch Internals - Tracking in-sync shard copies](https://www.elastic.co/blog/tracking-in-sync-shard-copies)** > > Deep dive into Elasticsearch's internals, highlighting how the consensus module and the data replication layer interact beautifully to keep your data safe. ---
**Author:** ![hackerwin7](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hackerwin7/32/43223_2.png) [@hackerwin7](https://discuss.elastic.co/u/hackerwin7)\ **Post date:** [May 15, 2020, 7:53am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/7 "2020-05-15T07:53:26Z")
Thanks for this very much! ---
**Author:** ![hackerwin7](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hackerwin7/32/43223_2.png) [@hackerwin7](https://discuss.elastic.co/u/hackerwin7)\ **Post date:** [May 15, 2020, 10:32am UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/8 "2020-05-15T10:32:12Z")
After reading to this, according to PacificA The `index.write.wait_for_active_shards` only check before write forward to replica, Is there any more strong style to ensure that check the data sink after the write forward to replica return. Just like Kafka settings `min.insync.replicas` and `ack` will strongly ensure the data sink multiple replica after write then return the response to User In a case : if In-sync Replica Group have only one replica, that is primary is worked, and the node which own the primary encounter an unrecoverable disaster, that primary data is corrupt permanently. This case maybe caused to data lost ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [May 15, 2020, 2:09pm UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/9 "2020-05-15T14:09:20Z")
Perhaps a simpler example of independent failures leading to data loss is if you have a primary and a replica on distinct nodes and both of them encounter an unrecoverable disaster at the same time. At least in cases like this Elasticsearch will tell you that data was lost, rather than carrying on regardless. You cannot in general protect against collections of independent failures. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 12, 2020, 2:13pm UTC](https://discuss.elastic.co/t/would-rolling-restart-cause-continuous-bulk-data-lost/232739/10 "2020-06-12T14:13:31Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.