Thanks Erick. I am going through the recommendations given in this email chain.
Best, Modassar On Thu, Nov 5, 2020 at 7:17 PM Erick Erickson <erickerick...@gmail.com> wrote: > 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 > >> > >
