dm-V1.0.5使用汇总

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

使用过程需要注意的有:
1、源端表存在大小写问题,到TIDB默认变小写,需要在TASK增加参数
设置大小写敏感:case-sensitive:true
2、源端MySQL大事务,代码归档不能超过4G,若超了…
停止task,手动把BINLOG移动到relay_log目录里
3、提高DM对下游写入能力,优化sync参数,可根据配置酌情调整
#备份、导入、同步
image

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控制,部分功能还在改进

1赞

还差一部分的内容,你再贴出来~我转到技术文章里面去?

那我来帮你吧~

为什么我贴就有问题:sweat_smile:

你前面的空格要去了~

1赞

目前 DM 已经更新到 5.3 版本,你这个 1.0.5 的版本是2020年4月27日上线的,

尽可能做一下更新~hhhh~太旧了这个版本。

感谢建议,主要是这个版本确实很稳定,线上多套TIDB集群 严重依赖这个组件服务做CDC工作的,稳定是前提,不然KPI就没了,目前在测试环境用的新版本

最主要的是:官方说法是,现在不维护 DM1.0 了。。。用着会不会没有安全感。。。。:joy:

从目前使用情况,我相信这个版本的:grinning:挺稳的