re: more replicas - pro: you can scale your query processing workload because you have more nodes available to service queries, eg 1,000 QPS sent to Solr with 5 replicas, then each is only processing roughly 200 QPS. If you need to scale up to 10K QPS, then add more replicas to distribute the increased workload
con: additional overhead (mostly network I/O) when indexing, shard leader has to send N additional requests per update where N is the number of replicas per shard. This seems minor unless you have many replicas per shard. I can't think of any cons of having more replicas on the query side As for your other question, when the leader receives an update request, it forwards to all replicas in the active or recovering state in parallel and waits for their response before responding to the client. All replicas must accept the update for it to be considered successful, i.e. all replicas and the leader must be in agreement on the status of a request. This is why you hear people referring to Solr as favoring consistency over write-availability. If you have 10 active replicas for a shard, then all 10 must accept the update or it fails, there's no concept of tunable consistency on a write in Solr. Failed / offline replicas are obviously ignored and they will sync up with the leader once they are back online. Cheers, Tim On Thu, Apr 18, 2013 at 4:48 PM, Furkan KAMACI <furkankam...@gmail.com>wrote: > What are the pros and cons Having More Replica at SolrCloud? > > Also there is a point that I want to learn. When a request come to a > leader. Does it forwards it to a replica. And if forwards it to replica, > does replica works parallel to build up the index with other replicas of > its same leader? >
