DM2.0初体验
转载
作者：navyaijm2017
什么是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 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
更多技术问题交流大家可以关注我微信公众号：
