[
https://issues.apache.org/jira/browse/SOLR-11481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206997#comment-16206997
]
Varun Thacker commented on SOLR-11481:
--------------------------------------
1. The replica asks the leader for it's fingerprint and compares it to the
local copy. The fingerprint is calculated on the index and we compare the max
version number from the index. If the version for matches then the indexes are
the same and we mark the replica as active.
2. If the highest version on the replica is behind the leader, then the replica
asks for the last 100 ( default ) updates from the leader.
3. If the replica is missing less than the 100 updates then it asks the leader
for the specific missing updates and applies them locally
4. In the scenario that the replica has fallen behind over a 100 updates we
resort to replication of indexes
5. In full replication, we compare each segment locally vs the leader and fetch
those segments that are either missing or if the checksums don't match.
> Ref guide page explaining nuances of the recovery process
> ---------------------------------------------------------
>
> Key: SOLR-11481
> URL: https://issues.apache.org/jira/browse/SOLR-11481
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Varun Thacker
> Priority: Minor
>
> The Solr recovery process involves PeerSync , which has configuration
> parameters to allow the number of records it should keep.
> If this fails we do a index replication where possibly we can throttle
> replication
> I think it's worth explaining to users what these configuration parameters
> are and how does a node actually recover.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
