[
https://issues.apache.org/jira/browse/SOLR-13955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045849#comment-17045849
]
David Smiley commented on SOLR-13955:
-------------------------------------
Question: If a node comes up empty, then isn't it arbitrary what replicas get
assigned to it? Does the previous replica assignment to this node really
matter then? Also sometimes the node's identity may be different and thus it
will be impossible to know which replicas used to be there. I wonder if the
use-case addressed here could better be addressed by the auto-scaling framework
detecting a lack of replicas for a collection and recognizing an opportunity to
add them when the node is available (thus more capacity)?
Minor comment: The logging I see in the code added is using {{String.format(}}
style String interpolation. Solr mostly uses a nice SLF4J feature of `{}` and
substitution. Please use that in the future.
> SHARED replicas can recover on clean disk
> -----------------------------------------
>
> Key: SOLR-13955
> URL: https://issues.apache.org/jira/browse/SOLR-13955
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Bilal Waheed
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> One of the benefits of SHARED replica is that it provides the ability to run
> SolrCloud with ephemeral disk(containers). Since the source of truth is in
> shared store, we can safely recover index from there. But currently there is
> no support to reason about the core descriptors that do not live locally on
> the disk. The purpose of this task is to discover missing core descriptors
> for SHARED replicas from ZK.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
