【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】
修改表的字段类型称为 Reorg DDL，会同时修改元数据和表数据。修改表数据会导致ticdc出现延迟，哪个版本修改字段类型Reorg DDL，ticdc不出现延迟
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
你现在用的是哪个版本？
6.5.0版本
有哪个数据库可以做到ddl改元数据和数据不同步的吗？
tidb 5.1版本支持reorg ddl, 6.2版本tidb采用并发框架，可异步处理DDL, 6.5版本优化了ticdc同步DML数据时，DDL对其的影响，按照 DML → DDL → DML 的顺序执行，同时支持过滤指定类型的 DDL 事件。
表字段类型变了，原来的数据还想不变类型？
有损变更必须要回填数据吧 
，无损变更应该不用
1 个赞
TiCDC是实时获取TiKV行数据的变更日志的工具，如果修改了数据类型出现同步延迟，说明一定是因为修改了数据类型导致了大量数据的变更出现。
在TiDB里，什么时候会出现修改数据类型而会修改数据呢？没错，就是有损变更的时候，比如int转varchar，通常是从大范围到小范围或跨数据类型的类型修改，具体哪些类型属于有损变更可以参考官网的说明。
反之，就是你第二个问题的答案，对于修改的数据类型不会出现有损变更的时候，就不会变更数据行，就不会改动大量数据，此时不会出现TiCDC的同步延迟，比如tinyint 转int等。
修改表的元数据时可以指定列的类型，还指定原来的类型就不会变
可以发一下具体修改的类型，从什么类型改为什么类型。
我觉得改了字段类型，不触发修改数据 不大可能实现。
你的适用场景是什么，应该有前提条件吧，比如原有字符串是abc，你强制把类型改成int，肯定应该无法修改的
timestamp类型改成datetime类型，我怀疑timestamp类型有bug问题，大批量删除数据，并且有高并发事务时候有可能导致数据和索引不一致
会有延迟啊，出现延迟，但是后续会继续同步吧
datetime字段如果不设置精度的话，默认是精度为0，只保留到秒吧。从实际上来说应该是有损的调整了。感觉不大可能不动元数据。
实际是会动实际数据的类型，而且cdc会延迟，我动了10G的表，下游kafka数据量剧增
你这是没有遇到问题吧，10G的表，下游kafka都能一二百G，如果要改很大的表，下游kafka都能给打爆
确实没有遇到，我们是下游mysql,暂时还没有遇到过修改数据类型的，如果按你这么说，那么下游mysql也可能没办法同步了。
如果晚上没有业务数据写入时，可以先停掉cdc。
个人感觉两个时间类型通过配置，timestamp 转为datetime可以成为无损转换。
DATETIME和TIMESTAMP除了存储需求不同外：
TIMESTAMP数据类型，是将日期时间数据转化为UTC（世界标准时间）进行存储，在查询时也是将数据转化为当前所在的时区的时间进行返回。
DATETIME数据类型，输入的是什么时间，存入的就是什么时间，查询时返回的也是输入时的时间，不会进行时区转换
设置DATETIME和TIMESTAMP的初始化值，可以为null、在取值范围内的任意时间戳、或者当前时间戳
你varchar(10)改5可不就相当于当前字段修改为把当前字段的substr(1,5)?