[SOLR-9835] Create another replication mode for SolrCloud

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 7.0
• Assignee: Shalin Shekhar Mangar
• Reporter: Cao Manh Dat
• Created: 07/Dec/16 15:20
• Updated: 02/Oct/19 17:30
• Resolved: 03/Jul/17 23:00

Description

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.

On CAP point of view, this ticket will trying to promise to end users a distributed systems :

• Partition tolerance
• Weak Consistency for normal query : clusters can serve stale data. This happen when leader finish a commit and slave is fetching for latest segment. This period can at most pollInterval + time to fetch latest segment.
• Consistency for RTG : if we do not use DQBs, replicas will consistence with master just like original SolrCloud mode
• Weak Availability : just like original SolrCloud mode. If a leader down, client must wait until new leader being elected.

To use this new replication mode, a new collection must be created with an additional parameter liveReplicas=1

http://localhost:8983/solr/admin/collections?action=CREATE&name=newCollection&numShards=2&replicationFactor=1&realtimeReplicas=1

Issue Links

• is depended upon by: SOLR-10106 Avoid deserializing SolrInputDocument if the node does not index the document
• is related to: SOLR-10233 Add support for different replica types in Solr
• is related to: SOLR-9706 fetchIndex blocks incoming queries when issued on a replica in SolrCloud
• relates to: SOLR-6237 An option to have only leaders write and replicas read when using a shared file system with SolrCloud.