共计 3457 个字符，预计需要花费 9 分钟才能阅读完成。
作者
盛玉 ，中国人寿财险金融科技核心零碎运行部
王耀强 ，PingCAP 资深解决方案架构师
导读
以后，寰球数字化浪潮推动数字经济与实体经济交融，更多的企业意识到数据平台对业务增长和翻新的重要性。通过国产化迁徙和替换数据库，中国数据库市场蓬勃发展，为企业自主翻新奠定了根底。本文以中国人寿财险公司为例，详述其从 Oracle 到 TiDB 分布式数据库的四个阶段的迁徙，展现了金融行业对数据库的高要求和国产数据库的价值利用。
背景和前言
以后，数字化浪潮席卷寰球，随着大数据、云计算、挪动互联网等数字技术的广泛应用，数字经济与实体经济深度交融的趋势越加显著。在数字化转型减速期，寰球企业与组织粗浅意识到数据平台是业务倒退的重要驱动力，如何无效利用数据，充沛开释数据价值，成为业务增长和翻新的要害根底。
近年来，科技翻新、科技自立自强已作为重要倒退策略，中国数据库市场正迎来倒退的黄金窗口期。在 IT 基础设施之中，数据库作为三大根底软件之一，承载了各类业务零碎的不同品种数据，如客户信息类、交易流水类、用户行为类等，通过对底层数据库的国产化替换和迁徙，为企业 IT 零碎的自主翻新奠定松软的根底。
业务零碎替换降级的倒退门路
企业在不同期间、由不同业务部门主导来推动信息系统的建设，割裂的烟囱式架构使得零碎之间的数据无奈买通并利用。数字化转型和国产数据库的迁徙工作，并不是简略的对传统商业数据库产品（如 Oracle 等）替换，更是要站在企业倒退的策略高度，从新对业务、利用、技术架构等方面进行综合考量，满足企业可继续规模化倒退的需要。金融机构在国产数据库替换路线上，呈现出两类倒退门路：
1 对成熟商业数据库的平行替换
金融机构有局部业务零碎因为开发工夫较早、相熟代码的人员较少、又特地依赖于成熟商业数据库的个性等起因，往往会优先选择不改或者少改利用、应用兼容商业数据库个性的国产数据库进行替换。尽管短期内可能实现疾速替换，但长期看这种计划使得技术债进一步沉积，用户对原有数据库的粘性没有缩小，业务开发人员的习惯并没有扭转，因而“平行替换”实用于绝对较传统的利用。
2 从集中式到分布式的架构跃迁
分布式、云原生为代表的新技术的呈现，为数据库技术冲破实现弯道超车做好了实践铺垫。随同着数据应用场景的多元化，对于海量数据增长迅速、高并发读写、顶峰业务弹性需要大的业务零碎，集中式商业数据库曾经无奈撑持，从麻利开发迭代、技术自主掌控、业务连续性等角度进行评估，金融机构更偏向抉择国产分布式数据库实现架构的跃迁，这样能力在基础架构层面开拓自主翻新的路线。
从 Oracle 迁徙到 TiDB 实际
金融行业对于数据库的要求极其严苛，“稳固、高可用、高并发、高扩大”是抉择适合国产数据库的多维度考量规范。TiDB 作为原生分布式数据库，已广泛应用金融、互联网、电信、能源等各行各业中的不同业务场景，在踊跃帮助企业稳步推动国产化相干工作，并总结了数据库国产化迁徙的实践经验。
为响应国家层面“放慢建设科技强国，实现高水平科技自立自强”的号召，中国人寿财险公司踊跃推动数字化转型，启动 IT 架构的整体规划工作，摸索业界先锋技术及进行分布式架构转型。在数据库的国产化迁徙过程中，依照先边缘再外围的策略稳步推动，目前已实现多个外围业务零碎从 Oracle 到 TiDB 的迁徙革新工作，同时也为后续多部署状态的架构打下了松软的根底。本文以中国人寿财险公司外围零碎的革新实际为底本，论述通过四个阶段的分步骤施行，实现从 Oralce 迁徙到 TiDB 分布式数据库。
中国人寿财险外围零碎分布式数据库革新历程
1 迁徙筹备阶段
首先是对分布式数据库的选型，从数据库产品特点是否与业务场景匹配，满足业务平滑迁徙及继续倒退；是否齐全自主研发，保障产品的继续演进能力；是否有欠缺的生态建设，包含上下游工具、文档体系、培训体系；是否有宽泛的行业用户案例；是否反对云原生，满足将来的架构演进等角度进行综合评估后进行决策。
其次是迁徙革新布局，次要波及迁徙革新量分析、迁徙计划制订和回退计划制订几个方面。异构数据库之间的迁徙适配，通常波及利用零碎的革新。以保险为例，保险业务逻辑解决简单，各业务零碎之间的调用关系、实现整个交易的复杂度较高。中国人寿财险制订的策略是不再依赖关闭的商业数据库个性，而是由利用来主导业务流程实现，实现零碎散布式微服务架构的转型。利用革新剖析次要包含各零碎间调用模式、微服务的设计等。异构数据库的革新剖析，波及数据库对象革新（表构造、其余对象等）、SQL 语法革新、运维工具革新和流程变更等；通过提供的 O2T schema 比对工具，能够比对 schema 迁徙后，检测出是否有表、视图、或索引遗失的状况。
迁徙计划的制订须要联合零碎的存量数据及每日增量数据状况，制订切换前全量截面数据加截面后增量追数的迁徙形式，造成了迁徙手册及迁徙中应用的脚本工具，为后续我的项目的发展提供教训反对。借助 Kettle、SQLULDR2 与 Lightning、国产数据库同步工具、OGG 等多种模式，丰盛数据迁徙计划、实现差异化的需要，同时能够通过 o2t-sync-diff 工具比对 Oracle 和 TiDB 的快照数据正确性。
数据库是保险企业信息系统当中的要害基础设施，稳固运行是重中之重，因而也须要制订欠缺的回退计划。从 Oracle 到 TiDB 迁徙，能够应用 OGG 进行数据实时同步，反向同步通过 TiDB Drainer 工具把 Oracle 作为指标库，实现高效的反向回退。
从 Oracle 迁徙到 TiDB 的并行和回退机制
2 开发测试阶段
开发阶段须要对于原有业务零碎应用的数据库对象类型、数据库函数性能等进行粗疏剖析，通过 Oracle 到 TiDB 的数据类型映射、函数映射等领导手册、并联合 TiDB 数据库开发标准，实现代码开发及单元测试工作。测试阶段须要涵盖性能、性能、高可用、流量双发和回退测试。在零碎开发结束之后，须要进行各业务功能测试，并依照 3-5 年将来业务量的数据存储基线做性能测试，实现业务单交易负载测试、混合交易负载、程度扩展性测试等各项压力测试，验证高并发条件下数据库所能承载的业务流量。
在高可用测试方面，须要实现分布式数据库生产部署架构搭建、进行数据库根底组件故障演练，进行数据库同城和异地切换演练，以及进行数据库物理备份和逻辑备份复原等测试。流量双发测试能够对生产业务流量进行异步复制，搭建生产流量双发并行环境，实现 100% 全量业务生产级别仿真执行，对执行后果利用 o2t-sync-diff 比对工具进行生产和并行环境数据的比对验证，同时在并行环境搭建 TiDB Drainer 数据库增量回退链路，实现数据库日志级别的一致性数据同步，进行利用和数据库回退演练。
3 投产切换与运行保障
投产切换的所有步骤严格依照投产前演练的程序和操作形式进行，防止出现流程上以及操作上的危险。以中国人寿财险报价核心投产切换为例，为了避免投产危险，制订了分批切换策略：第一批依照 10% 的业务流量将局部典型渠道进行切换验证，数据迁徙依照全量和增量迁徙，无需回退；第二批依照 30% 的业务流量将规范和个性化的业务进行切换，反复第一批迁徙流程，局部业务表进行回退链路搭建；最初一批切换 60% 的外围业务流量，新增局部外围业务表的回退链路。在投产后进行 48 小时内进行数据库各性能指标实时监控保障反对，保障投产顺利施行实现。
中国人寿财险分批次切投产切换
4 功效总结与将来瞻望
TiDB 上线后齐全满足各项业务性能指标，运行稳固，承载外围零碎报价核心的全渠道业务量。TiDB 分布式数据库在中国人寿财险外围业务的胜利利用，首先节俭了老本，通过 X86 通用服务器代替 IBM 小型机，硬件投入老本升高了 75%；其次，用先进的分布式数据库替换集中式数据库，革新实现之后，OLTP 和 OLAP 性能较原来的 Oracle 数据库均有了显著回升，其中全量状态统计报表的解决时效晋升 80 多倍，并具备了更强的数据汇聚和查问能力；最初，通过凋谢架构实现了平安可控，初步打造了中国人寿财险的自主翻新体系，并一直演进，为后续异地双活革新奠定了松软的技术根底。
目前，国内金融机构的重要业务零碎仍在应用国外成熟的商业数据库，而国产数据库从成熟度和稳定性上还须要进行继续的打磨。数据库技术的倒退离不开新兴技术和业务场景的交融，因而不用局限于传统数据库的技术锁定。在产业改革减速的明天，中国数据库厂商应加大核心技术攻关力度，晋升产品创新性和影响力，增强知识产权爱护，摸索变道超车的倒退路线，逐步形成技术引领、生态欠缺、利用胜利的翻新倒退场面。
