dm-V1.0.5 使用汇总

作者： dbaspace 原文来源：https://tidb.net/blog/edb72332

DM 使用 V1.0.5 版本, 线上共创建了 100+ 的 WORKER 任务，给业务做各种数据同步任务，目前官方支持的几种同步方式都在线上运行，且使用超过 6 个月时间，挺稳定的，高峰期存在一定延期及其他。

使用过程需要注意的有：

1、源端表存在大小写问题，到 TIDB 默认变小写，需要在 TASK 增加参数

设置大小写敏感:case-sensitive:true

2、源端 MySQL 大事务，代码归档不能超过 4G，若超了…

停止 task, 手动把 BINLOG 移动到 relay_log 目录里

3、提高 DM 对下游写入能力，优化 sync 参数，可根据配置酌情调整

# 备份、导入、同步

4、增加连接心跳检查参数，账号需要有 DDL 权限

enable-heartbeat: false

5、业务库通过最好是要有一定的规则，在分库分表合并比较好处理，如库名 db_xxx_0xo…db_xxx_0ox 表名类似

目前遇到匹配规则有些情况下不是很满足，通过业务改造规范处理

6、目标端记录的 dm_meta 信息非常重要，不要轻易处理

如果想把任务重新搞，不改 taskname 名字，可以删除同步表数据、或 DROP

7、DM 写入慢，目前遇到处理办法

1、查看 TIKV 是否 IOUNTIL 比较高，可能磁盘 IO 性能不行，换盘

2、分库分表多实例下，多个 DM 使用一个 TIDB, 也会引起慢，资源充足下可以为每个 TASK 配置一个 TIDB-SERVER

3、调整 syncers 的参数

4、根据实际情况优化同步业务表 (分表合并方案，官方对于写入热点建议有参数设置)

8、任务名称规则，不能带有点号格式

9、增量同步数据需要注意：

1、update db_meta.xx is_global=1 修改名字

2、修改 task 里的位置点

3、relay_log 里的信息

10、使用 GTID 同步 BINLOG 可能会遇到，这样问题

改成 pos 同步即可恢复

11、分库分表合并，DM 默认使用悲观锁，会引起同步延迟，在 4096 个表批量刷 DDL 延迟在一个小时左右

官方有可改成乐观模式，没验证过，不知道会不会对数据准确性产生问题

12、DM 同步也支持有损修改，算是 TIDB 特性

13、记得加监控，有延迟及时告警，能够及时处理

目前处理：同步 BINLOG 个数减去已经消费的个数 >1 做提示

14、做好各种异常冲突告警（数据冲突等）

数据冲突可根据 query-error 获取进行跳过

15、最后展示目前 DM 完成的管理，可以配置管理、WOKRER 控制、TASK 控制，部分功能还在改进