共计 3605 个字符，预计需要花费 10 分钟才能阅读完成。
社会数字化、智能化的倒退过程中，海量的数据带来微小挑战，各行各业都在减速数字化转型，越来越多的企业意识到数据基础设施是胜利的要害。然而，作为数据基础设施的外围，传统数据库例如 MySQL 面临性能和容量瓶颈，通过中间件实现的分库分表计划复杂度高，同时带来昂扬的运维老本。
作为一款企业级 NewSQL 数据库，TiDB 采纳计算、存储拆散的架构，能够依据业务须要进行弹性的扩大，应答更加实时和智能的数据利用需要。TiDB 提供 Data Migration (DM) 生态工具，帮忙用户实现从 MySQL 到 TiDB 数据迁徙，无效升高迁徙老本和危险。
DM 是由 PingCAP 研发的一体化的数据迁徙工作治理平台，反对从 MySQL、Aurora 或 MariaDB 到 TiDB 的全量数据迁徙和增量数据复制。DM 2.0 版本现已正式公布，新增高可用、乐观协调模式下的分库分表合并迁徙等企业级个性，同时带来一系列易用性的晋升，确保用户的原数据库能够平滑地切换到 TiDB，齐全不必放心迁徙带来的故障与数据失落。
DM 2.0 新个性
数据迁徙工作的高可用
DM 2.0 提供数据迁徙工作的高可用，局部 DM-master、DM-worker 节点异样后仍能保证数据迁徙工作的失常运行。
当部署多个 DM-master 节点时，所有 DM-master 节点将应用外部嵌入的 etcd 组成集群。该 DM-master 集群用于存储集群节点信息、工作配置等元数据，同时通过 etcd 选举出 leader 节点，该 leader 节点用于提供集群治理、数据迁徙工作治理相干的各类服务。若可用的 DM-master 节点数超过部署节点的半数，即可失常提供服务。
当部署的 DM-worker 节点数超过上游 MySQL/MariaDB 节点数时，超出上游节点数的相干 DM-worker 节点默认将处于闲暇状态。若某个 DM-worker 节点下线或与 DM-master 产生网络隔离，DM-master 能主动将与原 DM-worker 节点相干的数据迁徙任务调度到其余闲暇的 DM-worker 节点上并持续运行。
乐观协调模式下的分库分表合并迁徙
DM 1.0 版本反对在线上执行分库分表的 DDL 语句（通称 Sharding DDL），通过应用乐观模式，即当上游一个分表执行某一 DDL 后，这个分表的迁徙会暂停，期待其余所有分表都执行了同样的 DDL 才在上游执行该 DDL 并持续数据迁徙。乐观协调模式的长处是能够保障迁徙到上游的数据不会出错，毛病是会暂停数据迁徙而不利于对上游进行灰度变更、并显著地减少增量数据复制的提早。
DM 2.0 版本提供新的乐观协调模式，在一个分表上执行的 DDL，主动批改成兼容其余分表的语句后立刻利用到上游，不会阻挡任何分表执行的 DML 的迁徙。乐观协调模式实用于上游灰度更新、公布的场景，或者是对上游数据库表构造变更过程中同步提早比拟敏感的场景。
在乐观协调模式下，DM-worker 接管到来自上游的 DDL 后，会把更新后的表构造转送给 DM-master。DM-worker 会追踪各分表以后的表构造，DM-master 合并成可兼容来自每个分表 DML 的合成构造，而后告诉相应的 DM-worker 把与此对应的 DDL 迁徙到上游；对于 DML 会间接迁徙到上游。
DM 2.0 版本试验性的反对从 MySQL 8.0 迁徙数据到 TiDB，同时提供 TLS 反对，构建平面的数据安全体系，保障 DM 组件之间以及 DM 组件与上下游数据库之间的连贯与传输的平安与合规，帮忙企业实现数据在全生命周期过程中的不失落、不泄露、不被篡改和隐衷合规。
易用性全面晋升
在新个性之外，DM 2.0 版本带来易用性的全面晋升。用户能够通过 TiUP 进行 DM 2.0 的部署和运维，同时反对应用 TiUP 把 1.0 版本的 DM 导入降级为 2.0 版本。在 DM 2.0 中，DM-worker 应用 DM-master 提供的 API 动静进行注册，在扩容和缩容 DM-worker 时，不再须要重启 DM-master 组件，无效地晋升业务连续性。
对于 AWS Aurora、阿里云 RDS 等由云厂商提供的托管式 MySQL，用户通常无奈获取 SUPER 权限因此无奈在全量数据导出时获取一致性快照。在 DM 2.0 中，通过记录全量导出过程开始至完结区间的 binlog position 范畴并在增量阶段主动保障 safe-mode 的开启，在无需用户手动解决的状况下即保障了数据的最终一致性。对于 Aurora 中如“SELECT INTO S3”等特有权限，DM 2.0 在权限查看过程中也提供了更好的兼容反对。
在 DM 2.0 中 query-status 命令除了能查问到可能的数据迁徙异样外，对于局部常见异样，提供 “Workaround” 信息来领导用户如何进行解决。DM 2.0 引入 handle-error 命令来替换 DM 1.0 中的 sql-skip 与 sql-replace 命令，简化了解决数据迁徙过程中出错 SQL 语句的流程。
此外，DM 2.0 退出对全量导出数据及增量 binlog 数据中对应的 sql_mode 的主动解决，确保尽可能地缩小手动的配置和干涉。DM 2.0 也对一系列性能进行了易用性加强，包含全量导出文件的主动清理、配置参数优化、监控面板优化、log 展现优化等。
用户实际
微众银行
微众银行于 2014 年 12 月取得由深圳银监局颁发的金融许可证，是由腾讯等知名企业发动设立、国内首家停业的民营银行，致力于为普罗公众、渺小企业提供差异化、有特色、优质便捷的金融服务。
微众银行在多个业务场景中应用 TiDB，其中批量工作、流水日志归档这两类场景高度依赖 DM 的分表合表性能。在批量工作场景中，应用 DM 把上游多个 MySQL 实例的同构分表汇总合表到上游 TiDB 中，再借助 TiDB 的程度扩大能力来晋升批量效率。在流水日志归档场景，同样应用 DM 把上游多个 MySQL 实例的同构分表进行合表汇总到 TiDB 中，借助 TiDB 的程度扩大能力来提供实践无下限的存储容量能力。
原先的 DM 1.0 版本在应用过程中遇到一些问题：DM 的 Worker 组件产生异样挂掉后，会导致数据同步暂停，须要人工干预进行复原，操作较为繁琐且会影响数据同步的时效性。其次，在金融场景下，个别应用灰度策略进行表构造变更，即对于上游多个 MySQL 实例的同构分表，个别会灰度变更其中一个实例，察看几天无异样后，才会持续对剩下的其余同构分表进行表构造变更，这种场景在 DM 1.0 下会导致数据同步 block 住，同样会影响数据同步的时效性。
针对 DM 1.0 在理论场景中局部性能的缺失，微众银行数据库团队通过业务 POC 测试，开掘和细化了需要，协同 PingCAP 进行了深度的计划探讨，并进行了一系列性能的开发和优化工作。DM 2.0 的版本曾经涵盖了组件高可用、反对灰度变更等企业级个性，可能满足金融级的数据同步需要。此外，DM 2.0 在易用性上也有大量的优化，比方应用 TiUP 更不便地来部署和保护多套 DM 集群、Worker 上游 source 配置信息更加简化、错误信息更加清晰易读等。
现实汽车
现实汽车致力于研发比燃油车更好的智能电动车，首台现实 ONE 自 2019 年 11 月正式下线以来，现实汽车仅用 10 个月交付 20,000 辆，创中国造车新权势最快交付记录。
微服务曾经成为云原生时代企业数字化转型降级的根底，目前现实汽车累计 99% 以上，超过 400+ 的业务利用都构建在微服务之上，笼罩车联网、订单商城、车辆生产、售后、物流等业务流程。在微服务架构中，每个独自的微服务都对应独立的 MySQL 数据库（基于私有云 RDS），现实汽车采纳 TiDB Data Migration (DM) 工具实现把多个 MySQL 库的数据实时同步到一套 TiDB 集群，来解决两个业务场景的利用需要。
一方面，TiDB 满足跨多个 MySQL 数据库进行实时数据联查的需要，利用 TiFlash 的 HTAP 能力，提供实时的业务剖析报表。另一方面，利用 TiDB 对私有云的多个 MySQL 数据库做实时的数据备份，在晋升业务可用性的同时升高了私有云 RDS 在读写拆散场景下，实现负载平衡所须要额定应用的从库资源老本。
基于业务对 DM 工具的强依赖，现实汽车通过 TiUP 把原先 DM 1.0 集群降级到 DM 2.0，并对 DM 2.0 的高可用个性进行了深刻测试，包含 DM-master 与 DM-worker 节点的高可用、数据迁徙工作的主动调度与正确性保障，以及从 1.0 降级到 2.0 后的 DM-master 扩容等。总体来讲，DM 2.0 升高了从 MySQL 向 TiDB 进行数据实时同步的危险，保障了同步过程中的数据不失落与服务高可用。
体验 DM 2.0
大家能够通过 TiUP 疾速部署体验 DM 2.0，参照创立数据迁徙工作开始将数据从 MySQL 迁徙到 TiDB。对于 DM 1.0 集群，则能够应用 TiUP 导入并降级到 DM 2.0 集群。
另外，如果对 DM 后续的开发计划感兴趣，能够查看 GitHub repo 上的 roadmap。同时，也十分欢送大家来为 DM 奉献 PR、issue 以及应用反馈。
