[
https://issues.apache.org/jira/browse/SOLR-17821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18082446#comment-18082446
]
ASF subversion and git services commented on SOLR-17821:
--------------------------------------------------------
Commit f5a9985085f16312f04cc866cb05fada6f507279 in solr's branch
refs/heads/branch_10x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=f5a9985085f ]
SOLR-17821: Fix error scenario for ShardInstall or Restore (#3434)
(cherry picked from commit 4e5c83d2f07e3c1be51dcdcf5004665df33fb419)
> InstallShardData and Recover do not handle failures gracefully
> --------------------------------------------------------------
>
> Key: SOLR-17821
> URL: https://issues.apache.org/jira/browse/SOLR-17821
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore
> Reporter: Houston Putman
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Whenever a ShardInstall or Recover command succeeds, the shard zk terms will
> only be updated to reflect that they are not zero anymore. This is actually
> handled down in the InstallCoreData cmd, so if 1 core recover/install
> succeeds, then the zk terms will all be either untouched (if the terms are
> non-zero to start) or will all be set to 1. This does not handle errors
> gracefully.
> What we actually want to do is increase the terms of the successful replicas,
> and then the non-successful replicas can start to recover from the successful
> ones. If the leader was unsuccessful, it should give up leadership because
> its shard term is no longer the highest.
> Since shardInstall requires collections be read-only, we also need to fix the
> issues with read-only and recovery.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
