【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】tidb 6.5
【复现路径】 ticdc条件过滤
ignore-delete-value-expr = “name = ‘john’” # 过滤掉包含 name = ‘john’ 条件的 delete DML
我设置了ignore-delete-value-expr = “1 = 1’” #
我cdc配置文件，配置了上述过滤条件，目的是为了区分我手工删除不同步到下游，实际业务删除同步下游
delete from t_table where no=‘92171802708161882’ and 1 = 1
上述人为手工删除语句同步到kafka里面了
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
你这里多了一个引号？
没用，cdc抓取的是tikv的变化日志，cdc看不到你原始执行SQL的，它的过滤是根据值的value过滤的
ignore-delete-value-expr：配置一个 SQL 表达式，对带有指定值的 DELETE 类型的 DML 事件生效。ignore-insert-value-expr：配置一个 SQL 表达式，对带有指定值的 INSERT 类型的 DML 事件生效。ignore-update-old-value-expr：配置一个 SQL 表达式，对带有指定旧值的 UPDATE 类型的 DML 事件生效。ignore-update-new-value-expr：配置一个 SQL 表达式，对带有指定新值的 UPDATE 类型的 DML 事件生效。这个 1=1 实际没作用，是会在逻辑优化阶段被优化掉的，ignore-delete-value-expr 必须是实际要删除的列的范围才会生效。
我也觉的where 1=1无用，只是为了给语句打标记，具体值才有用，而且使用表达式过滤后，批量删除不同步的数据，会导致cdc延迟
必须要认真啊。
我是认真测试我需要实现的功能呀
CDC获取的是tikv 的变更数据，只认行数据的变更操作，无法识别你是手工变更还是业务变更的。
所以，结论是不管来源是谁，只要变更了一行数据，ticdc就会它这些变更行为同步到下游。
cdc获取变更的底层是从tikv的keyvalue来获取的，不是通过tidb-server的binlog来获取的，所以你sql上的差异，它无法区分
无法区分
无法区分的