? 优质资源分享 ?
学习路线指引(点击解锁) | 知识定位 | 人群定位 |
---|---|---|
? Python实战微信订餐小程序 ? | 进阶级 | 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。 |
?Python量化交易实战? | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
随着企业规模的扩大,对数据库可用性要求越来越高,更多企业采用两地三中心、异地多活的架构,以提高数据库的异常事件应对能力。
在数据库领域,我们常听的“两地三中心”、“异地多活”到底是什么呢?
“两地三中心”就是生产数据中心、同城灾备中心、异地灾备中心。这种模式下,两个地域的三个数据中心互联互通,当一个数据中心发生异常,其他数据中心可以正常运行并进行业务接管。
“异地多活”就是在多个地域建设多个数据中心, 业务数据能够在三个及以上的数据中心之间进行双向同步。异地多活架构具有更高的可用性,抗风险能力极强。
不同数据中心可以接管并恢复业务的前提是多个数据中心无差别,彼此之间可以实时同步数据。通过腾讯云 DTS 数据同步功能可以实现这一诉求。本文将向您介绍通过腾讯云 DTS 数据同步功能实现两地三中心架构的方案以及关键原理。
架构介绍
利用腾讯云DTS数据同步可构建下图中的两地三中心架构,其中1~4分别为一条单向的数据同步链路;A为生产数据中心,B为同城的灾备中心,C为异地的灾备中心。
图:两地三中心架构示例
关键问题
在上图所示的两地三中心架构中,数据同步需要解决以下四个关键问题:
- 单向链路中存量数据和增量数据的同步
- 通过单向链路构建的复杂拓扑中回环问题的处理
- 如何保证三个节点数据一致
- 同步延迟问题
解决方案
1. 单向链路中存量数据和增量数据的同步
单向同步链路是两地三中心、多活数据架构的基础。为了使单向链路的目标节点数据和源头节点一致,既要复制存量数据,又要持续同步增量数据。对于线上系统,源端往往不停地有业务数据写入,为了得到一份一致性的存量数据,往往需要对源端进行加锁,比如FTWRL或者备份锁,这也是mydumper,xtrabackup等备份工具采用的方案。加锁的弊端在于会影响源库的业务写入,这在一些场景下是无法接受的。针对这个问题腾讯云 DTS 提出了一种无锁方案,即存量数据导出时不对源库加锁,在回放增量数据时修复存量数据的不一致,最终达到源和目标数据的一致性。
DTS在发起数据同步任务的同时,会接管源端的Binlog,然后将Binlog在目标端进行回放,在同步任务期间源端的SQL操作,会重复在目标端执行一遍。
这跟MySQL Replication主从复制的原理是类似的,通常MySQL为一主多从的架构形式,主库Master负责数据写入,从库Slave负责数据读取,从库的IO线程将主库上的变化写入到本地Relay log,SQL线程读取Relay log在从库上进行回放,从而实现主从数据同步。
图:MySQL Replication主从复制原理图
MySQL这种读写分离的模式可以大大减少主库的访问压力,但灵活性较差,筛选功能不足。
DTS在主从复制架构的基础上,引入灵活的拓扑结构,支持一对多、多对一、联级单向、双向同步、联级环形同步等,可满足各种复杂的数据库同步场景的应用,如两地三中心、异地多活等。
2. 解决数据回环问题
数据同步中会遇到回环问题,以如下环形同步为例,对A进行SQL操作,A同步到B,B再同步到C,C又同步给A,A会重复处理该SQL操作,进而陷入无限循环中,所以如何进行数据破环,是双向同步、环形同步等必须要解决的问题。
图:数据回环问题
DTS通过在环形拓扑中做标记,从而识别出来接收到的SQL是否已执行过,达到破环的目的。在其他的拓扑结构,如双向同步、联级环形同步都可以通过做标记来实现破环。
3. 保证三节点数据一致
在两地三中心数据架构中,会有两个或三个节点需要同时进行数据写入,保证多个节点的一致性至关重要。
3.1 规划主键分区
在两地三中心的场景中实现数据一致性,常见的方法就是规划主键分区。主键分区即多个写入的数据库“各司其职“,各自负责更新不同的主键数据,从源头上避免产生主键冲突。例如A节点上负责更新ID为1、3、5的主键数据,B节点上负责更新ID为2、4、6的主键数据。
如果实际业务部分数据存在耦合,无法进行主键分区,则可能产生主键冲突。DTS支持对冲突进行处理,并提供如下三种冲突策略:
冲突报错
同步任务中,源库插入(INSERT)主键数据与目标库存在冲突时,任务报错并暂停,需要用户手动处理后才能继续。
冲突处理时SQL语句改写如下:
INSERT不改写
UPDATE 不改写
DELETE 不改写
冲突忽略
同步任务中检测到源库的主键插入(INSERT)数据与目标库发生冲突时,忽略源库的主键插入数据,以目标库的内容为准。
冲突处理时SQL语句改写如下
INSERT -> INSERT IGNORE
UPDATE 不改写
DELETE 不改写
冲突覆盖
同步任务中检测到源库的主键更新(INSERT和UPDATE)数据与目标库发生冲突时,用源库的主键数据覆盖目标的主键数据。
冲突处理时SQL语句改写如下:
INSERT -> REPLACE INTO
UPDATE -> DELETE + REPLACE INTO
DELETE 不改写
这里首先需要明确的是,DTS冲突策略的应用,仅针对发生主键冲突时的数据,应用后可以按用户设置的策略进行处理,使任务报错提醒给用户或者继续运行。不产生冲突的场景,如下图的UPDATE和所有的DELETE主键操作,源端的操作都会正常同步到目标端,DTS不会干预。
图:不产生冲突的场景下,DTS不干预
如果没有主键分区,多个源端INSERT同一条主键数据引起冲突时,DTS可以按照冲突策略来干预,但多个源端对同一条主键数据进行正常的UPDATE时(如上图,没有冲突),DTS不会干预,这样可能会出现,目标端的数据被重复刷新或者随意刷新(不能确定最终刷新的结果是哪个节点同步过来的),同一条主键数据在多个节点显示的不一致。
综上,要实现多节点数据一致性,进行主键分区是非常有效的方法,可以从源头上避免数据产生冲突。
3.2 两地三中心数据同步应用
下面结合两地三中心的数据架构,介绍数据一致性如何保证,以及通过设置冲突策略来处理冲突问题。
图:两地三中心架构示例
图中1-4为DTS的一条单向同步链路,1、2构成A<->B的双向同步,3、4构成A->C之间的双向同步。
A、B同时负责数据写入,提前规划好A、B各自负责更新的主键数据,例如A负责更新主键ID为1-100的数据,B负责更新主键ID为101-200的数据。
冲突策略给出如下推荐,用户在实际的场景中可以根据业务的情况进行灵活选择。
- 如果希望发生INSERT主键冲突时DTS给出提示用户手动处理,则4条链路都设置冲突报错。
- 如果希望INSERT主键时以A的为准,则A->B、A->C设置为冲突覆盖,B->A、C->A设置为冲突忽略。(不能保证UPDATE主键和DELETE主键操作也以A的为准)
4. 同步延迟问题
目标数据库相对于源数据库的延迟也是DTS 关注的一个重要问题,当 DTS 同步数据的速度达不到源端写入速度,就会出现延迟,这在某些场景下会影响业务对目标数据库的使用。
腾讯云 DTS 采用全新自研内核,对同步性能做了极致的优化,能满足大部分实际业务场景下对同步性能的需求。
如下为当前DTS同步任务中不同规格的RPS参考(RPS表示DTS每秒同步至目标表的数据行数)。
表:DTS同步任务中不同规格的RPS上线参考
micro 1000
small 2000
medium 5000
large >5000
在实际业务场景中,RPS可能会受源和目标数据库的运行负载、DTS 访问源和目标数据库的网络延时、网络带宽等多种因素的影响。腾讯云 DTS 经过优化,对网络延时的容忍度较高,在一些跨地域的场景中也能保持较好的性能。如果用户需要更高的传输性能,也可以通过专线接入、VPN接入等方式,保证数据传输过程中的网络延时和带宽质量。
总结
腾讯云DTS已具备实时数据同步、回环处理、数据冲突处理、高性能传输等能力,可根据企业需求灵活定制多种同步拓扑架构,用于两地三中心、异地多活等场景的数据同步。