-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(no)StoreV2 (Part 4): Backend hooks: precommit updates consistency_index #12855
Conversation
cec56af
to
f589fa2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Few minor comments.
aecf356
to
12cff65
Compare
12cff65
to
813e17a
Compare
@jingyih: I rebased the PR and its ready for review. |
1c7a248
to
eaeb3f9
Compare
a9fd806
to
d73e0c6
Compare
Every transaction committed to backend is writing most recent consistent_index. Makes sure that even automatically trigger commits of batch-transactions stays "really" consistent a.d. the most recent WAL log index applied.
860b572
to
851584f
Compare
851584f
to
f1123d6
Compare
@jingyih
I think that membership and version edits were in particular not bumping up the 'cindex' (as mvcc edits of backends were updating it, but not the direct edits to backend) Added to PR description. @gyuho please take a look at the proposed, more descriptive, names |
@ptabor Thanks for the explanation. This makes sense to me. In the past all membership related raft entries (or more generally, all cluster related) are not tied to consistent index, as the consistent index was designed for kv store (as opposed to metadata bucket which stores cluster related info). With your changes, it makes the handling of raft entries of different types more consistent. LGTM |
@@ -104,7 +104,6 @@ func (tw *storeTxnWrite) Put(key, value []byte, lease lease.LeaseID) int64 { | |||
func (tw *storeTxnWrite) End() { | |||
// only update index if the txn modifies the mvcc state. | |||
if len(tw.changes) != 0 { | |||
tw.s.saveIndex(tw.tx) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this breaks the atomicity of consistent index and writing transactions. @ptabor @ahrtr @serathius #13844
…rease Reason to store CI and term in backend was to make db fully independent snapshot, it was never meant to interfere with apply logic. Skip of CI was introduced for v2->v3 migration where we wanted to prevent it from decreasing when replaying wal in etcd-io#5391. By mistake it was added to apply flow during refactor in etcd-io#12855 (comment). Consistency index and term should only be negotiated and used by raft to make decisions. Their values should only driven by raft state machine and backend should only be responsible for storing them.
…rease Reason to store CI and term in backend was to make db fully independent snapshot, it was never meant to interfere with apply logic. Skip of CI was introduced for v2->v3 migration where we wanted to prevent it from decreasing when replaying wal in etcd-io#5391. By mistake it was added to apply flow during refactor in etcd-io#12855 (comment). Consistency index and term should only be negotiated and used by raft to make decisions. Their values should only driven by raft state machine and backend should only be responsible for storing them.
…rease Reason to store CI and term in backend was to make db fully independent snapshot, it was never meant to interfere with apply logic. Skip of CI was introduced for v2->v3 migration where we wanted to prevent it from decreasing when replaying wal in etcd-io#5391. By mistake it was added to apply flow during refactor in etcd-io#12855 (comment). Consistency index and term should only be negotiated and used by raft to make decisions. Their values should only driven by raft state machine and backend should only be responsible for storing them.
…rease Reason to store CI and term in backend was to make db fully independent snapshot, it was never meant to interfere with apply logic. Skip of CI was introduced for v2->v3 migration where we wanted to prevent it from decreasing when replaying wal in etcd-io#5391. By mistake it was added to apply flow during refactor in etcd-io#12855 (comment). Consistency index and term should only be negotiated and used by raft to make decisions. Their values should only driven by raft state machine and backend should only be responsible for storing them.
…rease Reason to store CI and term in backend was to make db fully independent snapshot, it was never meant to interfere with apply logic. Skip of CI was introduced for v2->v3 migration where we wanted to prevent it from decreasing when replaying wal in etcd-io#5391. By mistake it was added to apply flow during refactor in etcd-io#12855 (comment). Consistency index and term should only be negotiated and used by raft to make decisions. Their values should only driven by raft state machine and backend should only be responsible for storing them.
Implemented hooks mechanism in the backend, in particular pre-commit hook that:
Integrated it with
cindex
, such that every transaction committed to backend is writing most recent consistent_index.Makes sure that even automatically trigger commits of batch-transactions stays "really" consistent a.d. the most recent WAL log index applied. Prior to this PR membership and version edits were in particular not bumping up the 'cindex'.
Part of: #12913