DM v1 升级 v2 初体验

2022 年 7 月 11 日
本文字数：2141 字
阅读完需：约 7 分钟

作者： Hacker_DaUeI5uX 原文来源：https://tidb.net/blog/e15a4db5

什么是 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=3306dm_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-testansible_user = tidbdm_version = v1.0.5deploy_dir = /chj/app/dm1grafana_admin_user = "admin"grafana_admin_password = "admin"

复制代码

task 任务

自动升级

停止 1.0 的集群

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

复制代码

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

mdkir /home/tidb/tidb-test/dm2-testcd /home/tidb/tidb-test/dm2-testtiup 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-statusStarting 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 节点信息

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

执行扩容操作。TiUP DM 根据 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 是建立在数据源之上的
如果在测试过程中失败了想重新来一次

更多技术问题交流大家可以关注我微信公众号：

发布于: 刚刚阅读数: 4

原文链接:【http://xie.infoq.cn/article/80d383f35f5d92642a95bd682】。文章转载请联系作者。

TiDB 社区干货传送门

关注

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

发布

暂无评论

创作场景

DM v1 升级 v2 初体验

什么是 DM

为什么要升级

1.0 环境说明

部署拓扑

task 任务

自动升级

停止 1.0 的集群

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

使用 tiup 启动 2.0

查看集群

查看同步任务

扩容 DM-Master

验证集群的高可用

验证 DM-Master 的高可用

验证 DM-Worker 的高可用

问题总结

TiDB 社区干货传送门

评论