-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
VReplication: Remove auto_increment clauses for MoveTables to a sharded keyspace #15679
Conversation
Signed-off-by: Matt Lord <[email protected]>
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #15679 +/- ##
=======================================
Coverage 68.37% 68.37%
=======================================
Files 1556 1556
Lines 195051 195120 +69
=======================================
+ Hits 133365 133416 +51
- Misses 61686 61704 +18 ☔ View full report in Codecov by Sentry. |
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
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.
Looks good! One nit ask for a test change.
go/vt/vtctl/workflow/utils.go
Outdated
return true | ||
} | ||
|
||
noAutoIncAST := sqlparser.Rewrite(ast, stripAutoIncrement, nil) |
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 think it would have been easier to use Walk()
, to jump right into a Column
definition, but it's fine as it is.
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.
Thanks! Did I misunderstand what you meant? https://github.com/vitessio/vitess/pull/15679/files#diff-d3a320c7b03791f5d24189e3ae6d7fcac814f4fa1b3d7c02d496b3d8f0adf588R220
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.
Perfect!
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Signed-off-by: Matt Lord <[email protected]>
Description
It's common to move one or more tables from an unsharded keyspace to a sharded one as a subset of tables become too large and must be split — or when moving tables from a standalone MySQL instance to Vitess and sharding them in the process.
For unsharded tables it's standard to use MySQL's
auto_increment
feature so that a unique Primary Key value is automatically generated and assigned for each row. Once those tables are sharded, however, you DO NOT typically want to use them as each row needs to be unique across ALL shards rather than within a single MySQL instance/shard. You should instead use something generated externally such as some form of a globally/universally unique identifier or Vitess Sequences.Given this explicit best practice, we should perform this work for you automatically within Vitess by default (with the ability to opt-out) when moving tables from an unsharded keyspace to a sharded one. This avoids potential mistakes down the line (something that does a direct insert in the mysqld instance w/o providing a PK value, expecting a unique one to be generated when it's not) and prevents the user from having to perform other perhaps heavy manual operations such as later running an ALTER TABLE on the tables.
Related Issue(s)
Checklist