[
https://issues.apache.org/jira/browse/SOLR-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15122527#comment-15122527
]
Yonik Seeley commented on SOLR-8586:
------------------------------------
bq. It isn't stated, but I assume the replica does a full sync if its
fingerprint, after sync, does not match the leader's?
right.
bq. Are there any scale concerns around calculating the fingerprint? Say, if
there are 100,000,000 (non-deleted) docs in the index?
Yes, this needs to be tested. We can do some caching if it's an issue.
bq. 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?
No, but in a high volume situation, we won't be able to sync up by requesting a
few missed docs from the leader anyway, so it probably doesn't matter. This is
more for both low update scenarios, and for bringing the whole cluster back up.
> 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
