Oh dear. You made me look at the reference guide. Ouch.
We have this nice page “Defining core.properties” that talks about defining core.properties. Unfortunately it has _no_ warning about the fact that trying to use this in SolrCloud is a really bad idea. As in “don’t do it”. To make matters worse, as you have found out painfully, it kinda worked in cloud mode in times past. Then the collections API doc says you can add property.name=value, with no mention that the name here should NOT be any of the properties necessary for SolrCloud to operate. The problem here is that adding property.name=value would set that property to the _same_ value in all cores. Naming all the replicas for a collection to the same thing is not supported officially, if it works in older Solrs that was by chance not design. And there’s no special provision for just using that property as a prefix. That’s really designed for custom properties. And, by the way, “name” is really kind of a no-op, the thing displayed in the drop-down is taken from Zookeeper’s node_name. Please don’t try to name that. I very strongly recommend that you stop trying to do this. Whatever you are doing that requires a specific name, I’d change _that_ process to use the names assigned by Solr. If it’s just for aesthetics, there’s really no good way to change what’s in the drop-down. Best, Erick > On Nov 5, 2020, at 5:25 AM, Modassar Ather <modather1...@gmail.com> wrote: > > Hi Shawn, > > I understand that we do not need to modify the core.properties and use the > APIs to create core and collection and that is what I am doing now. > This question of naming the core as per the choice comes from our older > setup where we have 12 shards, a collection and core both named the same > and the core were discovered by core.properties with entries as mentioned > in my previous mail. > > Thanks for the responses. I will continue with the new collection and core > created by the APIs and test our indexing and queries. > > Best, > Modassar > > > On Thu, Nov 5, 2020 at 12:58 PM Shawn Heisey <apa...@elyograg.org> wrote: > >> On 11/4/2020 9:32 PM, Modassar Ather wrote: >>> Another thing: how can I control the core naming? I want the core name to >>> be *mycore* instead of *mycore**_shard1_replica_n1*/*mycore* >>> *_shard2_replica_n2*. >>> I tried setting it using property.name=*mycore* but it did not work. >>> What can I do to achieve this? I am not able to find any config option. >> >> Why would you need to this or even want to? It sounds to me like an XY >> problem. >> >> http://xyproblem.info/ >> >>> I understand the core.properties file is required for core discovery but >>> when this file is present under a subdirectory of SOLR_HOME I see it not >>> getting loaded and not available in Solr dashboard. >> >> You should not be trying to manipulate core.properties files yourself. >> This is especially discouraged when Solr is running in cloud mode. >> >> When you're in cloud mode, the collection information in zookeeper will >> always be consulted during core discovery. If the found core is NOT >> described in zookeeper, it will not be loaded. And in any recent Solr >> version when running in cloud mode, a core that is not referenced in ZK >> will be entirely deleted. >> >> Thanks, >> Shawn >>
