低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型

2024年 5月 7日 66.7k 0

本文由 韩谷悦(花名:伶素)撰写,2019年9月4日首发于 OxeanBase 公众号。

OMS介绍

OceanBase迁移服务(OceanBase Migration Service,以下简称OMS)是OceanBase提供的一种支持同构或异构RDBMS与OceanBase之间进行数据交互的服务,它提供了数据的在线迁移和实时增量同步的数据复制能力。

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-1

通过OMS用户可以不停服地将数据迁移到OceanBase上,在业务切换应用数据库到OceanBase前,OMS启用反向数据同步链路,再执行应用切换到OceanBase数据库,重新建立主备关系,此时所有在切换后发生在OceanBase数据库上的数据变更都将实时同步至切换前的源端数据库,以此来应对紧急回切的需求场景,最大程度的降低业务迁移风险,助力企业用户构建高可用、高可靠的数据体系架构

OMS可以在异构的IT基础结构之间实现大量数据毫秒级延迟的实时复制,从而在包括在线数据迁移、跨城异地数据灾备、应急系统、实时数据同步、容灾、数据库升级和移植等多个场景下应用。

OMS可实现在业务应用无感知,不中断的前提下执行数据迁移和同步,保证数据的完整性和事务的一致性。OMS提供可视化的集中管控平台,通过简单的配置完成数据的实时迁移,对源数据库和业务系统的影响开销可忽略不计,OMS帮助用户以最低的风险,极小的开销,最高的效率实现同构/异构数据库向OceanBase进行实时数据迁移和数据同步。目前OMS支持的源端数据库包括Oracle、MySQL、DB2、OceanBase等。

OMS基本功能

  1. 数据迁移

数据迁移功能可以帮助用户在线将其他数据源的数据实时的迁移到OceanBase上。OMS的数据迁移提供在线迁移,OMS部署服务器需要能够同时与源实例和目标实例保持网络连通,而用户只需配置好待迁移的源库和部署好的目标库,选择需要迁移的表(白名单)或不需要迁移的表(黑名单),即可启动数据迁移任务,不需要中间任务额外的处理或者启停、中断等人为操作。OMS自动完成整个数据迁移的全部流程,实现源端数据库(数据表)中的存量数据全部迁移到目标端数据库(数据表)当中,同时保持源库到目标库的实时增量同步。

1)迁移任务

迁移任务是OMS数据迁移服务的基本单元。OMS在创建迁移任务时可以指定的迁移范围最大是数据库级别,最小范围是表级别。迁移任务的生命周期包括了结构迁移、数据全量迁移、增量迁移、同步链路切换、同步链路反向切换以及同步链路清理的全部流程管理。

2)迁移模式

OMS数据迁移支持结构迁移、全量数据迁移和增量数据迁移等迁移模式。其中:

  • Schema结构迁移 :负责将源库中的数据对象定义(如表、索引、约束、视图等等)迁移到OceanBase目标库中。当源端数据库非OceanBase时,会依据目标OceanBase的租户类型(Oracle或MySQL)的语法定义标准进行格式转换和拼装,而后复制到OceanBase目标库中。
  • 全量数据迁移:将源库表中的存量数据迁移至OceanBase库里对应的表。OMS提供在线数据迁移,全量数据迁移过程中,源库不断有业务写入,在全量数据迁移之前OMS会启动增量拉取模块,拉取源实例的增量更新数据,并解析、封装、存储在OMS中。
  • 增量数据迁移:将全量迁移过程开始后的源库中发生变化的数据(新增、修改或删除)同步到OceanBase库里对应的表里。当全量数据迁移完成后,OMS会启动增量数据回放模块,从增量数据拉取模块中获取增量数据经过过滤、映射转换后同步到目标实例,增量数据同步追平后,OMS会维护源库到目标库的实时数据同步链路。  

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-1

3)数据校验

在全量数据迁移完成,增量数据迁移至目标端与源端基本追平后,OMS会自动发起一轮针对源库配置的数据表和目标端表的全量数据校验任务。在增量数据同步过程中,用户也可以发起自定义的数据校验,OMS会提供相应的接口。针对校验出来的不一致数据,OMS会提供以源端为基准,在目标端做订正操作的SQL脚本。

4)同步链路切换

切换指应用将数据库连接从源实例改为目标实例,同时调整数据链路同步方向的过程,需要应用短暂停服务修改应用数据源配置,切换在传统行业也叫割接。

应用在停止后,可在OMS再次发起一轮全量校验再次确认源端和目标端数据一致,然后再修改数据源配置。

OMS提供业务切换之后,目标实例到源实例的增量同步链路,将业务切换后在OceanBase端产生的数据变更实时的回流到原业务数据库。实现方法是应用在再次启动之前,在OMS应用里点击“切换”操作。切换操作会停掉从源库到OceanBase的数据同步链路,启动从OceanBase到切换前源库的数据同步链路。

5)反向切换

反向切换是指将应用数据库连接从目标库改回源库,同时调整数据同步链路方向的过程。当业务应用运行在目标端数据库遇到严重问题时,可使用反向切换功能。应用在再次启动之前,也需要在OMS里点击一下“反向切换”操作。反向切换会停掉从目标端到源端的数据迁移链路,并恢复从源端到目标端的数据迁移链路。此后,源端的数据库修改将再次同步到目标端中。

反向切换能力极大的降低了数据迁移到OceanBase上的风险。 

2. 数据同步

OceanBase在三地五中心部署方案中通过Paxos协议和多副本部署实现了真正的异地容灾,但少数情况下,特别是一些基于底座输出场景,由于云平台等限制客户首先上线了单个数据中心。为解决单数据中心的地区级故障导致的服务不可用问题以及满足监管需求,用户往往会在异地构建灾备中心,当业务中心发生地区故障时,直接将业务流量切换到灾备中心。当前OMS的数据实时同步功能主要为底座中枢库之间的数据实时同步提供了解决方案。下图所示,OMS支持异地灾备部署的典型案例。

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-3

如上图所示,当业务中心故障时,可以通过切换域名的方式实现灾备中心的业务接管。通过OMS的秒级切换和实时校验功能为灾备中心的创建提供有力支持。OMS通过多资源节点部署实现组件高可用,任意一个OMS单元节点发生故障,同步链路会自动找到机房内的其他可用资源节点做断点续传。

3. 复制拓扑关系

1)单向复制

单向同步是OMS支持的最基本的迁移拓扑结构,一对一的单向配置。主要应用于数据迁移场景,可实现在线构建主备集群。

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-4

2)双向复制

OMS支持异地双活的典型场景即实例之间的在线双向同步,业务应用可以连接任意地区的实例以支撑业务应用。当两个在线系统的数据集合完全相同时,为了确保同步数据的一致性,业务层需要保证相同表的同一个主键或唯一键的数据记录只在一个数据库实例中更新,亦或是可以从应用层区分每个实例存储的库表,单表只支持在单实例中更新。

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-5

3)广播式复制

广播式复制的主要应用于业务拆库的同步场景。

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-6

4)聚集式复制

聚集式复制主要应用于业务整合场景,如多个业务库之前部署在MySQL、Oracle上,OMS可以将其并发的迁移到OceanBase的不同租户中。为保障同步数据的一致性,每个同步实例应选择不同的同步对象。

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-7

  1. 数据源类型

OMS支持多种类型的关系型数据库到OceanBase的迁移,具体功能上会因源端数据库特点而略有区别,如下表所示:

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-8

OMS架构设计与组件原理

本节将重点介绍OMS的整个系统架构以及组件的基本原理。OMS的体系结构如下图所示:

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-9

  1. 结构迁移的核心组件DBCat

与其他迁移工具不同的是,结构迁移的核心组件DBCat作为OceanBase原生的Schema转换引擎,根据源端和目标端的具体数据源类型、字符编码类型,做精确的数据类型映射或转换,同时与OceanBase的不同类型租户对Oracle/MySQL的兼容能力严格对齐,如果源库有个别数据类型在OceanBase的相应版本里暂时不支持,会选择为最接近的、兼容度最高的数据类型做转换映射。OMS的结构迁移组件支持表、约束、索引、视图以及多种数据库对象的转换和迁移。

2. 全量数据流和数据校验模块

全量数据流模块Light-dataflow负责源库存量数据的迁移和迁移后的全字段校验。为了扩展的灵活性及组件充分的复用,全量数据流模块Light-dataflow自下而上分别是Reader模块、Writer模块、Broker service模块和统一数据模型层。

  • Reader模块负责从源端数据读取数据,每一种数据库类型都有对应的Reader plugin。Reader将读取的记录按统一数据模型层转换后放入Broker中,由其他模块消费。
  • Writer模块从Broker中订阅某张表的记录,根据每个Writer plugin的类型,将记录按统一数据模型层转换为适配下游的插入语句写入下游。
  • Broker模块用于解耦Reader、Writer或其他模块,从而异步化提升性能,更重要的是解耦后,上下游模块可以相互独立,便于维护和扩展。
  • 统一数据模型层:各组件间通过Broker要实现解耦,还需要有一层统一数据模型。数据从Reader写入Broker时需要先按统一数据模型转换,从Broker获取数据记录后,也需要由记录的统一数据模型转化为下游适配的对象或语句。

以上四个底层模块基础上,OMS编排实现了数据的迁移、校验以及订正。对于迁移来说,配置好源端、目的端、待迁移表、库表映射等关键信息后,为要每张迁移表创建一条reader --> broker --> writer的通道,然后由上层迁移程序对每张表的迁移进行调度。通常会并发迁移多张表,每张表的迁移在Reader和Writer也都可以并发执行。对于数据校验和订正来说,也是在配置好源端、目的端、待迁移表、库表映射等关键信息后,为每对校验的表创建src reader --> broker <-- dst reader 以及 broker --> verifier的校验通道。

3. 日志读取模块

不同类型数据库的日志读取模块实现方式不同,下面以Oracle和OceanBase为例做简要介绍:

  • Oracle Store模块由两部分构成:日志抓取客户端(OracleAgent)和日志转换模块(OracleReader)。其中,OracleAgent负责将Oracle数据库的重做日志或是归档日志通过网络链路传输到抓取存储服务器(crawler),OracleReader对crawler上的日志进行解析、过滤,并转换成内部标准的记录格式后交由存储服务队列(DrcQueue)进行存储。
  • OceanBase的Store实现方式是依赖于OceanBase的liboblog工具来获取,liboblog是OceanBase的增量数据同步工具,通过RPC方式拉取OceanBase各个分区的Redo日志,然后结合各个表、列的Schema信息,将Redo日志转换为一种中间定义的数据格式,最后以事务方式输出修改的数据。

4. 同步写入模块

同步写入模块JDBCWriter是从Store中拉取增量数据,再翻译成insert/udpate/delete等SQL写到目的端。Store记录的增量是流式的,通过pipeline实现保证数据的有序性。因此Writer单线程顺序执行事务可以满足基本需求,但性能不可扩展,于是我们引入并发写机制,在提升同步性能的同时也需要保证数据的一致性,为此我们引入冲突矩阵机制实现乱序并发写入,来确保每个事务的最终一致性。同时为了避免循环复制问题,所有通过OMS同步写入模块写入的数据将会在Store中做打标处理,不会再次被其他同步写入模块消费掉。

5. 分层视角

OMS从功能视角上分三层体系层次,分别是:

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-10

  • 服务接入层:主要包括客户端的迁移服务的交互,各种类型数据源的管理、迁移任务的录入、OMS各个组件模块的运维和监控等
  • 流程编排层:主要负责实现上层各种迁移任务的执行细节。如表结构同步任务、启动全量数据同步、增量数据同步、数据校验和数据订正任务等
  • 组件链路层:主要包括负责全量数据迁移和全量数据校验并针对校验不一致数据生成订正SQL的checker模块、负责数据库增量的日志读取、解析和存储的Store模块以及向目标端数据库并发写入的JDBCWriter模块、以及组件状态监控supervisor模块等



OMS产品优势

OMS是当前以及未来对OceanBase迁移支持最好的产品,数据链路组件是基于OceanBase内核原生研发的,尤其是使用OceanBase的liboblog工具获取OceanBase的增量,并建立反向数据同步链路,极大的降低了整体迁移方案的风险。OMS迁移服务跟同类产品相比还具备以下五大优势:

  • 简单易用

安装便捷,提供数据迁移和同步任务的可视化管理界面,向导式的链路创建流程,用户通过OMS应用控制台即可简单轻松创建数据传输链路。

  • 多种类型数据库支持

目前支持源端数据库类型有Oracle、MySQL、DB2、OceanBase,支持全量迁移和增量数据同步。

  • 秒级回流&回滚

当应用切换到目标端OceanBase数据库上后,数据修改会被实时同步回源库,同步链路的正向切换、反向切换均是在秒级内完成。

  • 一键完成迁移

整个数据迁移链路和回滚机制的搭建都是在页面上连贯操作完成,使用简便。

  • 秒级数据验证

数据增量同步过程中,可以定时校验两边的数据增量是否一致。同时展示差异数据,提供快速订正途径。

总结

对金融企业而言,系统架构从集中式转向分布式是大势所趋。在数据库层面,要从单机数据库转向分布式数据库虽极具诱惑,但更换数据库,企业决策依然会非常谨慎,因为涉及到巨大的风险和成本,其中就包含数据库迁移过程中的风险和成本。而OMS的出现则在一定程度上消除了这一阻碍,也在最大程度上降低了业务迁移的风险。

目前,已经有越来越多的客户通过使用OceanBase迁移服务从集中式架构向分布式架构完成转型。截止到今天,OceanBase已经在南京银行、西安银行、人保健康险、常熟农商行、苏州银行、广东农信等多家商业银行和保险机构上线。OceanBase不断通过产品端的革新,为传统企业输送“互联网基因”,帮助更多客户向分布式架构转型。

作者简介:韩谷悦(花名:伶素)北京邮电大学计算机专业硕士,工作8年多来一直从事数据库产品的研发工作,目前在OceanBase团队从事产品管理的相关工作。

————————————————————————————————————————————

社区版官网论坛

社区版项目网站提 Issue

欢迎持续关注 OceanBase 技术社区,我们将不断输出技术干货内容,与千万技术人共同成长!!!

搜索🔍钉钉群,或扫描下方二维码,还可进入 OceanBase 技术答疑群,有任何技术问题在里面都能找到答案哦~

低风险高效率!看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型-11

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论