新闻中心

如何迁移?

在金融业务场景中,数据库迁移升级、数据分发与数据备份是数据库系统必不可少的基本功能。其中前者是实现数据解耦及汇总的重要基础,例如保险行业常见的总分系统架构,多个子库需要实时的将业务数据同步至总库汇总查询;银行核心交易系统中,需要将交易数据实时同步至分析子系统进行报表,跑批等业务员操作。而数据备份则是数据安全的基石,更是金融业务数据的生命线。作为一个金融级数据库产品来说,TDSQL 在技术层面沉淀了针对数据库数据迁移、分发、同步和备份的 TDSQL-MULTISRCSYNC(TDSQL-多源同步)解决方案,为数据库系统国产化转型的高可用、高可靠提供了有益参考。

▐  TDSQL 多源同步核心架构:数据迁移与同步的关键逻辑

分布式数据库 TDSQL 是腾讯打造的一款分布式数据库产品,具备强一致、高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性,同时提供智能 DBA、自动化运营、监控告警等配套设施。

TDSQL-MULTISRCSYNC(多源同步),是高性能、高一致,支持多种异构数据平台的数据分发服务。该服务支持以 TDSQL 作为源端的数据实时同步分发至 MySQL、Oracle、PostgreSQL、消息队列等平台,同时也支持以 TDSQL 作为目标端,将 MySQL 或者 Oracle 的数据实时同步至 TDSQL 中,并且部署灵活,支持一对多,多对一等多种复制拓扑结构。

多源同步模块典型的基于日志的 DCD 复制技术,其系统架构如下:

从上图我们可以看到,整个系统可以大致地分成三个部分:producer,store,consumer。

  • producer:增量日志获取模块,主要负责解析获取源端的增量数据改动日志,并将获取到的日志解析封装为 JSON 协议的消息体,投送至消息队列。当源端是 MySQL 或者 TDSQL 时,获取的增量日志为 binlog 事件,这里要求 binlog 必须是 row 格式且为 full-image。当源端是 Oracle,producer 从 Oracle 的物化视图日志中获取增量数据并进行封装和投送。这里 producer 在向消息队列生产消息时,采用 at-least-once 模式,即保证特定消息队列中至少有一份,不排除在队列中有消息重复的情况。

  • store:消息队列中,因为数据库系统日志有顺序性要求,因此这里所有的 topic 的 partition 个数均为 1,保证能够按序消费。

  • consumer:日志消费和重放模块,负责从消息队列中将 CDC 消息消费出来并根据配置重放到目标实例上。这里因为 producer 端采用 at-least-once 模式生产,因此消费者这里实现了幂等逻辑保证数据重放的正确。

▐  核心特性:高性能、高一致、高可用

一、高性能保障:基于行的哈希并发策略

金融业务场景中,往往对数据的实时性要较高,因此对数据同步的性能提出了比较高的要求。为了解决这样的问题,consumer 采用了基于行的哈希并发策略实现并行重放。下面以 binlog 消息为例来说明该策略的实现。

数据库系统在记录 binlog 时,按照事务的提交顺序将行的改动写入 binlog 文件,因此按照 binlog 文件记录事件的顺序进行串行重放,源端和目标端数据库实例状态一定会达到一致。但是串行重放因为速度慢,在遇到如批量更新等大事务时,容易产生较大的同步时延,适应不了对数据实时性较高的同步场景。为了提高并发度,这里 consumer 按照每个行记录的表名和主键值进行 hash,根据 hash 值将消息投送到对应的同步线程中。这样乱序的重放会导致数据不一致吗?答案是不会的,因为虽然是将顺序的消息序列打乱了,但是同一行的所有操作都是在同一个线程中是有序的,因此只要每个行的改动执行序列正确,最终数据是会一致。这个过程如下图所示:

二、一致性保障:row 格式 binlog 事件的幂等容错

实现幂等逻辑的动机有两个:

  • 因为生产者实现的是 at-lease-once 模式进行消息生产,因此 consumer 这里必须要能否处理消息重复的问题。

  • 支持幂等逻辑后,便于数据的修复,且在数据同步的过程中不需要记录镜像点,便于运维。

这里幂等逻辑的设计原则就是,保证按照 binlog 事件的意图去对目标实例进行修改。如 insert 事件,其意图就是要在数据库中有一条 new 值标识的记录;update 事件的意图就是,数据库中没有 old 值标识的记录,只有 new 值标识的记录;delete 操作也是同样,其结果就是要求目标数据库中,不包含 old 值标识的记录。因此针对 insert,update,delete 操作,其幂等逻辑如下:

  • INSERT

根据上图可以看到,当出现主键冲突时,insert 操作会转变成 delete+insert 操作来保证 insert 动作执行成功。另外图中的影响行数小于 0 或者等于 0 标识执行 SQL 出错和主键冲突。

  • update

从上图我们可以看到,update 操作的幂等处理,其实就是保证了在数据库中,只能有 new 值产生的记录。

  • delete

这个过程中,delete 结束后大于 0 就成功;小于 0 就是失败;等于 0 的时候我们认为它可能没有匹配到行,这个时候我就按照主键操作——因为删除的操作最终的结果就是目标一定没有了当前删除的消息主键所标识的这一行——这条操作完成后,DB 里一定没有这行数据,因此仅仅是按照主键进行删除就可以了。这个时候如果影响行数大于 0,则删除成功。如果等于 0,就认为按照主键去匹配,本身删除不到,匹配不到——意思是本身目标就没有这条要删的主键所标识的数据——所以实际上它的结果跟要做完删除的结果,影响是一样,也就结束这一条删除的幂等。

三、高可用保障:多机容灾保护

这一套同步服务,一定是高可用的,体现在两个方面:1、灾难的情况下,本身消费者的服务能够在假如机器出现一些不可恢复的故障时能够及时地感知并且自动迁移和切换;2、要应对本身常规的扩容——垂直扩容或者水平扩容的伸缩性需求,这也是我们比较强调,这一套同步服务要能够兼容各种灾难情况和常规的运维场景下各种各样的要求来做到服务的高可用。

重点针对数据库迁移同步的场景而言,TDSQL 多源同步提供多机容灾保护机制:

消费者高可用保障层面,一方面消费者服务本身无状态,所有的任务下发通过 MetaCluster 实现,可以通过多台机器去部署同步服务,这套容灾机制通过 manager 进程来实现,也就是说当整个机器掉电,运营这个机器的 consumer 已经不存活,这个时候这些 consumer 在 MetaCluster 上的存活节点的失效就会被其他机器的 manager 节点感知——认为另外一些机器的 consumer 已经不存活,这个时候就会把任务接管过来,并且在自己机器上重新拉起这些服务。

二是我们要做到同一个数据同步的链路不能在两台机器上同时拉起,这是一个互斥的要求。高可用机制会通过一些像唯一标识或者当前的分派节点做到,同一个数据同步的任务在被拉起的时候一定是发生在不同的机器上来实现漂移与互斥的操作,这个多机容灾保护总体上就是通过 MetaCluster 和监控的进程,比如说 manager 这样的服务进行协调完成,保证在机器级别灾难或者其他灾难情况下这些任务能够在十秒以内成功迁移到其他的存活节点上。

详情请登录 学校网址:http://www.xkzjsj.com

联系人 倪老师 13384498909微信同步

所有课程尽在新科展计算机学校http://www.xkzjsj.com

长春市朝阳区同志街与隆礼胡同交汇火炬大厦9 新科展计算机学校(桂林路附近)


吉林省新科展高级IT网络培训中心是吉林省最大的计算机培训学校
吉林省新科展高级IT网络培训中心学校常年招生,咨询学习请提前电话联系,登记预约学习时间
新科展承诺:100%推荐就业,规定时间内免费重学。

合作伙伴

计算机培训 培训学校