Thanks a lot, Per. Now I understand the whole scenario. One last question: I've been searching trying to find some kind of request handler that retrieves cluster status information, but no luck. I know that there exists a JSON called clusterstate.json, but I don't know the way to get it in raw JSON format. Do you know how to get it status? Any request handler or Solr query? Maybe checking directly from Zookeeper?
Best regards, - Luis Cappa. 2012/12/15 Per Steffensen <st...@designware.dk> > Luis Cappa Banda skrev: > > Do you know if SolrCloud replica shards have 100% the same data as the >> leader ones every time? Probably wen synchronizing with leaders there >> exists a delay, so executing queries to replicas won't be a good idea. >> >> > As long as the replica is in state "active" it will be 100% up to date > with leader - updates goes to leader, but it dispatches simular request to > replica and does not respond (positively) to your update-request before it > has successfully received positive answers from replica (and of course also > locally stored the update successfully). If replica is in state > "recovering" or "down" or somthing it is (potentially) not up to date with > leader. > > Remember that even though updates are made on both leader and replica > synchronously it might not be available for (non-real-time) search on > leader and replica at exactly the same time, if you do not also make sure > to commit as part of you update. If you update alot you probably do not > want to commit every time. If you use (soft) auto-commit on the leader and > replica it will be possible that leader and replica does not respond > equally to the same request at the same time - but the leader can just as > well as the replica be the one that is "behind". If you use low values for > (soft) auto-commit in practice leader and replica will have the same > documents available for search at any time. > > Thank you very much in advance. >> >> Best regards, >> >> >> >> > > -- - Luis Cappa
