Comments inline: On Wed, Sep 4, 2013 at 10:38 PM, Lisandro Montaño <lisan...@itivitykids.com> wrote: > Hi all, > > > > I’m currently working on deploying a solrcloud distribution in centos > machines and wanted to have more guidance about Replication Factor > configuration. > > > > I have configured two servers with solrcloud over tomcat and a third server > as zookeeper. I have configured successfully and have one server with > collection1 available and the other with collection1_Shard1_Replica1. >
How did you configure them this way? In particular, I'm confused as to why there is collection1 on the first node and collection1_Shard1_Replica1 on the other. > > > My questions are: > > > > - Can I have 1 shard and 2 replicas on two machines? What are the > limitations or considerations to define this? Yes you can have 1 shard and 2 replicas, one each on your two machines. That is the way it is configured by default. For example, this can be achieved if you create another collection (numShards=1&replicationFactor=2) using the collection API. > > - How does replica works? (there is not too much info about it) All replicas (physical shards) are peers who decide on a leader using ZooKeeper. All updates are routed via the leader who forwards (versioned) updates to other replicas. A query can be served by any replica. If a replica goes down, then it will attempt to recover from the current leader and then start serving requests. If the leader goes down, then all the other replicas (after waiting for a certain time for the old leader to come back) decide on a new leader. > > - When I import data on collection1 it works properly, but when I > do it in collection1_Shard1_Replica1 it fails. Is that an expected behavior? > (Maybe if I have a better definition of replica’s I will understand it > better) > Can you describe how it fails? Stack traces or excerpts from the Solr logs will help. -- Regards, Shalin Shekhar Mangar.
