TiDBDM20GA,数据迁移不用愁

中科医院曝光资质 http://pf.39.net/bdfyy/zjft/161225/5154124.html

社会数字化、智能化的发展进程中,海量的数据带来巨大挑战,各行各业都在加速数字化转型,越来越多的企业意识到数据基础设施是成功的关键。然而,作为数据基础设施的核心,传统数据库例如MySQL面临性能和容量瓶颈,通过中间件实现的分库分表方案复杂度高,同时带来高昂的运维成本。

作为一款企业级NewSQL数据库,TiDB采用计算、存储分离的架构,可以根据业务需要进行弹性的扩展,应对更加实时和智能的数据应用需求。TiDB提供DataMigration(DM)生态工具,帮助用户实现从MySQL到TiDB数据迁移,有效降低迁移成本和风险。

DM是由PingCAP研发的一体化的数据迁移任务管理平台,支持从MySQL、Aurora或MariaDB到TiDB的全量数据迁移和增量数据复制。DM2.0版本现已正式发布,新增高可用、乐观协调模式下的分库分表合并迁移等企业级特性,同时带来一系列易用性的提升,确保用户的原数据库可以平滑地切换到TiDB,完全不用担心迁移带来的故障与数据丢失。

DM2.0新特性

数据迁移任务的高可用

DM2.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节点上并继续运行。

DM2.0高可用架构示意图

乐观协调模式下的分库分表合并迁移

DM1.0版本支持在线上执行分库分表的DDL语句(通称ShardingDDL),通过使用悲观模式,即当上游一个分表执行某一DDL后,这个分表的迁移会暂停,等待其他所有分表都执行了同样的DDL才在下游执行该DDL并继续数据迁移。悲观协调模式的优点是可以保证迁移到下游的数据不会出错,缺点是会暂停数据迁移而不利于对上游进行灰度变更、并显著地增加增量数据复制的延迟。

DM2.0版本提供新的乐观协调模式,在一个分表上执行的DDL,自动修改成兼容其他分表的语句后立即应用到下游,不会阻挡任何分表执行的DML的迁移。乐观协调模式适用于上游灰度更新、发布的场景,或者是对上游数据库表结构变更过程中同步延迟比较敏感的场景。

ShardingDDL悲观协调模式V.S.乐观

在乐观协调模式下,DM-worker接收到来自上游的DDL后,会把更新后的表结构转送给DM-master。DM-worker会追踪各分表当前的表结构,DM-master合并成可兼容来自每个分表DML的合成结构,然后通知相应的DM-worker把与此对应的DDL迁移到下游;对于DML会直接迁移到下游。

乐观协调模式下的ShardingDDL流程示

DM2.0版本试验性的支持从MySQL8.0迁移数据到TiDB,同时提供TLS支持,构建立体的数据安全体系,保障DM组件之间以及DM组件与上下游数据库之间的连接与传输的安全与合规,帮助企业实现数据在全生命周期过程中的不丢失、不泄露、不被篡改和隐私合规。

易用性全面提升

在新特性之外,DM2.0版本带来易用性的全面提升。用户可以通过TiUP进行DM2.0的部署和运维,同时支持使用TiUP把1.0版本的DM导入升级为2.0版本。在DM2.0中,DM-worker使用DM-master提供的API动态进行注册,在扩容和缩容DM-worker时,不再需要重启DM-master组件,有效地提升业务连续性。

对于AWSAurora、阿里云RDS等由云厂商提供的托管式MySQL,用户通常无法获取SUPER权限因而无法在全量数据导出时获取一致性快照。在DM2.0中,通过记录全量导出过程开始至结束区间的binlogposition范围并在增量阶段自动保证safe-mode的开启,在无需用户手动处理的情况下即保证了数据的最终一致性。对于Aurora中如“SELECTINTOS3”等特有权限,DM2.0在权限检查过程中也提供了更好的兼容支持。

在DM2.0中query-status命令除了能查询到可能的数据迁移异常外,对于部分常见异常,提供Workaround信息来指导用户如何进行处理。DM2.0引入handle-error命令来替换DM1.0中的sql-skip与sql-replace命令,简化了处理数据迁移过程中出错SQL语句的流程。

此外,DM2.0加入对全量导出数据及增量binlog数据中对应的sql_mode的自动处理,确保尽可能地减少手动的配置和干预。DM2.0也对一系列功能进行了易用性增强,包括全量导出文件的自动清理、配置参数优化、监控面板优化、log展示优化等。

用户实践

微众银行

微众银行于年12月获得由深圳银监局颁发的金融许可证,是由腾讯等知名企业发起设立、国内首家开业的民营银行,致力于为普罗大众、微小企业提供差异化、有特色、优质便捷的金融服务。

微众银行在多个业务场景中使用TiDB,其中批量任务、流水日志归档这两类场景高度依赖DM的分表合表功能。在批量任务场景中,使用DM把上游多个MySQL实例的同构分表汇总合表到下游TiDB中,再借助TiDB的水平扩展能力来提升批量效率。在流水日志归档场景,同样使用DM把上游多个MySQL实例的同构分表进行合表汇总到TiDB中,借助TiDB的水平扩展能力来提供理论无上限的存储容量能力。

原先的DM1.0版本在使用过程中遇到一些问题:DM的Worker组件发生异常挂掉后,会导致数据同步暂停,需要人工干预进行恢复,操作较为繁琐且会影响数据同步的时效性。其次,在金融场景下,一般使用灰度策略进行表结构变更,即对于上游多个MySQL实例的同构分表,一般会灰度变更其中一个实例,观察几天无异常后,才会继续对剩下的其他同构分表进行表结构变更,这种场景在DM1.0下会导致数据同步block住,同样会影响数据同步的时效性。

针对DM1.0在实际场景中部分功能的缺失,微众银行数据库团队通过业务POC测试,挖掘和细化了需求,协同PingCAP进行了深度的方案讨论,并进行了一系列功能的开发和优化工作。DM2.0的版本已经涵盖了组件高可用、支持灰度变更等企业级特性,能够满足金融级的数据同步需求。此外,DM2.0在易用性上也有大量的优化,比如使用TiUP更方便地来部署和维护多套DM集群、Worker上游source配置信息更加简化、错误信息更加清晰易读等。

理想汽车

理想汽车致力于研发比燃油车更好的智能电动车,首台理想ONE自年11月正式下线以来,理想汽车仅用10个月交付20,辆,创中国造车新势力最快交付记录。

微服务已经成为云原生时代企业数字化转型升级的基础,目前理想汽车累计99%以上,超过+的业务应用都构建在微服务之上,覆盖车联网、订单商城、车辆生产、售后、物流等业务流程。在微服务架构中,每个单独的微服务都对应独立的MySQL数据库(基于公有云RDS),理想汽车采用TiDBDataMigration(DM)工具实现把多个MySQL库的数据实时同步到一套TiDB集群,来解决两个业务场景的应用需求。

一方面,TiDB满足跨多个MySQL数据库进行实时数据联查的需求,利用TiFlash的HTAP能力,提供实时的业务分析报表。另一方面,利用TiDB对公有云的多个MySQL数据库做实时的数据备份,在提升业务可用性的同时降低了公有云RDS在读写分离场景下,实现负载均衡所需要额外使用的从库资源成本。

基于业务对DM工具的强依赖,理想汽车通过TiUP把原先DM1.0集群升级到DM2.0,并对DM2.0的高可用特性进行了深入测试,包括DM-master与DM-worker节点的高可用、数据迁移任务的自动调度与正确性保证,以及从1.0升级到2.0后的DM-master扩容等。总体来讲,DM2.0降低了从MySQL向TiDB进行数据实时同步的风险,保障了同步过程中的数据不丢失与服务高可用。

体验DM2.0

大家可以通过TiUP快速部署体验DM2.0,参照创建数据迁移任务开始将数据从MySQL迁移到TiDB。对于DM1.0集群,则可以使用TiUP导入并升级到DM2.0集群。

另外,如果对DM后续的开发计划感兴趣,可以查看GitHubrepo上的roadmap。同时,也非常欢迎大家来为DM贡献PR、issue以及使用反馈。




转载请注明:http://www.aierlanlan.com/cyrz/5104.html