[
https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter reassigned SOLR-12182:
-------------------------------------
Assignee: Timothy Potter
> Can not switch urlScheme in 7x if there are any cores in the cluster
> --------------------------------------------------------------------
>
> Key: SOLR-12182
> URL: https://issues.apache.org/jira/browse/SOLR-12182
> Project: Solr
> Issue Type: Bug
> Affects Versions: 7.0, 7.1, 7.2
> Reporter: Anshum Gupta
> Assignee: Timothy Potter
> Priority: Major
> Attachments: SOLR-12182.patch, SOLR-12182_20200423.patch
>
>
> I was trying to enable TLS on a cluster that was already in use i.e. had
> existing collections and ended up with down cores, that wouldn't come up and
> the following core init errors in the logs:
> *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> replica with coreNodeName core_node4 exists but with a different name or
> base_url.*
> What is happening here is that the core/replica is defined in the
> clusterstate with the urlScheme as part of it's base URL e.g.
> *"base_url":"http:hostname:port/solr"*.
> Switching the urlScheme in Solr breaks this convention as the host now uses
> HTTPS instead.
> Actually, I ran into this with an older version because I was running with
> *legacyCloud=false* and then realized that we switched that to the default
> behavior only in 7x i.e while most users did not hit this issue with older
> versions, unless they overrode the legacyCloud value explicitly, users
> running 7x are bound to run into this more often.
> Switching the value of legacyCloud to true, bouncing the cluster so that the
> clusterstate gets flushed, and then setting it back to false is a workaround
> but a bit risky one if you don't know if you have any old cores lying around.
> Ideally, I think we shouldn't prepend the urlScheme to the base_url value and
> use the urlScheme on the fly to construct it.
--
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
