为提高效率，提问时请尽量提供详细背景信息，问题描述清晰可优先响应。以下信息点请尽量提供：
另外，之前的task.yaml的记录，如何清除，有时候干扰信息
1、你上面提到的流量是什么流量，是网络流量的监控吗？
2、DM 集群启动后，不管 task 是否启动，relay log 组件就会开始拉取上游 MySQL 的 binlog 日志。可以看下 relay log 的大小是否是增长的状态。
3、清理 task 信息，可以在 dmctl 里面使用 stop-task 停止这个 task：
是网络监控，配置inventory.ini配置文件的时候，没有指定relay log，再开启DM的时候，把之前的binlog都拉取过来了，导致网络流量监控报警，之前的任务已经使用stop-task关闭了。再次使用query-status查看，还是会有之前task的历史信息
DM 的版本是什么？最后的截图是 stop-task 后 query-task 看到的信息吗？这个信息是正常的，因为 worker 还在是启动的状态，但是已经没有 task 信息了哈~~~
DM是最新版本，一共是4个实例，配置了4个task.yaml，我以为是，DM重启后，之前的task.yaml的历史信息会清空，只有再指定task.yaml任务的时候，才会显示task.yaml信息的，如果task.yaml没有启动的话，这个dm-worker就只是去上游拉去binlog，到本地对吧
对的，dm 集群启动后，即使不启动 task 仍会拉取上游的 binlog
好的多谢
DM worker 可以配置 relay log 的机制，启动 worker 就会从上游 MySQL 处拉取 binlog 存在本地，task 启动后就从 worker 本地的 relay log 中取数据。
好的多谢~~
请提交更多一些的日志
Table struct compatibility check 是檢查上游 MySQL 的 Table Schema 是否在下游 TiDB 也支持的。這裡 DM 解析這個 Schema 失敗了，原因是遇到亂碼。把這張圖裡列出的亂碼 comment 改正或去掉就可以了。留意 Database 和系統的 character set 最好統一用 utf8mb4。
# 上游 MySQL 執行
alter table `vmanhua`.`user_info` comment = '...正確的註釋...';
alter table `vmanhua`.`user_info` modify column `province` tinyint(3) comment '...正確的註釋...';
...
字符集都是统一的utf8字符集，之前这个实例的数据使用的是mydumper，syncer导入到tidb中，没有报错的。
这个是之前使用mydumper,syncer导入到tidb中，也有乱码，是可以正常导入的
嗯，那是因為 Syncer 沒有做這個檢查。如果不需要這個檢查，可以在 task.yaml 設定忽略它
---
name: test
...
ignore-checking-items: ["table_schema"]
好的明白了，已经解决了，把乱码的表注释去掉了。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。