Tidb DM高可用问题

[广泽苍山 (广泽)]

Tidb的大佬好，
最近在做Tidb数据库的相关调研，打算将我们公司的一部分业务迁移到Tidb中去来对业务进行支持。现在遇到一些问题，需要求助各位Tidb的大佬帮助提供一些思路。

[部署环境]
1. 公司目前的部署环境是在阿里云上，使用k8s进行管理
2. 业务数据目前采用RDS作为主要的数据库存储

[目标]
1. 搭建成型Tidb集群
2. 迁移部分的业务存储到Tidb集群

[现状]
1. 和RDS不同，Tidb需要我们自己进行运维，所以需要有一个试验期
2. 试验期的过程中，数据需要从RDS向Tidb进行部分数据库的全量迁移和增量迁移(增量迁移是一个半长期的过程）
3. 在试验期内，业务会把Tidb当错一个普通的从库进行查询调用

[主要问题]
同步工具按照官方推荐试用了DM，经过测试可以实现上游RDS和下游Tidb之间的同步。但是经过浏览DM的文档，有如下担忧需要麻烦各位大佬解答一下:
1. DM的master是否高可用，是否有类似主从设计的高可用保证？
2. DM的worker执行的任务是否高可用的保证？比如worker所在的机器发生crash的情况下，任务是否可以同步给另外一个worker节点继续执行？
3. 阿里云的RDS到Tidb采用DM这种同步工具，是否可以作为一个同步的常态存在，也就是说把Tidb当作一个slave的RDS,这种可靠性是否能够保证？延迟的情况如何？

[小王同学]

您好，DM 2.0 版本是支持高可用的，新的架构图如下，近期将会发布 2.0 rc 版本。可以关注 GitHub 地址 https://github.com/pingcap/dm

2.0 HA 版本 DM 的主要特性包括：

• 可部署多个 DM-master 管理集群，包括元信息的管理、任务调度、客户端请求处理。少部分 DM-master 出现故障对集群不会造成影响。
• 可部署多个 DM-worker 进行数据的迁移，当 DM-worker 出现故障时，DM-master 会将任务调度到空闲的 DM-worker。
• dmctl 通过链接任何一个 DM-master 即可查询集群状态、对数据迁移任务进行管理。

以上 2.0 的 DM 架构可以回答您这边的问题 1 和问题 2。针对问题 3 ，目前也有一些用户把 TiDB 当作上游的一个 slave，正常情况下，延迟在秒级。但是还是要看下游 TiDB 的负载情况，负载比较高的话，延迟有可能会偏高。DM 作为 MySQL 到 TiDB 的全量数据迁移和增量数据同步的工具，长期运行是没有问题的。但是我们更建议在业务测试通过之后，可以直接把 TP 的业务迁移到 TiDB 上，以充分利用其 平扩容或者缩容、金融级高可用、实时 HTAP 等特性。

[广泽苍山 (广泽)]

的全量数据迁移和增量数据同步的工具

感谢回复！看起来DM的2.0确实可以解决我们的问题。
还想追问一下，2.0 rc的版本最近是否有明确上线deadline？我们现在是否可以采用2.0 beta的版本来进行尝试，其可靠程度高吗？

[小王同学]

2.0 rc的版本最近是否有明确上线deadline

您好，2.0 rc 在下周五会发布，如果本周要进行测试的话，建议使用 nightly 版本。

[广泽苍山 (广泽)]

deadline

好的，感谢！

[小王同学]

[sylzd]

补充问一个问题： @小王同学
DM依赖上游MySQL宕机的情况，如何保证任务的可用性？