-
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
VStreamer: recompute table plan if a new table is encountered for the same id #9978
VStreamer: recompute table plan if a new table is encountered for the same id #9978
Conversation
…same id Signed-off-by: Rohit Nayak <[email protected]>
Signed-off-by: Rohit Nayak <[email protected]>
Signed-off-by: Rohit Nayak <[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.
Just a small nit about the log message (feel free to ignore).
Thank you!
return nil, nil | ||
} | ||
vs.plans[id] = nil | ||
log.Infof("table map changed: id %d for %s has changed to %s", id, plan.Table.Name, tm.Name) |
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.
Maybe also note that we will reload and cache a new plan for the table to avoid concern and indicate corrective action being taken ~:
log.Infof("Table plan map changed in VStream: the id %d was associated with %s and now represents %s. We will reload and cache a new plan for the table.", id, plan.Table.Name, tm.Name)
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.
Good suggestion, I will update in my next PR though, rather than start another CI cycle for this ...
… same id (vitessio#9978) * Recompute the plan for a table if a new table is encountered for the same id Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]>
… same id (vitessio#9978) * Recompute the plan for a table if a new table is encountered for the same id Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]>
… same id (vitessio#9978) * Recompute the plan for a table if a new table is encountered for the same id Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]>
… same id (#9978) (#11148) * Recompute the plan for a table if a new table is encountered for the same id Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]> Signed-off-by: Rohit Nayak <[email protected]>
… same id (#9978) (#11149) * Recompute the plan for a table if a new table is encountered for the same id Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]> * Trigger rebuild Signed-off-by: Rohit Nayak <[email protected]> Signed-off-by: Rohit Nayak <[email protected]>
Description
VStreamer caches a "table plan" for each new table it encounters via the binlog TABLE_MAP_EVENT.
MySQL internally generates a unique (incrementing) id for a table as it inserts them into the binlog. The first time we see an id, we compute the table plan (essentially the list of columns with name and type information). If we get the same id again, we currently assume it is the same table and use the cached plan.
However when the mysql server restarts it starts a new numbering for table ids and depending on the DMLs encountered the table id map can be different from the earlier one.
Thus the binlog will contain the same id for different tables. While streaming from an older GTID, it can happen that we have cached a plan for table1 for id 100, say. And later we get the same id 100 for table2. Usually this will result in an error because the fields for the table will not match the row image. If a vstreamer encounters an error it just restarts after 5 seconds, when it recreates the plans and heals itself.
But in rare situations where the schemas are almost identical we can generate unrelated FieldEvents and consequently a DML for the wrong table.
This PR adds a check before using a cached plan. If the table name for the cached plan doesn't match that for the table map event, it nullifies that cache entry and recomputes the plan for this id.
Signed-off-by: Rohit Nayak [email protected]
Related Issue(s)
#9976
Checklist