-
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
OnlineDDL: reject duplicate UUID with different migration_context #9637
OnlineDDL: reject duplicate UUID with different migration_context #9637
Conversation
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
- `vtctl ApplySchema -uuid_list='...'` now rejects a migration if an existing migration has the same UUID but with different `migration_context`. | ||
|
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.
Wrong file? This is the 10.0.4 release notes.
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.
wrong file indeed
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
The test Excerpt:
|
Description
Followup to #9325. In this PR we reject a migration if submitted with same UUID and different
migration_context
.As reminder, the user is allowed to supply their own migration UUIDs via
vtctl ApplySchema -uuid_list='...'
. This functionality is used to allow the user control and idempotency over their migrations.UUID is a unique migration identifier. It is impossible to have any two migrations on same shard with same UUID. Hence, when one submits
-uuid_list=...
with an already existing UUID, their submission does not create a new migration. However, it is then also reasonable to expect that the user provides-migration_context
. If the same migration is submitted twice or more, with same UUID and samemigration_context
, that is fine. The newer submissions are silently ignored, and this is a desired behavior that allows idempotency.However, if the new submission uses a different
migration_context
(either because the user has specified one, that is different from the original one; or the user has specified none at all, in which casevtctl
generates a random, unique value), then we consider this as an unintentional duplication, and as of this PR we return an error.Here is a valid resubmission:
Here is an invalid one:
Related Issue(s)
Checklist
cc @dbussink @fatih @mavenraven