Repository navigation
Remove stale tableId mapping in RDS source (MySQL) when a table id is reused - #7162
Merged
graytaylor0 merged 1 commit intoSep 30, 2026
Conversation
The MySQL RDS source keeps an in-memory `tableId -> TableMetadata` map that is built from binlog TABLE_MAP events. `handleTableMapEvent` returned early for any table that is not of interest without touching the map, so an entry recorded for a table of interest survived indefinitely. The binlog `table_id` is assigned by the server from its table definition cache and is not stable: it can be reassigned to a different table across a server restart, and also when a table is evicted from and reloaded into the cache. When a table id previously bound to a table of interest was reassigned to a table that is not of interest, `isValidTableId` still accepted the row events for that table because the stale entry was present and pointed at a table of interest. Those rows were then decoded using the wrong column definitions, which silently wrote corrupted documents to the sink and raised type-conversion errors for the rows whose types did not line up. Remove the mapping held for a table id whenever a TABLE_MAP event shows the id now refers to a table that is not of interest, so subsequent row events for that id are skipped as intended. Resolves opensearch-project#7125 Signed-off-by: Masaki Mori <masakigg@amazon.co.jp>
gg-mskm
requested review from
KarstenSchnitter,
Zhangxunmt,
dinujoh,
divbok,
dlvenable,
graytaylor0,
kkondaka,
oeyh,
san81,
sb2k16,
srikanthjg and
srikanthpadakanti
as code owners
September 25, 2026 10:51
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
graytaylor0
approved these changes
Sep 29, 2026
graytaylor0
left a comment
Member
There was a problem hiding this comment.
Thanks for addressing this!
oeyh
approved these changes
Sep 30, 2026
graytaylor0
pushed a commit
to graytaylor0/data-prepper
that referenced
this pull request
Oct 1, 2026
…pensearch-project#7162) The MySQL RDS source keeps an in-memory `tableId -> TableMetadata` map that is built from binlog TABLE_MAP events. `handleTableMapEvent` returned early for any table that is not of interest without touching the map, so an entry recorded for a table of interest survived indefinitely. The binlog `table_id` is assigned by the server from its table definition cache and is not stable: it can be reassigned to a different table across a server restart, and also when a table is evicted from and reloaded into the cache. When a table id previously bound to a table of interest was reassigned to a table that is not of interest, `isValidTableId` still accepted the row events for that table because the stale entry was present and pointed at a table of interest. Those rows were then decoded using the wrong column definitions, which silently wrote corrupted documents to the sink and raised type-conversion errors for the rows whose types did not line up. Remove the mapping held for a table id whenever a TABLE_MAP event shows the id now refers to a table that is not of interest, so subsequent row events for that id are skipped as intended. Resolves opensearch-project#7125 Signed-off-by: Masaki Mori <masakigg@amazon.co.jp> Co-authored-by: Masaki Mori <masakigg@amazon.co.jp>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
In the RDS source's CDC/binlog stream mode,
BinlogEventListenerkeeps an in-memorytableId -> TableMetadatamap (tableMetadataMap) that is populated from binlog TABLE_MAP events.handleTableMapEventreturned early for any table that is not of interest without touching the map, so an entry recorded for a table of interest survived indefinitely and was never invalidated.The binlog
table_idis not stable: the server assigns it from its table definition cache and can reassign it to a different table across a server restart (and when a table is evicted from and reloaded into the cache). When atable_idpreviously bound to a synced table is reassigned to a non-synced table,isValidTableIdstill accepts the row events because the stale entry is present and points at a synced table. Those rows are then decoded with the wrong column definitions, which silently writes corrupted documents to the sink (for example a byte-arraynamerendered as[B@30fb30c]) and raises type-conversion errors for rows whose types do not line up. This reproduces on routine operational events such as an Aurora reboot, maintenance, or failover.This change removes the mapping held for a
table_idwhenever a TABLE_MAP event shows that the id now refers to a table that is not of interest, so subsequent row events for that id are skipped as intended. Mappings for tables of interest are unaffected; they are already overwritten on every TABLE_MAP event.Verification:
BinlogEventListenerTest. Without the fix the stale-mapping test fails (isValidTableIdreturnstruefor a reassigned id); with the fix all tests pass.aurora-mysql 3.10.4): after forcing atable_idcollision across a reboot, the unfixed build reproduces theRow data length (25) does not match column names size (21)WARN and writes corrupted documents, while the fixed build removes the stale entry, skips the non-synced rows, and writes no corrupted documents. Synced-table replication is unchanged in both cases.Issues Resolved
Resolves #7125
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.