[
https://issues.apache.org/jira/browse/SOLR-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224895#comment-17224895
]
Chris M. Hostetter commented on SOLR-14979:
-------------------------------------------
Here's what i've confirmed from some investigation in to the feasibility of
this idea...
*Most* "collection" level functionality in solr doesn't care about these
nodeNames -- or the fact that they are derived from the host:port of the node
-- instead the {{state.json}} for the collection is consulted to determine the
{{"base_url" + "core"}} of a replica to determine how to send a request to a
particular replica (ie:
{{"http://prd-solr-xyz.region-aaa.mycompany.com:8983/solr"; +
"gettingstarted_shard1_replica_n1" =
"http://prd-solr-xyz.region-aaa.mycompany.com:8983/solr/gettingstarted_shard1_replica_n1"}}
However: a handful of _cluster_ level APIs, rely on the fact that
{{ZkStateReader.getBaseUrlForNodeName(String)}} can be used to "reverse" any
"nodeName" found in live_nodes to compute a URL (by combining it with the
{{URL_SCHEME}} cluster property). in order to send cluster level API requests
for things like metrics, adding new collections/replicas, etc...
----
Strawman proposal:
* modify solr startup to look for a user specified 'nodeName' on startup,
likely via sytem property (example: {{\-Dsolr.node.name=prd-solr-xyz}}
** similar to discussion in SOLR-14958 & SOLR-14934, this should *ONLY* be read
by SolrDispatchFilter, so that it can be overridden by a servlet-context
specified property, so it can be unique per "node" when running multiple (test)
nodes in a given JVM)
** if this option/property is not specified, then the existing code for
generating a _derived_ nodeName should still be used by each node on startup.
** either way the final nodeName value should (probably) still get the same
basic URL encoding that is currently used in order
* when a solr-node registers itself with ZK under {{/live_nodes}} the
ephemeral-node created should continue to be based on the 'nodeName'
** but the _content_ of the ephemeral ZK node (currently empty) should contain
the URL of the solr node
** ie: if a solr node starts up on
{{http://prd-solr-xyz.region-aaa.mycompany.com:8983/solr}} with a user
specified {{solr.node.name=prd-solr-xyz}} then the ephemeral node name should
be {{/live_nodes/prd-solr-xyz}} and the _content_ of that node should be
{{http://prd-solr-xyz.region-aaa.mycompany.com:8983/solr}}
* {{ZkStateReader.getBaseUrlForNodeName(String)}} should return the content of
the {{/live_nodes}} associated with teh specified nodeName
** for back compat / rolling cluster upgrates, we can continue to compute what
the URL _should_ be if the {{live_node}} has no content by follows the existing
naming convention
** this logic of checking the content of (new) ephemeral nodes could be done as
part of {{refreshLiveNodes(...)}} (ie: when the {{/live_nodes}} watcher fires)
... _OR_ ... ZkStateReader fetch the contents of each ephemeral node on demand
as needed -- either way caching the information in a {{Map<String,String>
nodeNameToNodeUrl}} (that could be purged by {{refreshLiveNodes(...)}})
*** which approach should be taken would depend largely on wether folks think
it's better to have (every) ZkStateReader _allways_ pay the cost of checking
the ephemeral nodes exactly once when a new node is created, or defer the check
so it's only done _if_ that ZkStateReader needs it for some cluster level
command -- but risk concurrent commands redundently quering ZK for the same
info.
> 'nodeName' should be configurable as a startup option/system property
> ---------------------------------------------------------------------
>
> Key: SOLR-14979
> URL: https://issues.apache.org/jira/browse/SOLR-14979
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
>
> Currently solr cloud nodes all use a 'nodeName' generated from the hostname +
> port (+ webapp context) (ie:
> {{prd-solr-xyz.region-aaa.my-company.com:8983_solr}} and then register their
> nodeName as an ephemeral zk nodes in {{/live_nodes}}.
> I think it would be helpful if nodes could optionally be configured to use an
> arbitrary (string) node name - w/o any assumptions that it be based on the
> current host/port - so that it's possible to shutdown a node and migrate it
> to a new host and/or port w/o any adverse impacts on other nodes in the
> cluster, or existing cluster configuration/preferences that might care about
> nodeNames.
> This would not only make it easier to migrate solr nodes between "machines"
> in cloud environments where hostnames may be based on racks/regions/etc...
> but it would also make it much easier to deal with stopping/restarting solr
> nodes in tests - w/o needing brittle code to hope and pray that we can re-use
> the same port on restart (SOLR-13871)
--
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
