Add tracking session state changes for transaction start #11061
Merged
Conversation
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
dbussink
added
Type: Enhancement
dbussink
requested review from
ajm188,
doeg,
notfelineit,
harshit-gangal and
systay
as code owners
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Bug fixes
Non-trivial changes
New/Existing features
Backward compatibility
|
3 tasks
shlomi-noach
approved these changes
Aug 22, 2022
We also run a number of CI tests internally in PlanetScale and I think that that's the place where we would run against our MySQL fork as well to validate this behavior there too. |
|
Recap on how this is being tested: in this PR Vitess queries the MySQL server to test whether it supports This repo, The most relevant test, one that catches flaws in consistency logic, is |
This logic depends on the custom option that PlanetScale as in it's MySQL fork to get the current committed GTID at the start of a transaction snapshot. With this GTID, we can optimize vreplication to avoid having to lock tables around vreplication operations. See planetscale/mysql-server@9fa67ec for the change in MySQL that is published in our fork. The change here allows getting back this value through any query operation that might start a transaction. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
… tables while still getting a transaction consistent GTID Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
dbussink
force-pushed
the
dbussink/allow-using-new-start-gtid
branch
from
f88af23 to
ad6989e
Compare
notfelineit
pushed a commit
to planetscale/vitess
that referenced
this pull request
Sep 21, 2022
) (vitessio#990) * Add tracking session state changes for transaction start This logic depends on the custom option that PlanetScale as in it's MySQL fork to get the current committed GTID at the start of a transaction snapshot. With this GTID, we can optimize vreplication to avoid having to lock tables around vreplication operations. See planetscale/mysql-server@9fa67ec for the change in MySQL that is published in our fork. The change here allows getting back this value through any query operation that might start a transaction. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com> * Use 'session_track_gtids = START_GTID' where possible, and avoid LOCK tables while still getting a transaction consistent GTID Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com> Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com> Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com> Co-authored-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com> Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com> Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com> Co-authored-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
This was referenced Jul 17, 2024
Feature Request: ability to control streamer snapshot method (GTID tracking vs table locking)
#16420
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This logic depends on the custom option that PlanetScale as in it's MySQL fork to get the current committed GTID at the start of a transaction snapshot.
With this GTID, we can optimize vreplication to avoid having to lock tables around vreplication operations.
See planetscale/mysql-server@9fa67ec for the change in MySQL that is published in our fork.
The change here allows getting back this value through any query operation that might start a transaction.
With this change, we can essentially do what was attempted in #9991 but it will guarantee now a consistent GTID for the snapshot.
The first commit here wires up passing through the session state changes on transaction start, the second commit starts using it for VReplication.
Related Issue(s)
See #9991 for a previous failed attempt.
Checklist