Vineet, I'm assuming that you are executing your search from a Java Client. If so, just use CloudSolrServer present in the Solrj API and save yourself from all these troubles. If you are not using a Java client, then you need to put a few or all your servers behind a load balancer and invoke requests against that.
On Mon, Feb 24, 2014 at 5:34 PM, Vineet Mishra <clearmido...@gmail.com> wrote: > Can you brief as how to make a direct call to Zookeeper instead of Cloud > Collection(as currently I was querying the Cloud something like > *"http://192.168.2.183:8900/solr/collection1/select?q=*:* > <http://192.168.2.183:8900/solr/collection1/select?q=*:*>"* ) from UI, now > if I assume shard 8900 is down then how can I still make the call. > > I have followed the Apache Tutorial(with separate zookeeper running on port > 2181) > > http://wiki.apache.org/solr/SolrCloud > > Can you please be more specific in respect to zookeeper distributed calls. > > Regards > > > On Wed, Feb 19, 2014 at 9:45 PM, Per Steffensen <st...@designware.dk> wrote: > >> On 19/02/14 07:57, Vineet Mishra wrote: >> >>> Thanks for all your response but my doubt is which *Server:Port* should >>> the >>> >>> query be made as we don't know the crashed server or which server might >>> crash in the future(as any server can go down). >>> >> That is what CloudSolrServer will deal with for you. It knows which >> servers are down and make sure not to send request to those servers. >> >> >>> The only intention for writing this doubt is to get an idea about how the >>> query format for distributed search might work if any of the shard or >>> replica goes down. >>> >> >> // Setting up your CloudSolrServer-client >> CloudSolrServer client= new CloudSolrServer(<zkConnectionStr>); // >> <zkConnectionStr> being the same string as you provide in -D|zkHost when >> starting your servers >> |client.setDefaultCollection("collection1"); >> client.connect(); >> >> // Creating and firing queries (you can do it in different way, but at >> least this is an option) >> SolrQuery query = new SolrQuery("*:*"); >> QueryResponse results = client.query(query); >> >> >> Because you are using CloudSolrServer you do not have to worry about not >> sending the request to a crashed server. >> >> In your example I believe the situation is as follows: >> * One collection called "collection1" with two shards "shard1" and >> "shard2" each having two replica "replica1" and "replica2" (a replica is an >> "instance" of a shard, and when you have one replica you are not having >> replication). >> * collection1.shard1.replica1 is running on localhost:8983 and >> collection1.shard1.replica2 is running on localhost:8900 (or maybe switched) >> * collection1.shard2.replica1 is running on localhost:7574 and >> collection1.shard2.replica2 is running on localhost:7500 (or maybe switched) >> If localhost:8900 is the only server that is down, all data is still >> available for search because every shard has at least on replica running. >> In that case I believe setting "shards.tolerant" will not make a >> difference. You will get your response no matter what. But if >> localhost:8983 was also down there would no live replica of shard1. I that >> case you will get an exception from you query, indicating that the query >> cannot be carried out over the complete data-set. In that case if you set >> "shards.tolerant" that behaviour will change, and you will not get an >> exception - you will get a real response, but it will just not include data >> from shard1, because it is not available at the moment. That is just the >> way I believe "shards.tolerant" works, but you might want to verify that. >> >> To set "shards.tolerant": >> >> SolrQuery query = new SolrQuery("*:*"); >> query.set("shards.tolerant", true); >> QueryResponse results = client.query(query); >> >> >> Believe distributes search is default, but you can explicitly require it by >> >> query.setDistrib(true); >> >> or >> >> query.set("distrib", true); >> >> >>> Thanks >>> >> >> -- Regards, Shalin Shekhar Mangar.
