Skip to content
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

Schema Engine: fix to account for Online DDL swapped tables #9324

Merged

Conversation

rohit-nayak-ps
Copy link
Contributor

@rohit-nayak-ps rohit-nayak-ps commented Dec 4, 2021

Description

This is based off of the external PR #9306 to try to fix the failing tests

This PR addresses the following bug in schema engine reload process:

  • The schema engine depends on the information_schema.tables create_time field to tell when a table is updated. Unlike the name might indicate, this field is updated when a structural DDL is performed on a table (e.g. a column add/delete).
  • As an optimization, the schema engine keeps track of the last time it loaded (reloaded) the schema, and saves this timestamp (called lastChange).
  • When reloading schema, for each table we then check the create_time for that table against this saved timestamp, and if it's older, we skip examining the table further for changes.
  • Vitess online DDL swaps the tables, and a table swap does not affect the create_time timestamp for the table (it remains the original timestamp of when online DDL created the temporary table). If after this, but before the online DDL is done and the tables are swapped, a schema reload is run (in any of the various ways), we will record all the changes in schema at that point, and save the current time in the schema engine's lastChange field.
  • Now, after the online DDL completes, a schema reload is internally signaled:
    • For the table we are interested in (the one that was just DDL-ed), the create_time field is now older than the schema engine lastChange field. We therefore do not update the schema engine's view of this table's schema.

Changes:

  • Instead of keeping track of the lastChange time in schema engine, we track the create_time of every table explicitly. On a subsequent refresh, if we find the create_time of the table reported by MySQL differs from what we have cached in-memory, then we will assume the table has changed and reload its schema.
  • This will address the issue with tables being swapped during OnlineDDL without the create_time being modified.

Related Issue(s)

Fixes #9287

Checklist

  • Should this PR be backported?
  • Tests were added or are not required
  • Documentation was added or is not required

Deployment Notes

mvh-stripe and others added 2 commits November 30, 2021 15:01
…ine DDL

Signed-off-by: Harish Mallipeddi <mvh@stripe.com>
… a second: for instance if a column is altered immediately after creation then we get test failures due to incorrect FIELD events which are based on the previous DDL. Unit tests: reload schema when tablets are added/deleted since the test schema engine is an external singleton

Signed-off-by: Rohit Nayak <rohit@planetscale.com>
if isInTablesMap && createTime < se.lastChange {
if isInTablesMap && createTime == tbl.CreateTime && !(createTime >= se.lastChange) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

createTime < se.lastChange looks same as !(createTime >= se.lastChange), can we keep the earlier check, looks easier to read.

Copy link
Contributor

@shlomi-noach shlomi-noach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comment on my side; agree to @harshit-gangal 's comment.

Otherwise LGTM and the change looks tiny.

@@ -343,7 +343,7 @@ func (se *Engine) reload(ctx context.Context) error {
// TODO(sougou); find a better way detect changed tables. This method
// seems unreliable. The endtoend test flags all tables as changed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's also update this old comment by Sugu. Shall we clarify here as comment why the logic is as it is? Basically copy+paste the PR comment to explain about table creation and Online DDL etc.

Signed-off-by: Rohit Nayak <rohit@planetscale.com>
@rohit-nayak-ps rohit-nayak-ps force-pushed the rn-schema-engine-reload-fix branch from b4f96d3 to a9f68d7 Compare December 8, 2021 09:04
@rohit-nayak-ps rohit-nayak-ps merged commit 583f406 into vitessio:main Dec 8, 2021
@rohit-nayak-ps rohit-nayak-ps deleted the rn-schema-engine-reload-fix branch December 8, 2021 12:36
DeathBorn pushed a commit to vinted/vitess that referenced this pull request Apr 13, 2023
Fix schema engine reload so it accounts for swapped tables during online DDL

Signed-off-by: Harish Mallipeddi <mvh@stripe.com>
Signed-off-by: Vilius Okockis <vilius.okockis@vinted.com>
DeathBorn pushed a commit to vinted/vitess that referenced this pull request Apr 13, 2023
Reinstate lastChange logic to handle multiple DDLs that happen within a second: for instance if a column is altered immediately after creation then we get test failures due to incorrect FIELD events which are based on the previous DDL. Unit tests: reload schema when tablets are added/deleted since the test schema engine is an external singleton

Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Signed-off-by: Vilius Okockis <vilius.okockis@vinted.com>
DeathBorn pushed a commit to vinted/vitess that referenced this pull request Apr 13, 2023
Address review comments

Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Signed-off-by: Vilius Okockis <vilius.okockis@vinted.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Schema engine does not reload schema correctly after online DDL
4 participants