Sure will do thank you
On Thursday, September 20, 2018, Erick Erickson
wrote:
> Try "bin/solr zk rm -help"
> On Thu, Sep 20, 2018 at 8:51 AM Schaum Mallik
> wrote:
> >
> > Sure Shawn will do what you suggested in the previous emails. Thank you
> so
> > much
> >
> > On Thursday, September 20, 20
Try "bin/solr zk rm -help"
On Thu, Sep 20, 2018 at 8:51 AM Schaum Mallik wrote:
>
> Sure Shawn will do what you suggested in the previous emails. Thank you so
> much
>
> On Thursday, September 20, 2018, Shawn Heisey wrote:
>
> > On 9/20/2018 9:32 AM, Schaum Mallik wrote:
> >
> >> ‘Then use "bin/s
Sure Shawn will do what you suggested in the previous emails. Thank you so
much
On Thursday, September 20, 2018, Shawn Heisey wrote:
> On 9/20/2018 9:32 AM, Schaum Mallik wrote:
>
>> ‘Then use "bin/solr zk rm" to get rid of it from ZK.‘ <— can you give the
>> full command for this one if you don
On 9/20/2018 9:32 AM, Schaum Mallik wrote:
‘Then use "bin/solr zk rm" to get rid of it from ZK.‘ <— can you give the
full command for this one if you don’t mind
Before doing this, try what I suggested. I am not sure that you need to
mess with what you have in ZK.
If you have core.properties
‘Then use "bin/solr zk rm" to get rid of it from ZK.‘ <— can you give the
full command for this one if you don’t mind
Thank you
On Thursday, September 20, 2018, Erick Erickson
wrote:
> bq. In response to this mistake that I did of keeping the core.properties
> in
> the configuration directory
Thanks Shawn. Will follow your advice on this one. Thank you so much
On Thursday, September 20, 2018, Shawn Heisey wrote:
> On 9/20/2018 9:25 AM, Schaum Mallik wrote:
>
>> ok so that’s the problem. The core.properties in the replicas under
>> /opt/solr/server/solr. So if I remove the file from a
On 9/20/2018 9:25 AM, Schaum Mallik wrote:
ok so that’s the problem. The core.properties in the replicas under
/opt/solr/server/solr. So if I remove the file from all the replica folders
and also move the directories under /opt/solr/server/solr/configsets to
some backup location and restart this
ok so that’s the problem. The core.properties in the replicas under
/opt/solr/server/solr. So if I remove the file from all the replica folders
and also move the directories under /opt/solr/server/solr/configsets to
some backup location and restart this node then hopefully it should start
working c
bq. In response to this mistake that I did of keeping the core.properties in
the configuration directory when it was uploaded to zookeeper, how should I
go about fixing it?
Oh my. You're saying that core.properties is _in_ ZooKeeper? Never
seen that before ;).
OK, I think I see what's happening.
On 9/20/2018 9:13 AM, Schaum Mallik wrote:
In response to this mistake that I did of keeping the core.properties in
the configuration directory when it was uploaded to zookeeper, how should I
go about fixing it?
A core.properties file in the config in ZK will not cause any problems.
It should
In response to this mistake that I did of keeping the core.properties in
the configuration directory when it was uploaded to zookeeper, how should I
go about fixing it?
Thank you
On Thursday, September 20, 2018, Schaum Mallik
wrote:
> Hi Eric
>
> I created the collection the way you detailed it
On 9/20/2018 8:59 AM, Shawn Heisey wrote:
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.
Here's what I did to rep
Hi Eric
I created the collection the way you detailed it in here. The configuration
directory for the collections was copied over from the standalone solr 6.
the core.properties existed in the conf directory and I didn’t realize it
would cause this issue.
Also all the nodes are solr 7.4.
Thank y
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 ge
I agree with Shawn that having
instanceDir=/opt/solr/server/solr/configsets/articles as where your
core is located is strange, how are you starting Solr? In particular,
do those nodes use a "-s' parameter to redefine SOLR_HOME?
The "-d" option (assuming you created the collection with bin/solr)
ju
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 st
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/confi
On 9/20/2018 8:22 AM, Schaum Mallik wrote:
Thanks for the response Shawn.
My follow up question is how would the zookeeper ensemble know that the
location of the indexes has changed? Also do I need to apply the same
changes to the other 2 solr nodes which are working fine?
This move is not to
Thanks for the response Shawn.
My follow up question is how would the zookeeper ensemble know that the
location of the indexes has changed? Also do I need to apply the same
changes to the other 2 solr nodes which are working fine?
Thanks
On Thursday, September 20, 2018, Shawn Heisey wrote:
> On
On 9/20/2018 6:02 AM, Schaum Mallik wrote:
Yeah my indexes, read and write works fine on the other two solr nodes.
Since I have this setup running in prod currently what are the steps you
will advice I take to resolve this issue. Starting from scratch is really
not an option since it will involve
Yeah my indexes, read and write works fine on the other two solr nodes.
Since I have this setup running in prod currently what are the steps you
will advice I take to resolve this issue. Starting from scratch is really
not an option since it will involve a huge cost. Is there some workaround
that y
On 9/19/2018 9:20 PM, Schaum Mallik wrote:
The data and index get stored under
/opt/solr/server/solr/articles_shard1_replica_n1.
The config directory when the collection was created, that time the path to
the config was given as '/opt/solr/server/solr/configsets/articles'. I
didn't use the servic
I also want to add one other things. I had moved from a single core solr
instance on solr 6.6 to the solr cloud few months back. I had ran the
indexupgrader tool on the indexes before I moved them to the solr cloud.
On Wed, Sep 19, 2018 at 7:29 PM Shawn Heisey wrote:
> On 9/19/2018 8:22 PM, Scha
The data and index get stored under
/opt/solr/server/solr/articles_shard1_replica_n1.
The config directory when the collection was created, that time the path to
the config was given as '/opt/solr/server/solr/configsets/articles'. I
didn't use the service installer script. The other two solr nodes
On 9/19/2018 8:22 PM, Schaum Mallik wrote:
I have a 3 zookeeper ensemble and 3 solr nodes running version 7.4.0.
Recently I had to restart one node and after I did that it started throwing
this exception.
Caused by: org.apache.solr.common.SolrException: No coreNodeName
for
CoreDescriptor[name=
Hi Guys
I have a 3 zookeeper ensemble and 3 solr nodes running version 7.4.0.
Recently I had to restart one node and after I did that it started throwing
this exception.
{
"error":{
"metadata":[
"error-class","org.apache.solr.core.SolrCoreInitializationException",
"root-erro
26 matches
Mail list logo
