Would rolling restart cause continuous bulk data lost?

Elastic Stack Elasticsearch
1

Hi,
According to this

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?

2

No, Elasticsearch makes sure that doesn't happen.

3

Thanks for reply

Is there any issues or sources related to this ensures?

4

Sorry I do not understand the question.

5

I think they're after documentation on how Elasticsearch prevents this.

6

It's kinda complicated, but maybe this blog post helps?

7

Thanks for this very much!

8

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

9

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.

10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.