从 Oracle 迁移到 TiDB 的方案设计与用户实践

原创
05/25 14:14
阅读数 101

作者

盛玉 , 中国人寿财险金融科技中心系统运行部

王耀强 , PingCAP 资深解决方案架构师

导读

当前,全球数字化浪潮推动数字经济与实体经济融合,更多的企业意识到数据平台对业务增长和创新的重要性。通过国产化迁移和替换数据库,中国数据库市场蓬勃发展,为企业自主创新奠定了基础。本文以中国人寿财险公司为例,详述其从 Oracle 到 TiDB 分布式数据库的四个阶段的迁移,展示了金融行业对数据库的高要求和国产数据库的价值应用。

背景和前言

当前,数字化浪潮席卷全球,随着大数据、云计算、移动互联网等数字技术的广泛应用,数字经济与实体经济深度融合的趋势越加明显。在数字化转型加速期,全球企业与组织深刻意识到数据平台是业务发展的重要驱动力,如何有效利用数据,充分释放数据价值,成为业务增长和创新的关键基础。

近年来,科技创新、科技自立自强已作为重要发展战略,中国数据库市场正迎来发展的黄金窗口期。在 IT 基础设施之中,数据库作为三大基础软件之一,承载了各类业务系统的不同种类数据,如客户信息类、交易流水类、用户行为类等,通过对底层数据库的国产化替换和迁移,为企业 IT 系统的自主创新奠定坚实的基础。

业务系统替换升级的发展路径

企业在不同时期、由不同业务部门主导来推动信息系统的建设,割裂的烟囱式架构使得系统之间的数据无法打通并利用。数字化转型和国产数据库的迁移工作,并不是简单的对传统商业数据库产品(如 Oracle 等)替换,更是要站在企业发展的战略高度,重新对业务、应用、技术架构等方面进行综合考量,满足企业可持续规模化发展的需求。金融机构在国产数据库替换道路上,呈现出两类发展路径:

1 对成熟商业数据库的平行替换

金融机构有部分业务系统由于开发时间较早、熟悉代码的人员较少、又特别依赖于成熟商业数据库的特性等原因,往往会优先选择不改或者少改应用、使用兼容商业数据库特性的国产数据库进行替换。虽然短期内能够实现快速替换,但长期看这种方案使得技术债进一步堆积,用户对原有数据库的粘性没有减少,业务开发人员的习惯并没有改变,因此“平行替换”适用于相对较传统的应用。

2 从集中式到分布式的架构跃迁

分布式、云原生为代表的新技术的出现,为数据库技术突破实现弯道超车做好了理论铺垫。伴随着数据使用场景的多元化,对于海量数据增长迅速、高并发读写、高峰业务弹性需求大的业务系统,集中式商业数据库已经无法支撑,从敏捷开发迭代、技术自主掌控、业务连续性等角度进行评估,金融机构更倾向选择国产分布式数据库实现架构的跃迁,这样才能在基础架构层面开辟自主创新的道路。

从 Oracle 迁移到 TiDB 实践

金融行业对于数据库的要求极其严苛,“稳定、高可用、高并发、高扩展”是选择合适国产数据库的多维度考量标准。TiDB 作为原生分布式数据库,已广泛应用金融、互联网、电信、能源等各行各业中的不同业务场景,在积极协助企业稳步推进国产化相关工作,并总结了数据库国产化迁移的实践经验。

为响应国家层面“加快建设科技强国,实现高水平科技自立自强”的号召,中国人寿财险公司积极推进数字化转型,启动 IT 架构的整体规划工作,探索业界先锋技术及进行分布式架构转型。在数据库的国产化迁移过程中,按照先边缘再核心的策略稳步推进,目前已完成多个核心业务系统从 Oracle 到 TiDB 的迁移改造工作,同时也为后续多部署形态的架构打下了坚实的基础。本文以中国人寿财险公司核心系统的改造实践为蓝本,阐述通过四个阶段的分步骤实施,实现从 Oralce 迁移到 TiDB 分布式数据库。

img

中国人寿财险核心系统分布式数据库改造历程

1 迁移准备阶段

首先是对分布式数据库的选型,从数据库产品特点是否与业务场景匹配,满足业务平滑迁移及持续发展;是否完全自主研发,保证产品的持续演进能力;是否有完善的生态建设,包括上下游工具、文档体系、培训体系;是否有广泛的行业用户案例;是否支持云原生,满足未来的架构演进等角度进行综合评估后进行决策。

其次是迁移改造规划,主要涉及迁移改造量分析、迁移方案制定和回退方案制定几个方面。异构数据库之间的迁移适配,通常涉及应用系统的改造。以保险为例,保险业务逻辑处理复杂,各业务系统之间的调用关系、完成整个交易的复杂度较高。中国人寿财险制定的策略是不再依赖封闭的商业数据库特性,而是由应用来主导业务流程实现,实现系统分布式微服务架构的转型。应用改造分析主要包括各系统间调用模式、微服务的设计等。异构数据库的改造分析,涉及数据库对象改造(表结构、其他对象等)、SQL 语法改造、运维工具改造和流程变更等;通过提供的 O2T schema 比对工具,可以比对 schema 迁移后,检测出是否有表、视图、或索引遗失的情况。

迁移方案的制定需要结合系统的存量数据及每日增量数据情况,制定切换前全量截面数据加截面后增量追数的迁移方式,形成了迁移手册及迁移中使用的脚本工具,为后续项目的开展提供经验支持。借助 Kettle、SQLULDR2 与 Lightning、国产数据库同步工具、OGG 等多种模式,丰富数据迁移方案、实现差异化的需求,同时可以通过 o2t-sync-diff 工具比对 Oracle 和 TiDB 的快照数据正确性。

数据库是保险企业信息系统当中的关键基础设施,稳定运行是重中之重,因此也需要制定完善的回退方案。从 Oracle 到 TiDB 迁移,可以使用 OGG 进行数据实时同步,反向同步通过 TiDB Drainer 工具把 Oracle 作为目标库,实现高效的反向回退。

img

从 Oracle 迁移到 TiDB 的并行和回退机制

2 开发测试阶段

开发阶段需要对于原有业务系统使用的数据库对象类型、数据库函数功能等进行细致分析,通过 Oracle 到 TiDB 的数据类型映射、函数映射等指导手册、并结合 TiDB 数据库开发规范,完成代码开发及单元测试工作。测试阶段需要涵盖功能、性能、高可用、流量双发和回退测试。在系统开发完毕之后,需要进行各业务功能测试,并按照 3-5 年未来业务量的数据存储基线做性能测试,完成业务单交易负载测试、混合交易负载、水平扩展性测试等各项压力测试,验证高并发条件下数据库所能承载的业务流量。

在高可用测试方面,需要完成分布式数据库生产部署架构搭建、进行数据库基础组件故障演练,进行数据库同城和异地切换演练,以及进行数据库物理备份和逻辑备份恢复等测试。流量双发测试可以对生产业务流量进行异步复制,搭建生产流量双发并行环境,实现 100% 全量业务生产级别仿真执行,对执行结果利用 o2t-sync-diff 比对工具进行生产和并行环境数据的比对验证,同时在并行环境搭建 TiDB Drainer 数据库增量回退链路,实现数据库日志级别的一致性数据同步,进行应用和数据库回退演练。

3 投产切换与运行保障

投产切换的所有步骤严格按照投产前演练的顺序和操作方式进行,防止出现流程上以及操作上的风险。以中国人寿财险报价中心投产切换为例,为了防止投产风险,制定了分批切换策略:第一批按照 10% 的业务流量将部分典型渠道进行切换验证,数据迁移按照全量和增量迁移,无需回退;第二批按照 30% 的业务流量将标准和个性化的业务进行切换,重复第一批迁移流程,部分业务表进行回退链路搭建;最后一批切换 60% 的核心业务流量,新增部分核心业务表的回退链路。在投产后进行 48 小时内进行数据库各性能指标实时监控保障支持,保障投产顺利实施完成。

img

中国人寿财险分批次切投产切换

4 成效总结与未来展望

TiDB 上线后完全满足各项业务性能指标,运行稳定,承载核心系统报价中心的全渠道业务量。TiDB 分布式数据库在中国人寿财险核心业务的成功应用,首先节省了成本,通过 X86 通用服务器代替 IBM 小型机,硬件投入成本降低了 75%;其次,用先进的分布式数据库替换集中式数据库,改造完成之后,OLTP 和 OLAP 性能较原来的 Oracle 数据库均有了明显上升,其中全量状态统计报表的处理时效提升 80 多倍,并具备了更强的数据汇聚和查询能力;最后,通过开放架构实现了安全可控,初步打造了中国人寿财险的自主创新体系,并不断演进,为后续异地双活改造奠定了坚实的技术基础。

目前,国内金融机构的重要业务系统仍在使用国外成熟的商业数据库,而国产数据库从成熟度和稳定性上还需要进行持续的打磨。数据库技术的发展离不开新兴技术和业务场景的融合,因此不必局限于传统数据库的技术锁定。在产业变革加速的今天,中国数据库厂商应加大核心技术攻关力度,提升产品创新性和影响力,加强知识产权保护,探索变道超车的发展道路,逐步形成技术引领、生态完善、应用成功的创新发展局面。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部