深圳农商银行基于OceanBase的两地三中心落地及生产容灾切换实践
深圳农商银行基于分布式数据库推进IT架构升级转型和信息技术应用创新产业建设，具备高可用、易迁移、低成本等特性，截至目前，深圳农商银行在分布式数据库共投产了 30 多个生产业务系统，最早上线的业务已平稳运行 2 年，期间完成多次计划性同城、异地切换演练验证，有效提升了信息系统整体灾备保护能力。
2023 年 9 月，深圳因台风“海葵”出现了超历史极值的罕见强降水，部分系统可用性受到影响，深圳农商银行主动进行了信息系统整体异地灾备切换，其中 OceanBase 数据库顺利完成了异地 switchover 无损切换，支撑业务在异地成功运行，有效应对了本次危机，保障了业务连续性与数据一致性，为客户数据安全和金融服务能力提供了有力的技术支撑。
（一）当前部署架构
当前，我行 OceanBase 数据库基于“两地三中心+仲裁站点”的环境部署如图所示。
分布式数据库部署架构图
-
主集群：同城双机房和仲裁站点形成“2+2+1”五副本部署；
-
备集群：异地同机房“1+1+1”三副本部署；备集群异步拉取主集群的物理日志，同时，开启日志压缩以节约异地带宽；
在上述部署架构下，数据库灾备能力可达到如下级别：
-
机房内单节点故障RPO=0，RTO<30S，机房内切换；
-
同城机房级别RPO=0，RTO<30S；
-
异地(failover) RPO>0，RTO 分钟级；
-
异地(switchover) RPO=0，RTO 分钟级；
在此基础上，我行多次进行机房级和城市级故障切换演练，以及物理备份异地恢复演练，让数据库的“高可用”能力真正转换为“灾难发生时能够有效切换”的能力。
（二）上线业务系统情况
从业务类型划分，我行在 OceanBase 已投产运行的系统主要包括三类。
第一，对业务连续性要求高的重要系统：银行卡前置系统、企业级服务总线等。
第二，面向互联网用户的交易&支付类系统：电信/移动/联通电话缴费系统、综合理财投资系统、银联订单支付系统、收钱宝系统等。
第三，行内运营管理业务：客户关系管理系统、电销系统等。
对于上述各类系统，根据其重要程度、性能负载、数据量等因素，划分到不同集群，以多租户能力，有效利用集群中各个节点的计算资源，高效支撑业务迭代。
从实施路线划分，我行投产分布式数据库主要有国外数据库平迁、主机下移、系统重构以及新建业务四种。
（一）针对不同类型系统投产的注意事项
1.国外数据库平迁
-
首先应评估改造难度，确认是否可行：若不兼容点可被替换或风险较低，则可开始投入适配测试；若不兼容点改造风险较高，如某个跑批过程中依赖的DBMS包不支持，则需要重点评估数据库厂商的排期情况，以及应用开发自行实现的把握情况，在没有明确可行的方案前，不建议尝试。如果该系统的对象和SQL均无高风险的不兼容点，可启动适配。
-
其次应评估已存在的慢SQL，摸清下限：对于原本在国外数据库就存在的慢SQL，应重点关注，在同等规格的数据库环境中，可能有部分SQL会出现进一步的性能劣化，此时应具体情况具体分析，评估是执行计划问题还是算子性能问题，并积累到内部知识库，将调优过程定期同步。
经过上述两项评估，能够大体确认系统是否适合平迁，接下来需要结合国外数据库当前的资源、数据量、未来增长情况、部署架构，确认 OceanBase 相应的租户配置，包括是否使用分布式、是否更换字符集、是否启用读写分离等，并开始正式的性能压测和割接演练，最终保障业务不带风险投产。
若因历史迭代原因，系统存在大量复杂 SQL，数据库已是不堪重负的状态，这种情况更建议走“重构”路线，做系统性优化改造。
2.重构系统
重构类系统，多数情况下伴随性能优化、逻辑简化等非功能方面的改造，通常涉及表架构的变化，而变化的目的可能是希望消除多表关联开销或消除行列转化开销，以我行的使用经验，使用 OceanBase 做复杂系统重构时，可充分利用其存储引擎的编码能力处理冗余列，对重复数据自动完成高效压缩，避免业务侧过度关注存储空间的浪费问题，专注于业务性能优化。
在此问题上，也需要注意表字段不宜过多，否则也会面临查询整行开销过大的问题，待 OceanBase 支持列存后，将能够更好地处理大宽表数据。
3.主机下移
主机下移涉及数据库语法改造，需要应用开发团队介入做版本改造，对于下移后的语法选择，可根据行内的运维使用习惯以及开发团队适配经验进行选择。
4.新建系统
新建系统的关键评估因素是数据库的适配以及同业的投产情况，通常开发团队会根据实际情况进行推荐。
（二）分布式数据库技术支持体系完善实践
为保障上述各类系统的平稳落地，我行与 OceanBase 及其他厂商一起制定了技术服务和运维规范：
1.充分利用 OceanBase 官网，将官网的工单系统、产品文档、版本发布文档作为数据库技术支持的重要渠道；
2.定期同步新版本《OceanBase 开发规约》给运维、开发团队，必要时进行讲解；
3.积极申请培训资源，对行内 DBA 和开发人员（特别是重点项目开发人员）进行培训；
4.重要业务重点沟通，开发人员需提前了解如何用好分布式数据库，明确分布式数据库和相关组件的能力边界，对高并发联机交易、海量历史库在线查询、数据同步、大数据量清算等复杂场景形成开发侧的共识；
5.定期对各个集群环境进行巡检查并出具报告，重点包括 topsql、slowsql、集群状态等；针对典型问题出具排查手册，例如：如何排查典型高消耗 SQL（无索引、全表扫），使开发人员能够自主通过 OCP 进行问题初步分析；
6.灾备切换演练：通过调用数据库管理平台的标准 API 实现一键切换，并定期进行切换演练；
7.整理总结同步工具的使用注意事项与能力边界建议反馈给相关厂商；
8.整理总结物理备份恢复的注意事项反馈给相关厂商。
（一）容灾能力提升
基于原生分布式数据库，构建两地三中心的分布式数据库底座，保证同城具备机房级别RPO=0，RTO<30S；异地(failover) RPO>0，RTO分钟级；异地(switchover) RPO=0，RTO 分钟级。强大的容灾能力，在 9 月深圳暴雨的极端场景处置中发挥了重要作用，其先进性得到了充分体现。
（二）高效支撑业务完成信息技术应用创新产业改造
凭借数据库较成熟的兼容性和配套工具，投入较少人力即可完成异构数据库跨平台迁移，凭借数据库对业务屏蔽分布式特性的复杂度，支撑业务快速迭代上线。
（三）节约硬件投入成本，提升资源利用率
使用分布式数据库后，数据的副本数增多，但 OceanBase 各节点均具备承载业务的能力，同时多租户和数据压缩有效抵消了高冗余带来的硬件资源增加，使整体硬件投入仍在合理范围。
除此之外，多租户模式将数据库资源的使用方式云化，在保持业务稳定运行的前提下，允许动态进行资源增减。以银行卡前置系统为例，相比迁移前，其存储空间下降了 70%，同时交易响应耗时减少了 10%，达到降本增效的效果。
（四）深度对接，自主运维
得益于运维自动化的建设，和平时有效的切换演练，运维团队实现了行内统一切换平台与 OCP（OceanBase 云管理平台）的 API 对接，形成了标准化的一键切换，在面临业内极为罕见的全实战切换危机时，成功在 1 分钟内完成了数据库的Switchover 无损切换，并支撑业务在异地成功运行。
（五）突破挑战场景，推动生态共建
复杂应用落地方面，在客户关系管理系统中，推动系统开发团队与数据库厂商进行深度适配；数据库语言生态方面，在银行卡前置系统中，推动数据库厂商进行更深入的 C 语言类型适配；数据管理生态方面，推动存储厂商、数据同步厂商与数据库厂商进行备份恢复/数据同步的对接适配。在分布式数据库的落地过程中，整合多方资源，共同支撑业务发展，同时也为 OceanBase 数据库的生态建设起到积极的推动作用。