[
https://issues.apache.org/jira/browse/FLINK-39200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cong Cheng updated FLINK-39200:
-------------------------------
Description:
Currently, the MySQL row event deserializers in Flink CDC always fully
deserialize WRITE/UPDATE/DELETE binlog events for all tables, regardless of
whether the tables are actually subscribed by the connector.
This will lead to unnecessary CPU and memory overhead for rows from unmonitored
tables especially when a small portion of overall tables are consumed.
Thus, the deserialization of unmonitored tables should be skipped early instead
of filtering deserialized changed rows afterwards.
was:
Currently, the MySQL row event deserializers in Flink CDC always fully
deserialize WRITE/UPDATE/DELETE binlog events for all tables, regardless of
whether the tables are actually subscribed by the connector.
This will lead to unnecessary CPU and memory overhead for rows from unmonitored
tables especially when a small portion of overall tables are consumed.
Thus, the deserialization of unmonitored tables should be skipped early instead
of filtering deserialized changed rows afterwards.
> Skip deserialization of unsubscribed tables in MySql CDC binary log client
> --------------------------------------------------------------------------
>
> Key: FLINK-39200
> URL: https://issues.apache.org/jira/browse/FLINK-39200
> Project: Flink
> Issue Type: New Feature
> Components: Flink CDC
> Affects Versions: cdc-3.6.0
> Reporter: Cong Cheng
> Priority: Major
>
> Currently, the MySQL row event deserializers in Flink CDC always fully
> deserialize WRITE/UPDATE/DELETE binlog events for all tables, regardless of
> whether the tables are actually subscribed by the connector.
> This will lead to unnecessary CPU and memory overhead for rows from
> unmonitored tables especially when a small portion of overall tables are
> consumed.
> Thus, the deserialization of unmonitored tables should be skipped early
> instead of filtering deserialized changed rows afterwards.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
