[
https://issues.apache.org/jira/browse/SOLR-17557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897716#comment-17897716
]
Houston Putman commented on SOLR-17557:
---------------------------------------
The problem is if there is no up-to-date replica left. This is in the
break-glass scenario which we have to choose a not-most-recent-replica. We
could just use the replica with the highest ShardTerm that is available, I
think that would give us the most up to date replica? I don't think the
replicas with lower shardTerms could have documents that it doesn't have. Would
you agree with that? If it's the case, then we could get rid of PeerSync.
> PeerSync should only be called when the ZkShardTerm is not the highest
> ----------------------------------------------------------------------
>
> Key: SOLR-17557
> URL: https://issues.apache.org/jira/browse/SOLR-17557
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: Houston Putman
> Priority: Major
>
> Currently when a leader is elected for a shard, PeerSync is called after
> election to make sure that the new leader is not missing documents that other
> replicas have.
> With the "new" LeaderInitiatedRecovery (LIR) implementation based on
> ZkShardTerms, we now have a much better idea as to which replicas have all
> the documents that the old leader had. So if the newly elected leader has the
> highest ZkShardTerm (i.e. it was already in sync with the old leader before
> the leader election), then we shouldn't need to run PeerSync.
> For the break-glass scenario where the newly elected leader does *not* have
> the highest ZkShardTerm, then we will probably still want to run PeerSync,
> just to be safe, as there will probably be data loss and we want to minimize
> how much data that is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
