什么是DM

TiDB Data Migration (DM) 是PingCAP开源的一体化的数据同步任务管理平台，支持从 MySQL 或 MariaDB 到 TiDB或者Mysql 的全量数据迁移和增量数据同步。使用 DM 工具有利于简化错误处理流程，降低运维成本；类似的还有阿里开源的otter

为什么要升级

2.0使用tiup管理，tidb4.0也是使用tiup管理，后续的新版本都统一使用tiup管理了，统一管理工具方便后续平台化的建设
我比较关注的是高可用功能，1.0版本的dm-master、dm-worker节点都是单点，dm-master挂了还好，只是不能对集群做变更，对线上业务没有直接影响，如果dm-worker节点挂了，那么上面的同步任务都中断了，所以比较期待高可用功能，2.0还有其他新功能和改进点见下面链接

1.0环境说明

部署拓扑

# DM 模块
[dm_master_servers]
dm_master ansible_host=x.x.184.43
[dm_worker_servers]
dm_worker1_1 ansible_host=x.x.184.44 server_id=101 source_id="devdb-dev" dm_worker_port=8262 mysql_host=testdba-mysql.com mysql_user=dbarepl mysql_password='x3/kIzr7f3GO' mysql_port=3306
dm_worker1_2 ansible_host=x.x.184.45 server_id=102 source_id="chj-dev" deploy_dir=/chj/app/dm1 dm_worker_port=8263 mysql_host=devdb-mysql.chj.cloud  mysql_user=dbarepl mysql_password='x3/kIzr7f3GO8pB' mysql_port=30111
[dm_portal_servers]
dm_portal ansible_host=x.x.184.43
# 监控模块
[prometheus_servers]
prometheus ansible_host=x.x.184.43
[grafana_servers]
grafana ansible_host=x.x.184.43
[alertmanager_servers]
alertmanager ansible_host=x.x.184.43

# 全局变量
[all:vars]
cluster_name = dm1-test
ansible_user = tidb
dm_version = v1.0.5
deploy_dir = /chj/app/dm1
grafana_admin_user = "admin"
grafana_admin_password = "admin"

task任务

自动升级

停止1.0的集群

cd /home/tidb/tidb-test/dm-ansible-v1.0.4
ansible-playbook stop.yml

导入DM-Ansible 部署的 DM 1.0 集群并升级

mdkir /home/tidb/tidb-test/dm2-test
cd /home/tidb/tidb-test/dm2-test
tiup dm import --dir=/home/tidb/tidb-test/dm-ansible-v1.0.4/ --cluster-version v2.0.0-rc.2

使用tiup启动2.0

tiup dm start dm1-test

查看集群

tiup dm display  dm1-test

查看同步任务

tiup dmctl --master-addr 172.xx.184.43:8261 query-status
Starting component `dmctl`: /home/tidb/.tiup/components/dmctl/v2.0.0-rc.2/dmctl/dmctl --master-addr 172.xx.184.43:8261 query-status
{
    "result": true,
    "msg": "",
    "tasks": [
        {
            "taskName": "op_cmdb__dev",
            "taskStatus": "Running",
            "sources": [
                "chj-dev"
            ]
        },
        {
            "taskName": "mysqlcloud_test",
            "taskStatus": "Running",
            "sources": [
                "devdb-dev"
            ]
        }
    ]
}

至此，如果集群状态、任务状态都正常的话说明集群就升级完成了

扩容DM-Master

1.0的DM-Master是一台单点，所以升级到2.0后我们需要扩容两台DM-Master。

新建scale.yaml文件，添加新增的 woker节点信息

---
master_servers:
  - host: 172.x.184.44
    deploy_dir: "/chj/app/dm1/dm-master/deploy"
    data_dir: "/chj/app/dm1/dm-master/data"
    log_dir: "/chj/app/dm1/dm-maseter/log"
  - host: 172.x.184.45
    deploy_dir: "/chj/app/dm1/dm-master/deploy"
    data_dir: "/chj/app/dm1/dm-master/data"
    log_dir: "/chj/app/dm1/dm-maseter/log"

更详细的配置参考官网DM集群的yaml文件

执行扩容操作。TiUP DM 根据 scale.yaml 文件中声明的端口、目录等信息在集群中添加相应的节点

tiup dm scale-out  dm1-test  /home/tidb/tidb-test/dm-2.0-rc/scale.yaml

查看集群状态，确认扩容是否成功

验证集群的高可用

验证DM-Master的高可用

停止现在的DM-Master，查看Leader会不会选举到其他节点，Status这列，带’L’标识的就是Leader，通过下图可以看到成功切换了
通过查看任务或者操作任务验证DM-Master是否正常

验证DM-Worker的高可用

确认task目前所在的Worker节点和状态
我们把xx.xx.184.45:8263这个Worker节点停止，看看这个task任务会不会自动漂移的其他Worker节点上

3.通过sysbench给上游Mysql写入50w数据，在写入的过程中停止改task的所在的worker节点，待数据写完确认下游数据有没有丢失

sysbench --config-file=config oltp_insert --tables=1 --table-size=10000000 prepare

问题总结

自动升级应该会自动创建数据源并且自动拉起task任务，但是2.0.0-rc这个版本有问题，没有自动创建数据源，所有task都没有启动，已经反馈给官方，几天之后就修复了，目前在2.0.0-rc.2这个版本已经修复
测试DM-Worker的高可用功能，kill -9 杀点进程在启动，日志会疯狂的刷，每分钟能打1G多错误日志，这个问题也已经在2.0.0-rc.2这个版本已经修复
两台worke节点，其中一台故障，上面的task没有自动漂移到另一台节点上，咨询官方人员得知，task自动故障切换的前提是集群中必须有空闲的worker节点，即没绑定上游数据源的worker，调度是以一个上游数据源对应一个worker进行的，和task没关系，task是建立在数据源之上的
如果在测试过程中失败了想重新来一次

#删除导入的集群信息
rm -rf /home/tidb/.tiup/storage/dm/clusters/cluster-name/
#tiup导入后会把启动脚也更新了，所以我们需要用1.0的脚本在还原下
ansible-playbook  deploy.yml

更多技术问题交流大家可以关注我微信公众号：
%E5%BE%AE%E4%BF%A1%E5%85%AC%E4%BC%97%E5%8F%B7navyaijm

DM v1 升级v2初体验