-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Track shard moves for version vector #11977
base: main
Are you sure you want to change the base?
Conversation
Result of foundationdb-pr-clang-ide on Linux CentOS 7
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux CentOS 7
|
Result of foundationdb-pr-cluster-tests on Linux CentOS 7
|
Result of foundationdb-pr on Linux CentOS 7
|
dbf1126
to
6410831
Compare
Result of foundationdb-pr-clang-ide on Linux CentOS 7
|
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
@@ -88,8 +88,7 @@ class RecentStateTransactionsInfo { | |||
// sends this request has them and will apply them via applyMetadataToCommittedTransactions(); | |||
// and other proxies will get this version's state txns as a prior version. | |||
for (; stateTransactionItr != endItr; ++stateTransactionItr) { | |||
shardChangedOrStateTxn = | |||
shardChangedOrStateTxn || stateTransactionItr->value.first || stateTransactionItr->value.second.size(); | |||
shardChangedOrStateTxn = shardChangedOrStateTxn || stateTransactionItr->value.first; |
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.
does this line change fix a bug?
maybe when shardChangedOrStateTxn
is false, we can just continue
?
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 makes it more efficient, we do not need to send to all tLogs on the local CP if another CP modified the transaction state store- the other CP will commit the change.
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-cluster-tests on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux CentOS 7
|
Result of foundationdb-pr on Linux CentOS 7
|
@@ -861,6 +865,7 @@ std::set<Tag> CommitBatchContext::getWrittenTagsPreResolution() { | |||
toCommit.storeRandomRouterTag(); | |||
transactionTags.insert(toCommit.savedRandomRouterTag.get()); | |||
} | |||
lastShardMove = pProxyCommitData->lastShardMove; | |||
|
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.
Isn't there a timing issue here? The last shard move version would need to be obtained at the time the transaction gets started/the time the tags get collected? I think it should be at the point where we start accessing the shard metadata in this transaction? Else, the last shard move version could get updated in this window and we might not report the correct version to the resolver?
@@ -277,6 +277,8 @@ struct ProxyCommitData { | |||
std::shared_ptr<AccumulativeChecksumBuilder> acsBuilder = nullptr; | |||
LogEpoch epoch; | |||
|
|||
Version lastShardMove; | |||
|
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.
Where is this getting populated please? Is that done in a different commit?
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.
the constructor initializes it to invalidVersion. But it should be updated on return from the resolver, this line was dropped when I ported by debug patch. I'll update the PR.
With version vector, store the most recent version that modified the shard map on the resolvers, and include this value on replies back to the CP. On commits, the CP sends to the RV what it thinks is the most recent version of a shard change. If the CP is behind the RV, it is unaware of the latest shard change and may have the wrong set of tags; send the commit to all logs.
scenario
Code-Reviewer Section
The general pull request guidelines can be found here.
Please check each of the following things and check all boxes before accepting a PR.
For Release-Branches
If this PR is made against a release-branch, please also check the following:
release-branch
ormain
if this is the youngest branch)