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参数，可根据配置酌情调整
#备份、导入、同步

      

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、做好各种异常冲突告警（数据冲突等）

 

15、DM切换源端同步点，主要修改is_global=1,delete掉is_global=0

        在分库分表合并中，遇到不清理会遇到同步状态没问题，数据实际没同步问题

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

    

17、使用过程中DM 为什么能够保证数据一致性，比有些CDC牛逼，这方面的原理还是要学习

     要是能够根据数据值进行CDC 这个就更加完美，目前只能根据事件

18、为什么不用新版本

       看选择，目前这个还是比较稳定，有些业务已经使用了2年多了，挺稳的