为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
上游mysql修改表结构使用的PT-OSC修改的，上面的那个是pt-osc创建的表，我需要看哪个，下面的这个表结构就是正在同步mysql的表结构啊
1.确认下下游该表当前是否存在，如果存在，看下表结构
2.是通过什么方式跳过 ddl 的，sql-skip 还是 binlog filter ？
3.麻烦提供下该时间段内的 dm-worker 的日志
4.从 information_schema.tables 中查看下该表 user_vcoin_order_trade_log 的相关信息反馈下。辛苦
PT-OSC创建的表，mysql和tidb都没有此表，该表是PT工具自动创建，修改表结构成功后会自动删除，MySQL和tidb表数量和表名都是一样的。上面截图就是tidb的表结构。使用 sql_skip跳过的。
pt-osc 工具是创建一个新表，在新表上执行 ddl 操作，所有操作结束后，新表 rename 成旧表，替换原表。删除的是原表吧。看这个表的创建时间是上午 10:42 ，辛苦提供下日志吧。
表结构修改，由于DM不支持，然后DM中断了，MYSQL却还是在一直往前走。今天早上对DM进行SQL SKIP跳过操作只是alter table 那个语句，而PT工具修改流程并没有跳过，DM再次同步binlog，是应用了PT的工作流程。应该是这样
从日志上面，实际逻辑应该是不是通过 alter table 修改成功了， 而是 create table 操作已经包含了 pay_trade_no varchar(64) ，DDL 同步到下游 TiDB 。
另外 DM 也是支持 pt-osc 操作，可以通过在 sql-paterner 里面添加 online-ddl-scheme: pt 就可以同步 。
PT工具是创建和原来表一样的空表表结构，新表也是varchar(200)，在新表进行alter table 操作，在新表改字段的大小，但是对于tidb来说，还是不行的。那create table 操作已经包含了pay_trade_no varchar(64)那么这个是alter 操作修改来的，都是走binlog的，同步到下游 tidb还是不行啊，
alter table modify 不能有损调整 varchar 类型的列属性，这个是已知，并且在语法检测时候就会报错不支持。所以需要跳过。
意思是说，使用PT工具是可以修改字段长度的，但是需要跳过alter有损变更的语句。。。
这个不是自动跳过的，应该是没有同步成功。具体要看一下 dm-worker 日志确认一下。
我是手动跳过的，查看日志，从故障那一刻开始的第一条日志就是修改new表的表结构。在往前的日志信息没有
辛苦导一份 dm-worker 日志看下，文本格式，我们具体分析下，感谢
文件发给谁
E-mail：zhongshu.li@pingcap.com
有结果了么
另外方便提供下 DM 的版本吗 ？看下 mysqlbinlog 中是否存在这个 wbcomic_user._user_vcoin_order_trade_log_new 这个建表语句 ？我们排除下其他原因 。
版本1.1.0, 指的是tidb的binlog还是mysql的binlog，mysql的binlog肯定存在啊。
