Skip to content

Commit ecb4547

Browse files
committed
Snapshot calculation must continue
Do not block snapshot calculation even if there's an ongoing snapshot stream. If this stream takes a long time and we don't calculate snapshot, we run the risk of increasing the size of Raft logs so much that it causes group wide issues.
1 parent b190127 commit ecb4547

1 file changed

Lines changed: 6 additions & 4 deletions

File tree

worker/draft.go

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1000,10 +1000,12 @@ func (n *node) calculateSnapshot(discardN int) (*pb.Snapshot, error) {
10001000
_, span := otrace.StartSpan(n.ctx, "Calculate.Snapshot")
10011001
defer span.End()
10021002

1003-
if atomic.LoadInt32(&n.streaming) > 0 {
1004-
span.Annotate(nil, "Skipping calculateSnapshot due to streaming")
1005-
return nil, nil
1006-
}
1003+
// We do not need to block snapshot calculation because of a pending stream. Badger would have
1004+
// pending iterators which would ensure that the data above their read ts would not be
1005+
// discarded. Secondly, if a new snapshot does get calculated and applied, the follower can just
1006+
// ask for the new snapshot. Blocking snapshot calculation has caused us issues when a follower
1007+
// somehow kept streaming forever. Then, the leader didn't calculate snapshot, instead it
1008+
// kept appending to Raft logs forever causing group wide issues.
10071009

10081010
first, err := n.Store.FirstIndex()
10091011
if err != nil {

0 commit comments

Comments
 (0)