On 1/19/2017 4:09 AM, Hendrik Haddorp wrote: > Given that the data is on HDFS it shouldn't matter if any active > replica is left as the data does not need to get transferred from > another instance but the new core will just take over the existing > data. Thus a replication factor of 1 should also work just in that > case the shard would be down until the new core is up. Anyhow, it > looks like the above call is missing to set the shard id I guess or > some code is checking wrongly.
I know very little about how SolrCloud interacts with HDFS, so although I'm reasonably certain about what comes below, I could be wrong. I have not ever heard of SolrCloud being able to automatically take over an existing index directory when it creates a replica, or even share index directories unless the admin fools it into doing so without its knowledge. Sharing an index directory for replicas with SolrCloud would NOT work correctly. Solr must be able to update all replicas independently, which means that each of them will lock its index directory and write to it. It is my understanding (from reading messages on mailing lists) that when using HDFS, Solr replicas are all separate and consume additional disk space, just like on a regular filesystem. I found the code that generates the "No shard id" exception, but my knowledge of how the zookeeper code in Solr works is not deep enough to understand what it means or how to fix it. Thanks, Shawn
