[
https://issues.apache.org/jira/browse/SOLR-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15122311#comment-15122311
]
David Smith commented on SOLR-8586:
---
Trying to understand this without knowing the internals of the sync process --
apologies in advance if these are dumb questions:
It isn't stated, but I assume the replica does a full sync if its fingerprint,
after sync, does not match the leader's?
Are there any scale concerns around calculating the fingerprint? Say, if there
are 100,000,000 (non-deleted) docs in the index?
In a high volume situation (1000's updates / sec), will the leader's
fingerprint calculation be in perfect sync with the last versions it is
communicating to the replica? Thinking about a searcher being refreshed in the
middle of this request, or something like that.
> Implement hash over all documents to check for shard synchronization
>
>
> Key: SOLR-8586
> URL: https://issues.apache.org/jira/browse/SOLR-8586
> Project: Solr
> Issue Type: Improvement
>Reporter: Yonik Seeley
> Attachments: SOLR-8586.patch, SOLR-8586.patch
>
>
> An order-independent hash across all of the versions in the index should
> suffice. The hash itself is pretty easy, but we need to figure out
> when/where to do this check (for example, I think PeerSync is currently used
> in multiple contexts and this check would perhaps not be appropriate for all
> PeerSync calls?)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
