[
https://issues.apache.org/jira/browse/SOLR-7347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132095#comment-18132095
]
Nick Shanin commented on SOLR-7347:
-----------------------------------
>From code reading against apache/main b73f03976fa, the version clock is not
>raised from versions a new leader has seen
>(solr/core/src/java/org/apache/solr/update/VersionInfo.java:127-135). A
>candidate is to raise the clock on the follower's apply path, so a new leader
>never issues a lower version. Is this still wanted?
🤖 AI-generated 🤖
> clock skew can cause data loss
> ------------------------------
>
> Key: SOLR-7347
> URL: https://issues.apache.org/jira/browse/SOLR-7347
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Yonik Seeley
> Priority: Major
>
> The high bits of versions are created using the system clock.
> System clock skew on the order of magnitude of time it takes for one leader
> to receive it's last update to the time it takes another replica to become a
> leader can cause data loss for any updates to the same document until the new
> leaders clock catches up with the old leaders clock.
> 1) replica1 is the leader and indexes document A, choosing version X (and
> forwards to replicas)
> 2) replica1 goes down
> 3) replica2 becomes the new leader
> 4) replica2 indexes an update for document A, and chooses version Y (which is
> less than X due to clock skew) and forwards to replica3
> 5) replica3 checks for reordered updates, finds version X and thus drops
> version Y
> This should be rare... you need a big enough clock skew and updates to the
> same document with different leaders within that time window. We should
> still fix this of course.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
