[ 
https://issues.apache.org/jira/browse/SOLR-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15748538#comment-15748538
 ] 

Ishan Chattopadhyaya commented on SOLR-9835:
--------------------------------------------

{quote}
Collection property to switch replication scheme

A new property called “onlyLeaderIndexes” will be added to the collection. Any 
collection that has this property set to true will only index to the elected 
leader and the rest of the replicas will only fetch index segments from the 
leader as described above in the document. This property must be set during 
collection creation. It will default to “false”. Existing collections cannot be 
switched to using the new replication scheme. Future work can attempt to fix 
that.
{quote}

Instead of a hardcoded property name, i.e. onlyLeaderIndexes=true/false, I 
suggest that we have something like "replicationScheme=onlyLeaderIndexes" (or 
some other value for the current replication scheme). That would keep the door 
open for us to add any other replication scheme in future.

> Create another replication mode for SolrCloud
> ---------------------------------------------
>
>                 Key: SOLR-9835
>                 URL: https://issues.apache.org/jira/browse/SOLR-9835
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Cao Manh Dat
>
> The current replication mechanism of SolrCloud is called state machine, which 
> replicas start in same initial state and for each input, the input is 
> distributed across replicas so all replicas will end up with same next state. 
> But this type of replication have some drawbacks
> - The commit (which costly) have to run on all replicas
> - Slow recovery, because if replica miss more than N updates on its down 
> time, the replica have to download entire index from its leader.
> So we create create another replication mode for SolrCloud called state 
> transfer, which acts like master/slave replication. In basically
> - Leader distribute the update to other replicas, but the leader only apply 
> the update to IW, other replicas just store the update to UpdateLog (act like 
> replication).
> - Replicas frequently polling the latest segments from leader.
> Pros:
> - Lightweight for indexing, because only leader are running the commit, 
> updates.
> - Very fast recovery, replicas just have to download the missing segments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to