From 601cb79aa65b9eebd2f142b1c64b753ce995b3be Mon Sep 17 00:00:00 2001 From: Ben Darnell Date: Wed, 26 Oct 2016 08:46:00 +0900 Subject: [PATCH] storage: Stop calling raftGroup.TickQuiesced This was a workaround for the interaction between quiesced ranges and CheckQuorum, and is no longer needed now that we have switched from CheckQuorum to PreVote. Reverts #9407 --- pkg/storage/replica.go | 20 -------------------- 1 file changed, 20 deletions(-) diff --git a/pkg/storage/replica.go b/pkg/storage/replica.go index ca70c7d72f07..c683e2a9268d 100644 --- a/pkg/storage/replica.go +++ b/pkg/storage/replica.go @@ -2216,26 +2216,6 @@ func (r *Replica) tickRaftMuLocked() (bool, error) { return false, nil } if r.mu.quiescent { - // While a replica is quiesced we still advance its logical clock. This is - // necessary to avoid a scenario where the leader quiesces and a follower - // does not. The follower calls an election but the election fails because - // the leader and other follower believe that no time in the current term - // has passed. The Raft group is then in a state where one member has a - // term that is advanced which will then cause subsequent heartbeats from - // the existing leader to be rejected in a way that the leader will step - // down. This situation is caused by an interaction between quiescence and - // the Raft CheckQuorum feature which relies on the logical clock ticking - // at roughly the same rate on all members of the group. - // - // By ticking the logical clock (incrementing an integer) we avoid this - // situation. If one of the followers does not quiesce it will call an - // election but the election will succeed. Note that while we expect such - // elections from quiesced followers to be extremely rare, it is very - // difficult to completely eliminate them so we want to minimize the - // disruption when they do occur. - // - // For more details, see #9372. - r.mu.internalRaftGroup.TickQuiesced() return false, nil } if r.maybeQuiesceLocked() {