-
Notifications
You must be signed in to change notification settings - Fork 593
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
feat(meta): support inject barrier to enable and disable writing old value for subscription #16460
Merged
Merged
Changes from 20 commits
Commits
Show all changes
24 commits
Select commit
Hold shift + click to select a range
43c84c3
feat(storage): store old value in memtable
wenym1 eff6a5c
add delete only test epoch
wenym1 beb2823
Merge branch 'main' into yiming/old-value-memtable
wenym1 e989c03
fix
wenym1 461560c
maintain log store table id in command ctx
wenym1 e4529d5
Merge branch 'main' into yiming/old-value-memtable
wenym1 4c797aa
support truncate
wenym1 0a4824f
feat(meta): support inject barrier to enable and disable writing old …
wenym1 b6044fa
commit with log store info
wenym1 842e828
fix measure batch size
wenym1 5c9d3d8
fix test
wenym1 4ea21d9
Merge branch 'main' into yiming/old-value-memtable
wenym1 4af4cb8
Merge branch 'yiming/old-value-memtable' into yiming/subscription-bar…
wenym1 798877d
refactor(state-table): make consistent op an enum in state table
wenym1 5576d6f
add comment
wenym1 3dc9fdf
apply comment
wenym1 9038ae5
Merge branch 'yiming/state-table-op-consistency-enum' into yiming/sub…
wenym1 9ea5174
Merge branch 'main' into yiming/state-table-op-consistency-enum
wenym1 d13768d
Merge branch 'yiming/state-table-op-consistency-enum' into yiming/sub…
wenym1 3a9ce59
Merge branch 'main' into yiming/subscription-barrier
wenym1 03a5a18
Merge branch 'main' into yiming/subscription-barrier
wenym1 79ec559
refine
wenym1 015cf80
Merge branch 'main' into yiming/subscription-barrier
wenym1 6e447e9
add log to new command
wenym1 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Placing such a field here (and all the related code path) looks quite ad-hoc to me... Why isn't it a field in
stream_plan::StreamActor
?A related question: how is this information persisted?
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.
We just use the subscription information persisted in catalog.
I used to think about adding it as a field of
StreamActor
. But sinceStreamActor
is also persisted, we will have to carefully maintain the consistency between the subscription information persisted in catalog and theStreamActor
. However, such information inStreamActor
is redundant, and the effort to carefully maintain the consistency is unnecessary.So at the end I chose the current implementation.
Plus: I think the dispatcher information is also unnecessary to be persisted in
StreamActor
, since, IIUC, the dispatcher information can be recalculated when we know the upstream and downstream distribution, and therefore the persisted dispatcher information is also unnecessary, and we will also have to carefully maintain the consistency.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.
This sounds ok to me.
My concern is on this field
related_subscriptions
. Basically, theBuildActorsRequest
RPC and all the subsequent calls only passactor_ids
, while the additional information such as the definition of the actors are stored in metadata and collected later. To keep the code consistent and clean, I think here we should also follow this style.Plus:
The actors need to know exactly which downstream actors it should connect to. Imagine that when one CN fails and restarts, the actors on it will be recreated while the rest CN doesn't need to do so. Is such information preserve somewhere?
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.
IIUC, the dispatch information can be calculated as long as we have the vnode distribution of upstream and downstream. For example, the upstream actor owns vnode [1, 2, 3], and then if we know the downstream actor A owns vnode1, B owns vnode2 and C owns vnode3, and then we will know that the upstream actor should dispatch to downstream actor A, B and C.
Currently, when a CN fails, a recovery will be triggered, and all actors will be rebuilt. Meta node should have the persisted vnode distribution information of all actors, and then the dispatcher information can be calculated as well, and then the actor can know which actors to connect.
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.
I see. You mean the
vnode_bitmap
in the downstream actors, which defines the data distribution of all state tables in that fragment/actors. Technically, it seems possible to have different distribution key in shuffle and state table, even though I believe in our system they are always same. 🤔