You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We enabled schema tracking on vttablet, the goal is we can track schema changes properly so that we can stitch row event with field events together. It works well with the raw ALTER TABLE sql statements. However, it does not work with schema migration with online ddl. We got cannot determine table columns for messages error after the online ddl finished, which indicates the schema tracker still holds the old schema and it does not match the one we get from TABLE_MAP_EVENT
Skim through the code, I think this is because in onlind ddl schema migration, we mark the "end" of it with a RENAME TABLE statement - it should be the signal for Vitess to reload schema for the table. However, Vitess parse RENAME TABLE to a RenameTable which does not have a table name, therefore we skip the reload call.
Reproduction Steps
If my theory is correct, it can be reproduced by a unit test:
Overview of the Issue
We enabled schema tracking on vttablet, the goal is we can track schema changes properly so that we can stitch row event with field events together. It works well with the raw
ALTER TABLE
sql statements. However, it does not work with schema migration with online ddl. We gotcannot determine table columns for messages
error after the online ddl finished, which indicates the schema tracker still holds the old schema and it does not match the one we get fromTABLE_MAP_EVENT
Skim through the code, I think this is because in onlind ddl schema migration, we mark the "end" of it with a
RENAME TABLE
statement - it should be the signal for Vitess to reload schema for the table. However, Vitess parseRENAME TABLE
to a RenameTable which does not have a table name, therefore we skip the reload call.Reproduction Steps
If my theory is correct, it can be reproduced by a unit test:
Or to reproduce it end to end:
Operating system and Environment details
Running on top of 4358c6a
Log Fragments
The text was updated successfully, but these errors were encountered: