On the query side, another down side i see would be that for a given memory pool, you'd have to share it with more cores because every replica uses it's own cache. True for the inner solr caching (JVM's heap) and OS caching as well. Adding a replicated core creates a new data set (index) that will be accessed while queried. If your replication adds a core of shard1 on a server that includes only shard2, the OS caching and solr caching would have to share the RAM with totally different memory parts (as files and query results for different shards are different) so it's clear. In the second case, if you add a replicated core to a server that already contains shard1, I'm not sure. There might be benefits if JVM handles its caches per shard and not per core, but the OS caching would differentiate between the different replications of same index and try to add both index files on memory.
Cheers, Manu So if you're short on memory or queries are alike (have high hit ration) you may better take advantage of your RAM usage than splitting it to many replications. On Fri, Apr 19, 2013 at 3:08 AM, Timothy Potter <thelabd...@gmail.com>wrote: > 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? > > >
