You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ratis.apache.org by "Glen Geng (Jira)" <ji...@apache.org> on 2020/11/17 12:30:00 UTC
[jira] [Updated] (RATIS-1161) Updating commit index of follower
does not require term check.
[ https://issues.apache.org/jira/browse/RATIS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Glen Geng updated RATIS-1161:
-----------------------------
Description:
This is a followup of Jira https://issues.apache.org/jira/browse/RATIS-748
According to the basic raft algorithm, the logic of advancing commit index for follower and leader is different.
*For follower:*
When receiving an AppendEntries Request, the logic is
{code:java}
If leaderCommit > commitIndex: set commitIndex = min(leaderCommit, index of last new entry)
{code}
*For leader:*
The majority commit should only be used on the log entry that created by current leader, thus need a term check.
{code:java}
If there exists an N such that N > commitIndex, a majority of matchIndex[i] ≥ N, and log[N].term == currentTerm: set commitIndex = N{code}
*For current ratis:*
We apply the advancing commit index logic of leader to follower, which will make follower's commit index to lag behind.
{code:java}
/**
* Update the last committed index.
* @param majorityIndex the index that has achieved majority.
* @param currentTerm the current term.
* @return true if update is applied; otherwise, return false, i.e. no update required.
*/
public boolean updateLastCommitted(long majorityIndex, long currentTerm) {
try(AutoCloseableLock writeLock = writeLock()) {
final long oldCommittedIndex = getLastCommittedIndex();
final long newCommitIndex = Math.min(majorityIndex, getFlushIndex());
if (oldCommittedIndex < newCommitIndex) {
// Only update last committed index for current term. See §5.4.2 in
// paper for details.
final TermIndex entry = getTermIndex(newCommitIndex);
if (entry != null && entry.getTerm() == currentTerm) {
commitIndex.updateIncreasingly(newCommitIndex, traceIndexChange);
return true;
}
}
}
return false;
}
{code}
*Intention of this Jira*
We want to prove the we can safely revert the advancing commit index logic of follower.
was:
This is a followup of Jira https://issues.apache.org/jira/browse/RATIS-748
According to the basic raft algorithm, the logic of advancing commit index for follower and leader is different.
*For follower:*
When receiving an AppendEntries Request, the logic is
{code:java}
If leaderCommit > commitIndex: set commitIndex = min(leaderCommit, index of last new entry)
{code}
*For leader:*
The majority commit should only be used on the log entry that created by current leader, thus need a term check.
{code:java}
If there exists an N such that N > commitIndex, a majority of matchIndex[i] ≥ N, and log[N].term == currentTerm: set commitIndex = N{code}
*For current ratis:*
We apply the advancing commit index logic of leader to follower, which will make follower's commit index to lag behind.
{code:java}
/**
* Update the last committed index.
* @param majorityIndex the index that has achieved majority.
* @param currentTerm the current term.
* @return true if update is applied; otherwise, return false, i.e. no update required.
*/
public boolean updateLastCommitted(long majorityIndex, long currentTerm) {
try(AutoCloseableLock writeLock = writeLock()) {
final long oldCommittedIndex = getLastCommittedIndex();
final long newCommitIndex = Math.min(majorityIndex, getFlushIndex());
if (oldCommittedIndex < newCommitIndex) {
// Only update last committed index for current term. See §5.4.2 in
// paper for details.
final TermIndex entry = getTermIndex(newCommitIndex);
if (entry != null && entry.getTerm() == currentTerm) {
commitIndex.updateIncreasingly(newCommitIndex, traceIndexChange);
return true;
}
}
}
return false;
}
{code}
*Intention of this Jira*
We want to prove the we can safely revert the advancing commit index logic of follower.
> Updating commit index of follower does not require term check.
> --------------------------------------------------------------
>
> Key: RATIS-1161
> URL: https://issues.apache.org/jira/browse/RATIS-1161
> Project: Ratis
> Issue Type: Improvement
> Components: server
> Affects Versions: 1.1.0
> Reporter: Glen Geng
> Priority: Minor
>
> This is a followup of Jira https://issues.apache.org/jira/browse/RATIS-748
>
> According to the basic raft algorithm, the logic of advancing commit index for follower and leader is different.
> *For follower:*
> When receiving an AppendEntries Request, the logic is
> {code:java}
> If leaderCommit > commitIndex: set commitIndex = min(leaderCommit, index of last new entry)
> {code}
>
> *For leader:*
> The majority commit should only be used on the log entry that created by current leader, thus need a term check.
> {code:java}
> If there exists an N such that N > commitIndex, a majority of matchIndex[i] ≥ N, and log[N].term == currentTerm: set commitIndex = N{code}
>
> *For current ratis:*
> We apply the advancing commit index logic of leader to follower, which will make follower's commit index to lag behind.
> {code:java}
> /**
> * Update the last committed index.
> * @param majorityIndex the index that has achieved majority.
> * @param currentTerm the current term.
> * @return true if update is applied; otherwise, return false, i.e. no update required.
> */
> public boolean updateLastCommitted(long majorityIndex, long currentTerm) {
> try(AutoCloseableLock writeLock = writeLock()) {
> final long oldCommittedIndex = getLastCommittedIndex();
> final long newCommitIndex = Math.min(majorityIndex, getFlushIndex());
> if (oldCommittedIndex < newCommitIndex) {
> // Only update last committed index for current term. See §5.4.2 in
> // paper for details.
> final TermIndex entry = getTermIndex(newCommitIndex);
> if (entry != null && entry.getTerm() == currentTerm) {
> commitIndex.updateIncreasingly(newCommitIndex, traceIndexChange);
> return true;
> }
> }
> }
> return false;
> }
> {code}
>
> *Intention of this Jira*
> We want to prove the we can safely revert the advancing commit index logic of follower.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)