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

字数 3892阅读 476评论 0赞 0

**作者**

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

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

## 导读

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

# 背景和前言

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

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

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

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

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

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

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

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

# 从 Oracle 迁移到 TiDB 实践

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

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

![](/home/attachment/202306/05/1240047_168595077990595.jpg)
 中国人寿财险核心系统分布式数据库改造历程

## 1  迁移准备阶段

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

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

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

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

![](/home/attachment/202306/05/1240047_168595080786795.jpg)

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

## 2  开发测试阶段

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

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

## 3  投产切换与运行保障

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

![](/home/attachment/202306/05/1240047_168595082265290.jpg)

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

## 4  成效总结与未来展望

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

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

TiDB Oracle MySQL

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

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

添加新评论0 条评论

文章目录收起目录

作者其他文章

相关文章

相关问题

相关资料