-
- Downloads
Simplify Snapshots (#2475)
We had a complicated mechanism to keep track of which transactions have been concluded, and which Raft proposals corresponded to those transactions. This required us to have a txnMark watermark, which kept track of all applied mutations and their Raft indices, which is quite confusing. Instead, now we just make use of the StartTs stored in proposal.Mutations and the fact that we have a Oracle which already knows the status of transactions. I make use of those givens to remove txnMarks and simplify how we do snapshots. Further more, I now propose snapshot indices so that the entire Raft group is synchronized on the same snapshot index, calculated by the leader. This also makes it clear that only leader does the snapshot calculation, and the corresponding action of aborting old transactions, with no health signal for some time. Also, rename MaxPending to MaxAssigned, which is a better term for what the variable holds, i.e. MaxAssigned timestamp by Zero so far.
Showing
- contrib/scripts/functions.sh 2 additions, 2 deletionscontrib/scripts/functions.sh
- dgraph/cmd/zero/oracle.go 11 additions, 12 deletionsdgraph/cmd/zero/oracle.go
- dgraph/docker-compose.yml 69 additions, 68 deletionsdgraph/docker-compose.yml
- posting/mvcc.go 8 additions, 43 deletionsposting/mvcc.go
- posting/oracle.go 64 additions, 12 deletionsposting/oracle.go
- protos/intern/internal.pb.go 535 additions, 267 deletionsprotos/intern/internal.pb.go
- protos/internal.proto 28 additions, 21 deletionsprotos/internal.proto
- query/query_test.go 2 additions, 2 deletionsquery/query_test.go
- systest/loader_test.go 12 additions, 13 deletionssystest/loader_test.go
- worker/draft.go 155 additions, 85 deletionsworker/draft.go
- worker/groups.go 2 additions, 2 deletionsworker/groups.go
- worker/predicate_test.go 1 addition, 1 deletionworker/predicate_test.go
- worker/worker.go 0 additions, 1 deletionworker/worker.go
Loading
Please register or sign in to comment