导语
2021 年 9 月，某超大型金融机构圆满实现最初一个规模高达 20TB+ 外围数据库的全面迁徙革新工作，也为后续向云原生多活架构演进打下了松软的根底。该外围零碎数据库全量迁徙我的项目的胜利上线，建立了金融行业践行科技强国的标杆实际。阿里巴巴团体副总裁、阿里云智能新金融 & 互联网事业部总经理刘伟光 将历时一年的迁徙全过程残缺步骤及技术攻略做提炼梳理，残缺积淀成了举世无双的干货、本文的全部内容。
“实际出真知”，阿里云和 OceanBase 走出了助力超大型金融机构国产数据库全面迁徙松软的一步，积攒了弥足珍贵的教训。因而，本文不是对于数据库替换的剖析和畅想，而是真正从理论面对理论的大规模简单的外围利用零碎的技术平台替换的技术指南，过程中存在各种“剖析”文章中想不到的问题，尤其对于现有运行的环境的各种适配和兼容，对利用的敌对性等，对于这些问题到底该如何解决，在这篇文章一一给出了具体解法。
在国家层面提出放慢建设科技强国，实现高水平科技自立自强的大背景之下，某超大型保险（团体）公司深刻推动数字化转型，紧随先锋技术发展趋势，前瞻性布局启动 IT 架构分布式革新转型，并于 21 年 9 月圆满实现了最初一个规模高达 20TB+ 外围数据库的全面迁徙革新工作，也为后续向云原生多活架构演进打下了松软的根底。该数据库国产迁徙我的项目胜利上线，建立了金融行业践行科技强国的标杆实际，也是对国家科技自立自强策略以及国产技术的履责担当；更推动了整个国内数据库治理与利用体系科技生态建设和科技产业链的疾速成熟。
对于保险行业而言，短时业务并发压力虽没有互联网企业那么大，然而在业务复杂性和对数据库专有个性的依赖水平上，都要远大于互联网企业。保险业务的解决更为简单，繁多业务要多个零碎实现，调用链比银行和互联网业务更长、更简单，确保简单汇合大交易量的稳固是保险业务数据库国产的挑战。
因为金融机构对业务连续性和数据准确性的严苛要求，在传统头部金融机构中始终没能有一家实现国产数据库全面迁徙，直到这家保险公司胜利施行，并获得了五个冲破。
迁徙工夫短
从 2020 年 9 月到 2021 年 9 月，仅用时一年即实现迁徙，而传统金融机构还没有实现过如此大规模的外围零碎全量迁徙。
迁徙规模破纪录
一年内实现了包含传统外围、互联网外围、个险销售、团险销售、经营治理、客服治理、大数据在内的近百个业务零碎在线传统集中式数据库的全量搬迁工作，迁徙数据规模超 400TB、数据量超千亿，单库数据规模超 20TB，我的项目整体服务器规模超过 2 万核。
同时保障业务连续性和数据准确性
整个迁徙过程无一例回切，上线后近一年来，零碎稳固运行, 并历经 2021 年残缺周期的“业务大考”，禁受住了开门红顶峰 TPS 5 万 +、QPS 21 万 + 和包含精算在内的所有业务环节的严苛考验，齐全满足生产须要，实现国产数据库从可用到好用的逾越。
实现技术 100% 自主翻新
基于齐全自研翻新的国产原生分布式数据库，迁徙过程中版本升级继续发版共计 50 余次，最长需要解决工夫 2 个月（Pro*C+Tuxedo）。同时通过零碎培训与交换实现累计超过 500 位员工的数据库业余考试认证，实现了数据库的全面自主掌控能力。
新一代技术成为要害生产力
迁徙后，存储老本显著降落，性能也大幅度晋升，数据库由主备模式倒退为反对两地三核心多活部署，生产事件处理时长从小时级缩短到分钟级。
当咱们回顾这一段历程，过程尽管艰苦，但积攒了贵重的大型金融机构国产数据库迁徙实践经验。
国产金融级数据库迁徙实际
后期筹备工作
一、数据库选型
数据库是企业 IT 基础设施中皇冠上的明珠，存储企业运行外围数据资产，向上撑持利用，向下屏蔽底层基础设施，在金融行业“稳固压倒一切”的大前提下，数据库的选型更为谨慎，依据信通院《数据库倒退钻研报告（2021 年）》的形容，截止 2021 年 6 月底，国产关系型数据库厂商就高达 81 家，面对如此纷繁复杂的产品，如何抉择适合的数据库是摆在该保险公司背后的首要问题。尽管数据库产品泛滥，通过审慎的评估后，最终抉择了 OceanBase、PolarDB 等三款产品作为先期试点验证，次要选型考量点如下：
- 是否能满足业务的平滑迁徙和将来架构的演进；
- 是否具备分层解耦能力，重点解除数据库与底层硬件、操作系统、中间件之间的耦合；
- 是否有足够人才储备、资金投入，保障产品的长期演进和商业兜底；
- 是否有宽泛的行业实际案例；
- 是否能做到齐全自主研发；
- 是否能兼容原有开发运维体系，自有技术人员是否疾速把握。
二、基础设施筹备
该保险公司外围业务零碎原先共计应用超过 60 多台 IBM 和 HP 高端小型机，超过 70 多台高端存储，Oracle 架构耦合性强，难以实现规模和性能的线性扩大。本次国产数据库采纳机架式服务器和本地存储全面代替进口小型机及传统 SAN 存储架构，以满足外围零碎全量迁徙的云原生分布式架构革新。同时为了防止基础设施变动过大导致业务零碎不稳固，采纳 Intel+ 海光 + 鲲鹏服务器混合部署的架构。后期仍以 Intel X86 为主，逐渐适度到海光、鲲鹏芯片国产服务器。实现在线调整不同型号机器，解除了基础设施供给依赖。
2020 年 9 月，正式启动国产数据库迁徙我的项目之后，从硬件环境的型号抉择，到选出指标零碎，进行容量布局，不到两个月的工夫，从 0 开始实现国产数据库的硬件和操作系统适配、以及整个服务器集群的搭建。
三、迁徙策略制订
该保险公司的业务通过多年的倒退，业务范围覆盖全国，特色显明、品种繁多、关联关系错综繁冗，外围数据库迁徙须要宽泛调研和充沛的科学论证——既要求数据库产品对比原有生产数据库的高性能和安全可靠，也须要疾速实现多套零碎的平滑迁徙，同时解决资源弹性和数据库横向扩大的能力。因而，建设了数据库迁徙施行的对立标准和规范，总体遵循评估 - 实现 - 管制 - 剖析改良的迷信方法论，发展有序迁徙，并定下三大迁徙策略：
- 先平迁再做业务和架构革新降级，防止多个变量同时产生，影响业务的连续性。原有数据模型不做革新，主体革新工作由新数据库来承当；
- 迁徙批次以业务零碎为粒度，从低负载到高负载，从外围到外围；
- 用 1 年工夫实现所有业务零碎的数据库全量迁徙革新，所有零碎数据库迁徙动作工夫窗口只给周六、周日凌晨 0 点到早上 6 点，周末小流量验证，周一重点保障，不影响失常业务发展。
互联网外围迁徙
一、业务背景
该保险公司外围尽管波及零碎泛滥，但总结下来次要分为：互联网外围和传统外围，两头通过相似 ESB 的总线机制实现异步解耦。
自 2016 年，这家保险公司的互联网外围和传统新外围利用开始从传统单体架构向散布式微服务架构革新。到 2020 年，互联网外围业务零碎曾经拆分成了 40 多个微服务模块并实现 Mesh 化接入，互联网外围特点是：
- 数据库系统已实现全国物理集中、逻辑集中，数据库对接的关联系统较多；
- 尽管做了微服务拆分，数据库仍有一定量的存储过程，另外触发器、自定义类型、函数、外键、分区表等高级性能均有应用；
- 因为业务特点，要服务好 100 多万代理人，对数据库资源弹性和性能要求更高。
因而互联网外围的数据库迁徙面临的次要技术挑战是：
- 全国集中式部署下单点故障会影响到全国；
- 主数据系统作为外围业务链路中的整个保险开户入口，外部对接 43 个关联系统，数据规模超 20TB，最大单表超 50 亿条数据，每天接口调用量超 2000 万次，是该公司单体数据库日均申请量最大的零碎，因为关联系统多，且处在业务链路的外围地位，因而对数据库 SQL 的效率要求十分高，迁徙过程不能影响原有生产零碎；
- 迁徙到新的分布式数据库平台要具备实时同步到 Kafka 的能力，并兼容原有格局，供上游大数据系统生产。
二、技术计划
（一）整体选型
针对以上技术挑战，抉择了和原有 Oracle RAC 架构更靠近的 PolarDB 作为互联网外围数据库的替换，PolarDB 作为新一代云原生数据库次要特点如下：
- 计算与存储拆散，应用共享分布式存储，满足业务弹性扩大的需要。极大升高用户的存储老本；
- 读写拆散，一写多读，PolarDB 引擎采纳多节点集群的架构，集群中有一个主节点（可读可写）和至多一个只读节点（最大反对 15 个只读节点）。写操作发送到主节点，读操作平衡地散发到多个只读节点，实现主动的读写拆散；
- 基于 K8S 状态部署，提供分钟级的配置升降级，秒级的故障复原，全局数据一致性和残缺的数据备份容灾服务；
- 集中式架构，不须要进行分布式架构相干思考设计，和原有应用习惯保持一致，性能不低于原有数据库；
- 高度兼容 Oracle 数据库，利用基本上不须要做 SQL 语法调整。
（二）迁徙办法
为了防止对原有生产业务造成影响且保障迁徙数据的严格一致性，采纳了 DTS 全量 + 增量的形式，对于数据规模超大的 Oracle 数据库集群，如客户主数据系统，提前 2 周启动数据迁徙链路，在全量数据迁徙之前 DTS 会启动增量数据拉取模块，增量数据拉取模块会拉取源实例的增量更新数据，并解析、封装、存储在本地存储中。
当全量数据迁徙实现后，DTS 会启动增量日志回放模块，增量日志回放模块会从增量日志读取模块中获取增量数据，通过反解析、过滤、封装后迁徙到指标实例，通过指标端主键保证数据的唯一性。利用切换胜利后，从利用接口的响应速度上看，性能比 Oracle 数据库晋升约 30%。到 2020 年底，单方携手实现了互联网外围所有模块的迁徙，包含服务超百万代理人的出单零碎 APP，和注册用户超 1 亿的寿险 APP、客户主数据等共计 40 多个业务零碎。
为了缩小迁徙过程中对上游大数据生产造成影响，到大数据的同步链路革新采纳了 2 步走的策略。
第一步，减少 PolarDB 到 Oracle 的反向实时同步，原有 Oracle 到 Kafka 同步链路不变，防止数据库切换带来太大的变动；
第二步，参考 SharePlex 的格局对 DTS 进行定制化开发革新，待验证充沛后，间接替换掉 SharePlex 原有同步链路。
（三）次要挑战
迁徙实现后，PolarDB 作为互联网外围数据库，须要稳固撑持起 2021 年一季度业务冲刺。而最前端的出单零碎是整个性能压力的集中点，并且因为做了微服务化革新拆成了 30 多个模块，扩散在了多个数据库中，任何一个数据库都可能存在被打爆的危险，在迁徙到 PolarDB 之前是拆在多个 Oracle RAC 集群中，依附外部开发的数据库监控实现多个 Oracle 集群的监控，迁到 PolarDB 之后整体架构将更适应业务弹性的挑战：
- 对立管控：通过 PolarStack 将多台机器组成的集群进行对立管控，提供 DBaaS 服务；
- 资源弹性：实例由原来的物理机部署，变为 K8S Pod 部署，更为灵便和弹性；
- 读写拆散：通过智能代理服务实现主动的读写拆散，实现分钟级扩容，故障场景下主动切换，利用不须要做任何调整。
业务冲刺当天通过了三个顶峰工夫点：12：00、17：00、21：00，每小时出单量和全天出单量进入了历史的前三位，高峰期出单笔数达到 9000 笔 /s。
（四）迁徙历程
- 2020 年 9 月，互联网外围首批利用模块迁徙到 PolarDB，整个适配过程不到一个月。尔后，互联网外围各个模块就开始了大规模地迁徙；
- 2020 年 11 月，PolarDB 实现了最大的单库客户主数据迁徙；
- 2021 年 1 月底，PolarDB 作为互联网外围出单零碎的数据库，稳固撑持起该保险公司 2021 年一季度业务冲刺。
传统外围迁徙
一、业务背景
该大型保险公司的传统外围零碎历史悠久，既有 1998 年之前建成的，也有 2004 到 2008 年间建成的，时间跨度长，数据量异样宏大，单个数据库的数据规模甚至超过 20TB。更具挑战的是，很多老外围按省市做了拆分，要分省市别离进行迁徙，繁多老外围零碎须要迁徙的数据库可能就要多达 36 个。传统外围总体来说能够分为三类零碎：
第一类：2016、2017 年基于 Java 技术栈开发的新外围零碎，大略有 13 个；
第二类：别离在 1998 年之前，2004 到 2008 年间建成的老外围零碎，大略有 6 个。
第三类：一些可能要下线的，不在此次数据库迁徙范畴内的零碎。
这些传统外围的数据库过后面临的次要技术挑战是：
- 零碎关联关系庞杂，既有保单平台管理系统也有资金类零碎，零碎间关系难以梳理；
- 既有物理和逻辑集中的新外围，也有物理集中，逻辑拆散的老外围，其中老外围分省部署，每个省都会有一套数据库，迁徙工作量微小；
- 对 Oracle 专有个性依赖较多，大量应用存储过程、触发器、自定义类型、函数、外键等。更为挑战的是老外围大量应用 ProC（SQL 嵌入式 C 程序）和 Tuxedo（Oracle 中间件做分布式事务处理）做保单过程解决，仅某年金零碎波及到的 ProC 程序就有 1500 多个，约 140 万行代码，业务短时间难以革新；
- 单库体量十分大，超过 10TB 的就有 6 个，最大单库规模超 20TB，停机窗口短暂；
- 交易量大，每天数据库调用几十亿次，还有大量简单汇合类精算和结算类交易。
二、技术计划
（一）选型计划
针对以上技术挑战，抉择了分布式数据库 OceanBase 作为传统外围的替换，OceanBase 原生分布式数据库次要特点如下：
- 采纳基于无共享（Shared-Nothing）的多正本架构，整个零碎没有任何单点故障，保证系统的继续可用；
- 基于 LSM 存储引擎技术，联合新硬件的能力，采纳可扩大的分布式架构，提供高性能和扩展性；
- 数据库针对 Oracle、MySQL 等利用最为宽泛的数据库生态都给予了十分高的利用兼容性反对；
- 尽管为分布式架构，个别也不须要应用层做相应的从新设计如指定散布键等，与原有 Oracle 应用习惯基本一致；
- OceanBase 数据库齐全自主研发，不依赖内部开源代码，真正做到自主研发。
（二）迁徙办法
针对传统外围简单的数据库状况进行全面验证，最终造成了 140 页的迁徙操作手册和具体的割接行事历，为后续零碎的迁徙和大面积推广积攒了贵重的教训，并造成了规范的迁徙割接计划。
整体迁徙办法过程如下，从根底环境筹备 - 迁徙过程演练 - 正式割接 - 监控运维等四大环节进行逐项拆解，落实到人，准确到分。
对于规模较大 Oracle 数据库的迁徙，咱们总结了如下四点帮忙晋升迁徙效率：
第一，冷热数据拆散。
个别的业务库数据中，数据具备本人的生命周期，数据的高频拜访具备冷热特点。比方，流水表历史数据，日志表历史数据除了在审计回查场景之外，拜访很少甚至不拜访，然而通常这部分数据都会比拟大，数据迁徙的开销会比拟高，造成数据迁徙工夫的缩短。针对该局部数据，咱们能够事后对这部分数据进行归档备份，而后采纳动态迁徙或者利用 OMS 工具全量迁徙独自迁徙。
第二，LOB 类型数据。
Oracle 数据表行 LOB 类型空间占用较大，每一批次的数据拉取大小会在原始行的根底上有显著减少。相比无 LOB 数据类型，对 OMS 端内存需要有数倍的需要，因而，优化的策略是独自对 LOB 类型的表建设新的链路，采纳较小的并发，防备 JVM OOM 的危险，同时，为了进步整体迁徙的速度，进行多链路并行迁徙。
第三，无 LOB 类型数据。
绝对于 LOB 类型数据，无 LOB 数据类型的表的迁徙，单位迁徙批次的大小较小且稳固，内存需要可控，并发度可适度加大，进步迁徙速度。所以，对该局部数据可应用较高的并发度单链路或多链路迁徙。
第四，多个大库迁徙链路通过不同 OMS 并发迁徙。
单台 OMS 能够反对多个迁徙工作，然而共享数据网络进口。鉴于大库数据的继续拉取，能够将大库的迁徙扩散至不同 OMS 节点，缩小大数据网络流量的争用。
（三）次要挑战
但最难的是针对 ProC 的适配。ProC 是 Oracle 提供的应用程序专用开发工具，利用 C 语言编写程序，在程序源代码中能够间接嵌入 SQL 语句，执行数据库操作。Pro*C 既兼容了传统 C 语言的开发模式，又提供了弱小的数据库操控能力，所以在保险行业和其余行业也有不小的用户根底。
而 Tuxedo(Transactions for Unix, Extended for Distributed Operations)作为最早的分布式事务产品，是 AT&T 在 20 世纪 80 年代推出的。传统老外围业务中，大量应用 Tuxedo 调用相干的 Pro*C 程序来做保单业务流程解决来保障跨库事务的一致性。
为了基本上解决该问题，实现利用的平滑迁徙，阿里成立我的项目攻坚团队，用 1 个月工夫，从头开发 ProC 兼容预编译程序和运行时库，2020 年国庆节前，预编译程序胜利编译了某年金业务的全副 1000 多个 ProC 程序，并正确跑通了两个典型批处理作业，通过了该公司的验收，停顿大大超出该公司预期，也因而在赛马中胜利胜出博得了该公司对 OceanBase 产品研发能力的信念。
短时间实现老外围的适配，得益于：
- 始终保持自主研发，研发人员有优良的集体能力，分明产品每一行代码的前因后果，可能疾速和高质量地新增和批改代码，真正做到了自主研发；
- 全链路买通的研发模式，Pro*C 只是外在交互模式，底层还要依赖数据库的内核能力，从 SQL 模式、优化器、服务端等做到了全链路买通，比方研发在批处理作业现场联调时发现 SQL 对 to_date 函数的 ‘J’ 参数尚未反对时，疾速反映给 SQL 模块，后端仅用一天实现了开发测试和公布；
- 麻利开发模式，攻坚小组的研发和测试大家坐到一起，每日随着我的项目停顿和变动疾速确定和调整当日的指标。突破研发和测试边界，研发一边在开发，测试同学曾经把单测和集成测试案例写好，开发侧有一点小的停顿就立刻验证测试，使得开发和测试能靠近同步实现。
（四）迁徙历程
2020 年 10 月，首个传统新外围理赔零碎顺利上线；
2021 年 3 月，实现传统老外围最小省份的迁徙上线；
2021 年 4 月，实现 13 个传统新外围的迁徙上线；
2021 年 8 月，实现传统老外围最初一个大省迁徙上线；
2021 年 9 月，实现传统老外围最初一个单体库迁徙上线。
全面体系化迁徙
该保险公司外围迁徙过程中遇到的另一个问题是如何体系化全面迁徙，尽管在 2021 年 3 月实现最小省份的迁徙，但前面还有多个老外围散布在 36 个按省市独立部署的 Oracle 中，每个省份又包含了 20 多个 schema，如果依照老的迁徙形式，每个省份都须要创立 20 多条迁徙链路，对于资源和人力都是极大的耗费，短时间也难以完成。通过剖析，工程化批量迁徙最大的问题是没有做到全流程自动化，手工操作的步骤还比拟多，为了解决该问题，产研和现场交付同学做了三件事件：
- OMS 数据迁徙工具在底层链路上从技术层面反对多 schema 合并操作，从而能够将同一个省份的二十多条链路合并到一条迁徙链路中；
- 在产品层面将数据迁徙工具的底层能力进行拆解，将原来无奈自动化的步骤做了自动化，并通过 API 的形式裸露进去，使得火线交付同学能够依据用户的理论状况像搭积木一样进行组装应用；
- 交付同学基于裸露的 API 和 140 多页的迁徙操作手册，用一个月工夫开发出简化迁徙链路配置的快捷迁徙工具。
在对快捷迁徙工具迭代了四个版本后，投入使用。须要人工干预的工作量缩小了 80%。同时一起建设了数据库迁徙施行的对立标准和规范，发展有序迁徙。上线施行规范流程包含 8 大环节，98 个步骤，5 倍峰值压测，体系化迁徙 8 大环节如下：
- 兼容性评估：明确改变范畴，进行适配革新工作量评估并合理安排工作工作；
- 负载评估：从原数据库获取 SQL 负载信息并在新数据库测试环境回放，验证新数据库利用后的性能；
- 测试迁徙、适配革新：进行适配革新、全量回归测试、性能测试。有条件的零碎（微服务化较好、重构等），能够分批革新和施行迁徙。其中，性能测试可依据迁徙前的要害业务容量基线，确定测试准出规范；
- 生产库存量、增量式迁徙：对于业务连续性要求不高的零碎，个别操作一次性存量形式实现数据迁徙；对于业务连续性要求高的零碎，采取全量 + 增量迁徙形式，待增量数据追平后施行切换，仅需在切换时点暂停业务（分钟级）；
- 反向回流：对于要害利用，可施行数据同步回原数据库应答未知危险；
- 数据验证：迁徙实现后进行数据准确性验证及利用验证；
- 继续监控：对可能遇到的问题进行监控、具体评估剖析；
- 在线压测：迁徙实现后，定期发展在线压测，基于理论生产场景进行业务全链路压力测试，继续保障利用容量和性能。
2021 年 5 月，西部某省的迁徙在 2 小时内顺利完成，验证了 Oracle 端多 schema 合并迁徙这一重要技术难点，相比之前有数倍的晋升，为残余省份的并行迁徙扫清了阻碍，通过优化后：
- 测试环境：自主进行数据迁徙和压测回放，并通过 SQL 主动优化倡议工具，大大提高了迁徙验证效率，能够自助解决 90% 以上的问题；
- 生产环境：将过程中须要人工查看费时、费劲的步骤，做到了自动化。
紧接着实现了东北三省 + 内蒙古总共四个省份的数据，过程中解决了 Oracle 源端呈现不可见控制字符脏数据的问题，确保了数据准确无误。
2021 年 8 月，历经后面 11 次的迁徙后，终于实现了最初一个、最重要省份，也是数据规模最大的的数据库迁徙。
2021 年 9 月，在解决了所有技术难题，实现了所有外围数据库的迁徙，经验了开门红大促的考验后，要实现一个保险公司一个残缺的业务周期，只剩下最初一关，就是保险精算。
保险精算是保险公司业务经营的特色，指使用数学、统计学、金融学、保险学及人口学等学科的常识与原理，去解决商业保险与各种社会保障业务中须要准确计算的我的项目。个别会在季度末和年末进行，以掂量企业的经营情况，并制订更有市场竞争力的保险产品，是保险业务发展不可或缺的要害一环。
保险精算剖析的特点在于数据量大，剖析的模型简单，过程中还有大量的数据写入，往往要继续一周甚至更长时间。并且要确保精算过程中，快照点的数据不能发生变化，基于传统 IOE 架构往往通过存储层的快照来实现。
迁徙到分布式数据库后，怎么保障在不停利用的状况下实现保险精算，是整个迁徙过程的最初一个阻碍。通过重复评估，阿里云为此制订了最佳计划，受害于 OceanBase 底层数据块的疾速物理备份和表级的恢复能力。通过近 1 个月的压测验证，集群复原速度达到 800MB/S，齐全满足精算的备份复原的工夫要求。最终在 2021 年 9 月 30 日在规定的工夫窗口实现了数据的备份并导入到了精算库，无效撑持了全面迁徙后的保险精算业务，解决掉了最初遗留的小尾巴。
次要问题总结
当然迁徙过程并不是齐全一帆风顺，尽管未产生重大生产事变，但过程中也出了几次故障。而这些故障背地既反映了国产数据库在面对简单场景上能力的晋升，也反映了分布式架构带来的根本性变动。
一、数据库连贯打满屡次触发高可用切换
互联网外围迁徙到 PolarDB 过程中遇到的最大一次问题是在 2021 年 1 月，当天凌晨面向 C 端用户的两个重要零碎实现数据迁徙和利用的割接。随同着日间业务流量逐步减少，两零碎因为大量的慢查问沉积较多利用连贯，将数据库服务梗塞，全天屡次触发 PolarDB 实例主动高可用切换，执行节点重建复原流程。
以云原生容器模式部署的数据库服务节点，除了受自身数据库相干的内存参数限度外，还受 cgroup 指定的 CPU 和内存限度。过后连接池打满后，因为内存超出限度，引起实例的屡次高可用切换重建。云原生数据库基于容器部署须要在稳定性和自保能力方面做诸多加强，为了解决相干问题，后续的版本中减少了 global plan cache、resource manager、并行日志回放、global index 等性能，数据库的内核参数也针对金融场景逐个做了定制化优化。
针对金融场景对稳定性要求极高的需要，通过本次互联网外围迁徙也减少了诸多管控运维能力：
- 减少 AWR 性能，定期收集 AWR 报告对性能和可用性进行剖析；
- 减少 GAWR 性能，对主机、Dockers、RW/RO 进行全量数据采集；
- 新增 online promote 性能，优化在线切换，进一步缩短切换工夫；
- 减少 Idle 状态 Session 超时主动断开连接性能，缩小后盾过程数，及时开释回收 Idle Session 的内存资源；
- 优化元信息缓存性能，Session 级别元信息缓存优化为全局元信息缓存，升高后盾过程的内存应用。减少内存总量资源管理管制，设置肯定的阈值，达到阈值后开始 Cancel Query、Kill Idle Session、Kill Active Session、回绝新用户 Session 连贯，加强数据库的自保能力。
二、SAN 交换机故障导致数据库进入无主状态
因为原有 Oracle 数据库都是基于 SAN 存储部署，在 2020 年 9 月份启动数据库迁徙工作之时，针对 OceanBase 部署倡议的本地 SSD 盘硬件还没有洽购到位。为了疾速启动相干的迁徙工作，最开始 OceanBase 传统新外围集群还是部署在 SAN 存储上，这也为第一个生产问题埋下了隐患。
第一个传统新外围利用理赔上线后，零碎运行比拟安稳。意外呈现在某天下午 14 点 7 分，零碎同时收到了利用监控和数据库监控的告警。监控显示，利用呈现了 90 秒的阻塞迭停。然而，当单方团队还在排查问题时，数据库曾经主动实现了复原。
通过深入分析，发现是 SAN 存储交换机到外围交换机连贯的一个端口呈现了故障。尽管配置了多路径转发，但因为操作系统内核的超时工夫 OceanBase 切主工夫不匹配，触发了 OceanBase 的主动选主操作。而选主过程中，另外一台物理机也走的同样端口也呈现了 IO 阻塞的问题，最终导致 OceanBase 进入无主状态，当多路径软件胜利切换后，OceanBase 未通过任何干涉就实现了主动复原。实质上是因为软件超时参数与硬件超时参数不匹配所导致，也是软硬件零碎磨合不够充沛的体现，通过相干参数的调整能缩小 RTO 的工夫。
在此次故障之前，大家对 OceanBase 的理解都停留在 PPT 层面：RPO=0、RTO<30 秒。直到这次故障才真切地感触到，故障时的疾速切换和主动恢复能力是如许的重要。然而故障产生，项目组外部也有质疑声音进去：“OceanBase 基于 SAN 存储的部署原本就是错的，咱们就不该应用 OceanBase。”但通过深刻的剖析才发现并不是 OceanBase 的问题，也不是 SAN 存储的问题，而是有没有充沛的磨合，软硬件相干的参数是不是最合适的。
IOE 架构之所以成为集中式架构下的最佳组合，正是通过宽泛的实际和各种场景的锻炼，让软硬件都能在一个最佳的状态下提供服务。最终通过这次事件之后，大家统一认识，调整参数并不能根本性解决问题。原来部署在 SAN 存储上的 OceanBase 迁徙到了本地盘硬件设施上，随后也逐步演进到两地三核心多活部署架构。
三、执行打算跳变导致业务卡顿
如果一个数据库厂商说 100% 兼容 Oracle，保障迁徙过程不出任何问题，那肯定是自吹。即使做到了事先压测充沛，且尽量笼罩完所有业务场景。但对于割接上线后的零碎稳定性、兼容性还是要画问号。关键在于是否有及时无效的监控，以及呈现问题后的疾速应急伎俩。毕竟曾经投产的利用，应急还是第一优先级。
在 11 月份某个周末，理赔零碎呈现慢 SQL，导致理赔利用零碎票据汇总操作卡顿超时。为什么零碎曾经稳固运行了半个多月，没有任何的业务变更，反而在周末业务低峰期呈现问题？现场交付专家通过剖析很快定位到起因，OceanBase 的执行打算产生了跳变，导致执行打算走错。
通过深入分析，OceanBase 和其余数据库一样，通过应用执行打算缓存 (Plan Cache)，对于雷同的 SQL（参数不同），跳过解析阶段，防止从新生成执行打算，以晋升 SQL 的性能。然而理论场景中传入的参数往往是不同的，就像淘宝双 11 有热点库存，在保险行业也有大小机构号。尽管 SQL 看起来一样，但因为传入的参数不同，优化的伎俩和执行的门路也不一样。
Oracle 数据库为了抉择最优的执行打算，会定期进行数据对象统计信息的收集（如每天夜间的保护窗口（maintenance window）），淘汰旧的执行打算，使新的执行打算可能依照理论的数据统计信息生成更精确更优的执行打算。OceanBase 采纳相似的办法，但因为 OceanBase 每天进行数据解冻合并，增量数据落盘，数据库对象的理论数据信息（行，列，平均值等）会产生较大的变动。因而合并当前，打算缓存会进行清理，并依据第一次传入的参数生成执行打算进行缓存，默认状况下，只会保留一个执行打算。因为周末过后第一次传入的参数不具备广泛代表性，导致后续执行打算走错，产生了性能问题。
执行打算跳变是一个比拟常见的数据库性能景象，Oracle 先后推出了 Cursor Sharing，Outline，Bind peeking，ACS，SPM 等伎俩来优化改良，然而生产上也无奈彻底躲避执行打算走错的问题，新的数据库产品从 Oracle 99% 到 100% 的兼容优化也是最难的，也不是短时间能欲速不达。对于这种小概率事件，应急就成为了最初的兜底伎俩，在不动利用的大前提下，通过数据库灵便的绑定执行打算，是呈现突发问题时比拟无效和容易落地的伎俩。理论整个迁徙过程中，对于偶发的执行打算跳变，项目组也曾经轻车熟路，没有给迁徙带来意外影响。
整体成果
历时一年，近 100 个业务零碎全面实现国产数据库降级，成为首家实现 100% 外围业务零碎国产数据库降级的大型金融企业，数据库 OceanBase 和 PolarDB 用量占比超过 97%。
通过数据库的全面替换，实现了对数据资产的的全面平安保障能力，做到了：
- 100% 数据库技术栈的平安可控，解脱对 Oracle 数据库的依赖；
- 解脱对小型机和高端存储的依赖；
- 促成云原生和分布式数据库利用成熟，从可用到好用并获得性能晋升；
- 数据库服务集中管控，显著升高硬件及整体运维老本；
- 真正的实时扩缩容和高可用能力，轻松应答大促流动。
从齐全关闭的体系架构到逐渐凋谢再到全面凋谢，真正实现了对数据库核心技术的自主掌控。得益于云原生架构和分布式架构的弹性和资源池化能力，也自此能实现“一库多芯”，只需一条命令就能够把租户切换到海光服务器节点，实现了国产硬件的平滑替换。
迁徙后因为分布式数据库提供的高效压缩能力，存储容量的大小只有原来的 1/3，加上高端小型机迁徙到国产机架式服务器，设施投入节俭近 2 亿元。
数据库服务器及存储机柜数量利用率进步了 300%。设施功率降落至原有 1/3。经测算，全年可节约电力约近千万度，为该公司数字化转型提供了源源不断的绿色动能，无力践行了国家双碳策略，缩小公司因为自建数据中心带来的碳排放增量。
结 语
明天国内大部分金融机构的外围业务依然运行在国外的数据库上，这是一个咱们无奈回避的事实，数据库的替换不仅是一个产品的替换，替换的目标不单纯为了“国产”两个字，更重要的是：技术必须提高；替换后的新零碎必须具备老零碎和国外产品不具备的能力，不仅是性能和稳固，更多是对业务的麻利撑持能力，和面对海量业务和不确定性的业务顶峰时刻的解决能力，以及更上一层楼的金融级高可用能力。
这些年咱们看过很多的文章都是对于数据库替换的剖析和畅想，然而面对理论的大规模简单的外围利用零碎的技术平台替换，过程中还有很多在各种“剖析”文章中想不到的问题，尤其对于现有运行的环境的各种适配和兼容，对利用的敌对性等很多，对于这些，阿里走出了松软的一步，积攒了弥足珍贵的教训，这些都为今后的国产过程给出了很好的示范效应。
对于作者
刘伟光
阿里巴巴团体副总裁、阿里云智能新金融 & 互联网事业部总经理。退出阿里云之前，在蚂蚁金服负责金融科技的商业推广和生态建设工作以及蚂蚁区块链的商业拓展工作；他在企业软件市场深耕多年，已经创立 Pivotal 软件大中华区分公司，创始了企业级大数据以及企业级云计算 PaaS 平台的市场先河。