Hi Shawn Sorry for being repetitive but want to make sure I understand you clearly.
So my real collection data sits just outside the configsets folder. So if I move the location mentioned under instancedir to some backup location and then restart solr cloud you think this non working node will get the real collection data sitting outside the configsets dir. I really appreciate the time and effort you are taking in answering my queries. Thank you On Thursday, September 20, 2018, Shawn Heisey <apa...@elyograg.org> wrote: > On 9/20/2018 8:44 AM, Schaum Mallik wrote: > >> Thank you for your detailed responses. I am still kind of confused though. >> Just to give you some more insight. When I first created the cloud I >> created to collections and the ‘-d’ option pointed to the directory where >> the config for the collection was stored which was in >> /opt/solr/server/solr/configsets/articles/conf >> >> so as you are saying if I move the replica data to another location and >> restart the node and most probably solr might complain then what happens >> next. This solr node was working fine a week back and the indexes were >> upgraded when they were moved from solr 6 to solr 7 >> > > I really think that those cores that won't initialize are remnants from a > non-cloud install and probably have *never* worked. For some reason, you > didn't notice these errors until now. > > If you take a non-cloud Solr instance that has indexes and add ZK_HOST to > make it a cloud instance, the cores that existed before cloud mode will NOT > work. > > I just completed a test where I did that exact sequence of converting a > node from non-cloud with existing indexes to cloud, and ran into the exact > same errors you're seeing. I can relay exact details of the test if > required. > > I think that moving the non-cloud cores out so Solr doesn't try to load > them will likely fix this issue. > > Thanks, > Shawn > >
