Re: Help with recovering shard range after zookeeper disaster
Thanks for the reply. Since, we don't have a working snapshot - we are creating brand new zookeeper nodes, re-upload solr configurations and manually create a clusterstate.json. Fortunately, doing a combination of grep and awk on corrupt snapshot - we figured out what the shard ranges were each of the shards.Hopefully we will be back up again soon. Lesson learnt - always keep a back up of a working snapshot of zookeeper. -- View this message in context: http://lucene.472066.n3.nabble.com/Help-with-recovering-shard-range-after-zookeeper-disaster-tp4284645p4284862.html Sent from the Solr - User mailing list archive at Nabble.com.
Help with recovering shard range after zookeeper disaster
We recently experienced a case where zookeeper snapshot became corrupt and would not restart. zkCli.sh (of zookeeper) would fail with an error unable to connect to / We have a solr cloud with two shards (Keys are autosharded) (Solr version 4.10.1) Unfortunately, we did not have a good snapshot to recover from. We are planning on creating a brand new zookeeper ensemble and have the solr nodes reconnect. We do not have a good clusterstate.json to upload to zookeeper. Our current state is - all solr nodes are operating on read-only mode. No updates are possible. This is what we are planning on doing now: 1. Delete snapshot and logs from zookeepers 2. Create brand new data folder 3. Upload solr configurations into zookeepers 4. With solr nodes running, have them reconnect to zookeeper. What I am not clear is, will each solr node as it attempts to reconnect - identify itself as which shard it originally belonged to. Will the clusterstate.json get created? I don't know the hash ranges since there is no clusterstate.json. Or do I need to manually create a clusterstate.json and upload it to the zookeeper. What is our best recourse now. Any help with disaster recovery is much appreciated. Thanks, Pramod -- View this message in context: http://lucene.472066.n3.nabble.com/Help-with-recovering-shard-range-after-zookeeper-disaster-tp4284645.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr 4.8 - Updating zkhost list in solr.xml without requiring a restart
> The idea is that your list of zookeeper hostnames is a virtual one, not > a real one. Thanks for the suggestion. Looks like I am not alone in thinking along the same lines. I am planning on doing that and was not sure if anyone else tried this approach and validated that it worked. -- View this message in context: http://lucene.472066.n3.nabble.com/Solr-4-8-Updating-zkhost-list-in-solr-xml-without-requiring-a-restart-tp4231979p4232045.html Sent from the Solr - User mailing list archive at Nabble.com.
Solr 4.8 - Updating zkhost list in solr.xml without requiring a restart
Hi, Is there an example which I could use - to upload solr.xml in zookeeper and change zkhost entries on the fly and have solr instances be updated via zookeeper. This will prevent us from restarting each solr node everytime, a new zookeeper host is added or deleted. We are on Solr 4.8. Thanks, Pramod -- View this message in context: http://lucene.472066.n3.nabble.com/Solr-4-8-Updating-zkhost-list-in-solr-xml-without-requiring-a-restart-tp4231979.html Sent from the Solr - User mailing list archive at Nabble.com.
When does SolrJ client add isShard=true automatically to the query
Hi all, We are using 3 shard solr cloud with 5 replicas per shard. We use SolrJ to execute solr queries. Often times, I cannot explain when, but we see in the query, isShard=true and shard.url=ip addresses of all the replicas. My questions are, 1. Why does this happen intermittently 2. When this happens, will it send requests to all the replicas in the shard and slow us down. 3. Most importantly, how can we avoid this situation. We also use zookeeper to manage our cluster. I am concerned that, if we add more replicas to each shard, this query will become slower. Thanks, Pramod -- View this message in context: http://lucene.472066.n3.nabble.com/When-does-SolrJ-client-add-isShard-true-automatically-to-the-query-tp4193512.html Sent from the Solr - User mailing list archive at Nabble.com.
How do I disable distributed search feature when I have only one shard
Hi there, We have a solr cloud set up with only one shard. There is one leader and 15 followers. So the data is replicated on 15 nodes. When we run a solr query, only one node should handle the request and we do not need any distributed search feature as all the nodes are exact copies of each other. Under certain load scenarios, we are seeing SOLRJ api is adding isShard=truedistrib=falseshard.url=A,B,C etc. to all the queries. Is the solr query waiting for responses from A, B and C before returning back to the client. If that is true, it is unnecessary and causing problems for us under heavy load. The thing is, somehow, these parameters are automagically added during query time. How do we disable this. The solrj query that we build programatically does not add these three parameters. Is there some configuration we can turn on, to tell solrj not to add these parameters to the solr request. Thanks, Pramod -- View this message in context: http://lucene.472066.n3.nabble.com/How-do-I-disable-distributed-search-feature-when-I-have-only-one-shard-tp4148449.html Sent from the Solr - User mailing list archive at Nabble.com.
Solr Replication Issue : Incorrect Base_URL
Hi,
I am deploying Solr in a larger web application. The standalone solr
instance works fine. The path-prefix I use is raptorslrweb. A standalone
SOLR query to my instance that works is as follows:
http://hostname:8080/raptorslrweb/solr/reviews/select?q=*%3A*wt=jsonindent=true
However, when I configure a solr cloud, I get the following error in
RecoveryStrategy:
msg:org.apache.solr.client.solrj.SolrServerException: Server at
http://hostname:8080/solr/reviews sent back a redirect (302).,
The reason is the base_url does not seem to honor the path-prefix.
clusterstate.json shows the following for the node:
{reviews:{
shards:{shard1:{
range:null,
state:active,
parent:null,
replicas:{
core_node1:{
state:down,
* base_url:http://hostname:8080/solr,*
core:reviews,
node_name:10.98.63.98:8080_solr},
Can someone please tell me where do I tell zookeeper or solr cloud that the
base url should be hostname:8080/raptorslrweb/solr and not
hostname:8080/solr.
Thanks,
Pramod
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Replication-Issue-Incorrect-Base-URL-tp4141537.html
Sent from the Solr - User mailing list archive at Nabble.com.
