【 TiDB 使用环境】DM v2.0.6 TIDB V4.0.8
【概述】 使用dm同步mysql作为上游的数据源时，mysql侧有简单的alter table tables add cdd int(4) comment :“ccccc” 类似语句dm这边直接跳过
【备份和数据迁移策略逻辑】 先全量再增量
【背景】
【现象】上游增加字段时，dm worker 节点日志是skip event ，明明配置文件没有做任何过滤，跳过的设置
【问题】 上游出现增加普通字段时，下游报错，上下游字段数不一致
1）dm同步，是用乐观模式还是悲观模式？
2）可以把dm的配置贴出来看看
大致的配置是这样的
模式呢？
没有配置模式
你这个有合并表的操作，必须要配置模式，默认是空，是无需协调的
shard-mode: "pessimistic" # 默认值为 "" 即无需协调。如果为分库分表合并任务，请设置为悲观协调模式 "pessimistic"。在深入了解乐观协调模式的原理和使用限制后，也可以设置为乐观协调模式 "optimistic"
这个没有涉及到合并表的操作，mysql 跟tidb是一对一的
1）不好意思，看错配置，你这个配置文件有库表黑白名单和route关系两块，没有filter配置，那就是用的filter默认配置。
2）麻烦把具体的SQL语句发下
3）麻烦把dm-worker跳过的对应的DDL日志发下
谢谢
mysql端的sql操作是 :USE pressure_measurement;
ALTER TABLE t_notebill_month_0
ADD COLUMN test_01 INT(4) COMMENT ‘测试字段2’;
dm worker 日志：[2022/02/16 20:02:11.610 +08:00] [WARN] [ddl.go:160] [“skip event”] [task=task_test] [unit=“binlog replication”] [event=query] [statement=“ALTER TABLE pressure_measurement.zzzt_test1_gho ADD COLUMN test_01 INT(4) COMMENT ‘测试字段2’”] [schema=pressure_measurement]
这个表都没有在dm的block-allow-list里面，跳过岂不是很正常？
mysql侧，做的是 t_notebill_month_0的修改，为啥到dm这边就变成了zzzt_test1_gho了呢?这边也没有做其他的处理。
怀疑是配置的问题，可以查看先当前运行的配置是什么，而不是配置文件的配置的是什么。
具体方法有几个，可以参考：
https://docs.pingcap.com/zh/tidb/stable/dm-export-import-config
DBA侧反馈是这样的：现在在mysql做的ddl操作，都是用ghost工具来做， 生成一个临时表 把原表的数据插入到临时表中 然后互相rename 就好了。
所以名字对不上是因为ghost的原因。
1）看到后缀_gho,但是有个疑问 你们是否用到gh-ost，但是_gho或者_ghc后缀都是在源表后面加上的，你们这个是不按套路出牌，还是遵循规则比较好。
2）如果用了onlineddl工具需要配置的：
`online-ddl-scheme: "gh-ost" # 目前仅支持 gh-ost 、pt`
建议把dm配置这块内容通读一遍，少犯一些错误，同时也会加深对dm学习和了解。
磨刀不误砍柴工！
可以问一下你们 DBA 使用的是自己修改过的 MySQL online DDL 工具吗？表名有什么规律吗？
1、临时表： zzz原表名_gho
2、 dm_meta.任务名称_onlineddl 表中无数据， show stats_meta 这个表 Modify_count和 Row_count 也都是0
是直接执行的alter table add还是使用percona tools执行的变更？
percona tools背后实现的步骤比较复杂，跟直接执行alter table不同
原生ghost 上patch 了一个 临时表名： zzz原表名_gho