lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gian Maria Ricci - aka Alkampfer <>
Subject RE: Pro and cons of using Solr Cloud vs standard Master Slave Replica
Date Thu, 14 Jan 2016 08:58:33 GMT
I agree that SolrCloud has not only advantages, I really understand that it offers many more
features, but it introduces some complexity. 

One of the problem I've found is that I've not found a simple way to backup the content of
a collection to restore in situation of disaster recovery. With simple master / slave scenario
we can use the replication handler to generate backups that can be easily used to restore
content of a core, while with SolrCloud is not clear how can we obtain a full backup. Probably
is just a matter of backupping every shard with standard replication handler and then restore
each shard after recreating the collection, but I've not found (probably I need to search
better) official documentation on backup / restore procedures for SolrCloud.


Gian Maria Ricci
Cell: +39 320 0136949

-----Original Message-----
From: Bernd Fehling [] 
Sent: giovedì 14 gennaio 2016 08:22
Subject: Re: Pro and cons of using Solr Cloud vs standard Master Slave Replica

SolrCloud has some disadvantages and can't beat the easiness and simpleness of Master Slave
Replica. So I can only encourage to keep Master Slave Replica in future versions.


Am 13.01.2016 um 21:57 schrieb Jack Krupansky:
> The "Legacy Scaling and Distribution" section of the Solr Reference 
> Guide also gives info elated to so-called master-slave mode:
> stribution
> Also, although the old master-slave mode is still technically 
> supported in the sense that the code and doc is still there, You won't 
> be able to get the level of community support  here on the mailing 
> list as you can get for SolrCloud.
> Unless you're simply trying to decide whether to leave an old legacy 
> system as-is with the old distributed mode, nobody should be 
> considered a fresh new distributed Solr deployment with anything other than SolrCloud.
> (Hmmm... have any of the committers considered deprecating the old 
> non-SolrCloud distributed mode features?)


> -- Jack Krupansky
> On Wed, Jan 13, 2016 at 9:02 AM, Shivaji Dutta 
> <>
> wrote:
>> - SolrCloud uses zookeeper to manage HA
>>         - Zookeeper is a standard for all HA in Apache Hadoop
>> - You have collections which will manage your shards across nodes
>> - SolrJ Client is now fault tolerant with CloudSolrClient
>> This is the way future direction of the product will go.
>> On 1/13/16, 5:58 AM, "Gian Maria Ricci - aka Alkampfer"
>> <> wrote:
>>> Thanks.
>>> --
>>> Gian Maria Ricci
>>> Cell: +39 320 0136949
>>> -----Original Message-----
>>> From: Shawn Heisey []
>>> Sent: lunedì 11 gennaio 2016 18:28
>>> To:
>>> Subject: Re: Pro and cons of using Solr Cloud vs standard Master 
>>> Slave Replica
>>> On 1/11/2016 4:28 AM, Gian Maria Ricci - aka Alkampfer wrote:
>>>> a customer need a comprehensive list of all pro and cons of using 
>>>> standard Master Slave replica VS using Solr Cloud. I¹m interested 
>>>> especially in query performance consideration, because in this 
>>>> specific situation the rate of new documents is really slow, but 
>>>> the amount of data is about 50 millions of document, and the index 
>>>> size on disk for single core is about 30 GB.
>>> The primary advantage to SolrCloud is that SolrCloud handles most of 
>>> the administrative and operational details for you automatically.
>>> SolrCloud is a little more complicated to set up initially, because 
>>> you must worry about Zookeeper as well as Solr, but once it's 
>>> properly set up, there is no single point of failure.
>>>> Such amount of data should be easily handled by a Master Slave 
>>>> replica with a  single core replicated on a certain number of 
>>>> slaves, but we need to evaluate also the option of SolrCloud, 
>>>> especially for fault tolerance.
>>> Once you're beyond initial setup, fault tolerance with SolrCloud is 
>>> much easier than master/slave replication.  Switching a slave to a 
>>> master is possible, but the procedure is somewhat complicated.  
>>> SolrCloud does not
>>> *have* masters, it is a true cluster.
>>> With master/slave replication, the master handles all indexing, and 
>>> the finished index segments are copied to the slaves via HTTP, and 
>>> the slaves simply need to open them.  SolrCloud does indexing on all 
>>> shard replicas, nearly simultaneously.  Usually this is an 
>>> advantage, not a disadvantage, but in heavy indexing situations 
>>> master/slave replication
>>> *might* show better performance on the slaves.
>>> Thanks,
>>> Shawn

View raw message