On 4/15/2013 3:38 AM, Victor Ruiz wrote:
About SolrCloud, I know it doesn't use master-slave replication, but incremental updates, item by item. That's why I thought it could work for us, since our bottleneck appear to be the replication cycles. But another point is, if the indexing occurs in all servers, 1200 updates/min could also overload the servers? and therefore have a worst performance than with master-slave replication?
One version (4.1, I think) has a problem that results in the entire index being replicated every time. The I/O required for that makes everything slow down on both master and slave.
There are reports of new master/slave replication problems with 4.2 and 4.2.1, but I'm not entirely clear on whether those are just cosmetic problems with index version reporting or whether some people are having actual real problems.
In 3.x and older, replication was generally the best option for multiple copies of your index, because there was no NRT indexing capability. Updating the index was a resource-intensive process with a high impact on searching, loading a replicated index was better.
Version 4.x adds NRT capabilities, so indexing impacts searches far less than it used to. SolrCloud with NRT features (frequent soft commits, less frequent hard commits) is the recommended configuration path now.
Thanks, Shawn
