[ https://issues.apache.org/jira/browse/SOLR-12011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cao Manh Dat resolved SOLR-12011. --------------------------------- Resolution: Fixed Fix Version/s: 7.3 master (8.0) > Consistence problem when in-sync replicas are DOWN > -------------------------------------------------- > > Key: SOLR-12011 > URL: https://issues.apache.org/jira/browse/SOLR-12011 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud > Reporter: Cao Manh Dat > Assignee: Cao Manh Dat > Priority: Major > Fix For: master (8.0), 7.3 > > Attachments: SOLR-12011.patch, SOLR-12011.patch, SOLR-12011.patch, > SOLR-12011.patch, SOLR-12011.patch > > > Currently, we will meet consistency problem when in-sync replicas are DOWN. > For example: > 1. A collection with 1 shard with 1 leader and 2 replicas > 2. Nodes contain 2 replicas go down > 3. The leader receives an update A, success > 4. The node contains the leader goes down > 5. 2 replicas come back > 6. One of them become leader --> But they shouldn't become leader since they > missed the update A > A solution to this issue : > * The idea here is using term value of each replica (SOLR-11702) will be > enough to tell that a replica received the latest updates or not. Therefore > only replicas with the highest term can become the leader. > * There are a couple of things need to be done on this issue > ** When leader receives the first updates, its term should be changed from 0 > -> 1, so further replicas added to the same shard won't be able to become > leader (their term = 0) until they finish recovery > ** For DOWN replicas, the leader should also need to check (in DUP.finish()) > that those replicas have term less than leader before return results to users > ** Just by looking at term value of replica, it is not enough to tell us > that replica is in-sync with leader or not. Because that replica might not > finish the recovery process. We need to introduce another flag (stored on > shard term node on ZK) to tell us that replica finished recovery or not. It > will look like this. > *** {"code_node1" : 1, "core_node2" : 0} — (when core_node2 start recovery) > ---> > *** {"core_node1" : 1, "core_node2" : 1, "core_node2_recovering" : 1} — > (when core_node2 finish recovery) ---> > *** {"core_node1" : 1, "core_node2" : 1} -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org