-
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
Schema Engine: fix to account for Online DDL swapped tables #9324
Schema Engine: fix to account for Online DDL swapped tables #9324
Conversation
…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) { |
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.
createTime < se.lastChange
looks same as !(createTime >= se.lastChange)
, can we keep the earlier check, looks easier to read.
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.
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. |
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.
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>
b4f96d3
to
a9f68d7
Compare
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>
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>
Address review comments Signed-off-by: Rohit Nayak <rohit@planetscale.com> Signed-off-by: Vilius Okockis <vilius.okockis@vinted.com>
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:
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).lastChange
).create_time
for that table against this saved timestamp, and if it's older, we skip examining the table further for changes.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'slastChange
field.create_time
field is now older than the schema enginelastChange
field. We therefore do not update the schema engine's view of this table's schema.Changes:
lastChange
time in schema engine, we track thecreate_time
of every table explicitly. On a subsequent refresh, if we find thecreate_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.create_time
being modified.Related Issue(s)
Fixes #9287
Checklist
Deployment Notes