lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Le Normand <>
Subject Re: What are the pros and cons Having More Replica at SolrCloud
Date Fri, 19 Apr 2013 00:43:45 GMT
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.


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

On Fri, Apr 19, 2013 at 3:08 AM, Timothy Potter <>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 <
> >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?
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message