ticdc手工删除信息不同步到下游,业务删除信息同步到下游,如何做到

【 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上的差异,它无法区分

无法区分

无法区分的