Anshum Gupta created SOLR-12182:
-----------------------------------
Summary: 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
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.2, 7.1, 7.0
Reporter: Anshum Gupta
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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
