金融行业国产数据库容灾建设五大难点及解决方案

金融行业业务具有高并发性、高实时性以及数据丢失容忍度低的特点，同时，金融作为强监管行业，决定了其必须具备完善的容灾体系，以保证业务的连续性和数据的完整性。数据库作为关键性的数据存储基础设施，其重要性不言而喻。随着国产化工作进入深水区，金融行业开始更多地使用国产数据库来替代国外数据库，业务改造也涉及到了核心系统。虽然国产数据库在安全和自主可控方面具有优势，但在容灾能力上仍然存在一些亟待解决的难题。

金融行业在国产数据库容灾建设时可能会面临以下一些挑战和难点：

1、 多活架构设计

金融行业普遍使用两地三中心或更多数据中心架构，当使用分布式数据库时，应用层面如何进行相应的设计，以达到更高的可用性?

2、故障处理

当某个中心发生故障时，数据库及应用如何应对，是否会造成性能下降或其他问题?

3、 异构数据库间的数据同步

金融机构大多选择数款国产数据库，异构数据库间的批量、实时同步如何实现，会面临哪些问题，如何应对?

4、 多数据中心的运维问题

多个灾备中心会大大增加运维复杂度，当进行例行灾备切换演练时，如何保证灾备端的配置、数据的一致性?

5、证券行业全网测试问题

全网测试情况下，如何避免主中心的脏数据同步至其他中心?

近期社区“数据库自主可控”课题组进行了“金融行业重要交易类数据库国产化替代技术路线选择及两地三中心容灾方案设计探讨?”主题同行交流，本文重点整理了交流中涉及到的几个建设具体核心难点问题，梳理各位专家经验共识，希望能给数据库同行们提供相关参考。

主笔专家：董健 某保司数据库负责人

拥有十年以上的数据库领域经验，负责数据库架构设计、优化和运维管理工作，擅长各类数据库性能调优、问题排查，包括Oracle、MySQL等国外数据库及国产数据库。同时也持有DAMA证书，拥有数据治理、数据安全、数据仓库、大数据等方面的经验。

本文还有更多专家分享作出贡献，详见正文

(一)国产数据库使用两地三中心的的多活架构下，应用层面如何设计?是否也需要对应实现多活的应用改造?相关的改造工具是自研还是主要由厂商提供?

应用由于是无状态的，其本身的高可用较容易实现，一般借助基于Nginx等开源产品封装的国产负载产品实现，且功能相近、性能稳定性均能满足要求。对于数据库发生故障时主节点发生切换的情况，一般使用DNS指向新主节点IP，避免应用层修改连接信息。

应用层主要考虑的是结合数据库高可用实现方式进行架构选择，可以参考社区“某大型银行董生”老师分享：

1、如果你使用的是分布式数据库，且提供了多地多中心的数据同步功能，那么建议直接使用数据库提供的多活数据同步功能，不要自己进行应用设计。多活架构下，最难的就是数据一致性的保障，分布式数据库一般采用Raft算法实现数据的一致，其中解决了诸如选举(Leader election)、日志复制(Log replication)、安全性(Safety)等问题。这些通过外挂的应用程序，不论如何补偿或者重试都不能完美的达到与之相同的效果，甚至相近的效果都很困难，特别是在进行灾备切换的时候。

2、如果选择的是单体数据库集群，那么就需要从应用上进行改造了，首先确认能否从数据上划分，将数据划分为相互不干扰的部分，若是可以，那么只需保障每个区域的主本数据是正确的，其他使用消息同步写对等的副本区域的数据库中。

3、如果不能从数据上划分，那么需要看数据在多中心是否有强一致性的要求，要是没有则将可以采用补偿或者异步方式，保障在对等中心实现最终的数据一致性，但是在这个时候，需要确认当数据发生冲突时候，选取和舍弃的规则。

4、最不幸的是，数据要求强一致性，那么你只能全部连接一个中心的主库，然后同步到各个中心的备库，在同步中如果有失败，需要对数据以主库主本数据进行修正和修复。

(二)在使用两地三中心的分布式数据库，某中心异常时，降副本操作是自动的吗?会否导致数据重分布及性能下降?

分布式数据库均有完善的故障处置机制，以OceanBase为例，两地三中心一般采用5副本(三个Region，5个AZ)，副本间使用Paxos协议进行同步，单个Region或AZ发生故障会进行降副本操作，但仍有多数副本保持工作，并不影响整个集群的可用性。短时间的故障不会进行副本补足(数据重分布)，但超过server_permanent_offline_time参数的值(默认3600秒)时，考虑到安全性，会自动补足副本，将会导致性能下降。

TiDB数据库的机制可以参考社区“某保险单位杨光”老师分享，可移步下方链接进行查看，此处不再赘述。

其他考虑可以参考社区“某证券单位施斌”老师分享：

分布式数据库两点三中心的架构，单个中心故障，一般都能做到自动接管，但是由于减少了副本，某些数据库要求副本多数派响应的，可能会对性能有影响，具体还是要结合数据库产品和高可用架构。看你们到底是采用了集群间同步的模式，还是使用多副本模式，比如2-2-1的5副本架构。对于后者，例如同城中心异常，为满足副本多数派响应的要求，可能会要求网络距离更远的异地副本给出响应，性能会有降低。

(三)国产数据库对于异构数据的同步，是否有比较好的解决方案?

对于此问题，社区的多位专家进行了回复，如“某大型银行董生”老师所说，工具选择的顺序如下：

1、异构数据同步，首先看数据库是否提供了此功能，如果有，优选选择数据库提供的同步功能。

2、如果没有，对于主流的数据库，像DATAX、kettle等开源软件，都提供了相应的同步能力。

3、若是开源工具不能满足要求，只能根据实际情况进行开发，这个过程虽然痛苦，但是可以有针对性的解决异构数据同步过程中的一些类型转换异常等问题。

另外，“某证券单位吉工”也提到了第三方付费的数据同步软件。

批量同步实现较为简单，对于实时同步工具的选择，建议考虑如下问题：

1、支持的数据库种类

一般金融机构有5种甚至更多的数据库类型，源端+目标端的组合多达数十种，为了降低复杂性，建议选择兼容尽量多数据库种类的工具。

2、数据同步粒度

需要支持database/schema、table、字段甚至行级别同步。

3、数据初始化、数据校验等功能

需考虑大数据量的数据初始化以及数据时间点的记录，自动进行源和目标端的数据校验，避免数据不一致问题。

4、同步性能

对于日志量较大的库，性能是重要的考虑因素。相比源端解析日志的效率，目标端应用的压力更大，可适当对应用进程进行拆分以避免延迟。

5、其他细节功能

如DDL同步、大事务的处理、报错处理等。

(四)对于国产数据库而言，运维在应对日常切换演练等场景，如何保证灾备端的配置、数据的一致性?

如社区“某证券单位施斌”老师所说， 分别从数据一致性、配置一致性进行阐述：

关于数据一致性，在设计数据库高可用架构的时候，应该要确定RPO指标，业务是要求0数据丢失，还是允许秒级或者分钟级的数据延迟。不同的RPO要求，采用的高可用方案也不一样。一般来说，数据库都会提供同步和异步两种数据同步模式，同步模式数据能确保主备一致，但是对性能可能会有较大影响，在异步模式下，主备的数据一致性无法完全保障，受网络带宽，服务器压力，具体的DML操作等很多因素影响。我们可以设计一个心跳表定时执行DML操作，估算主备间的同步延迟时间。

关于数据库配置，应该是指数据库的参数管理，这个在日常运维时要做好主备库一起变更，同时也可以定期做参数文件对比，有些数据库自身也支持参数比对功能。

(五)信创改造后，两地三中心情况下，全网测试情况下，如何避免主中心的脏数据同步至其他中心?

此问题为证券业同行提出，按照“某证券单位施斌”老师所说，是指使用生产环境配合交易所做测试，测试结束后需要恢复生产数据库。这个问题的前提是证券业生产库不是7*24提供服务，有停机窗口处理测试数据。这种业务场景需求也会影响到灾备架构的设计以及后期运维，需综合考虑。

结合“某证券单位施斌”和“某证券单位吉工”两位老师的观点，总结如下：

1、数据库从生产库定期生成全网测试环境库，进行生产测试数据隔离。此方案不会影响到生产环境，最为安全，但需要额外的资源，且会增加日常运维工作量。

2、测试数据进入生产环境，且扩散至灾备环境，待测试完成后清理。这个方案风险较高，可能有测试数据残留，大数据量的DML可能带来清理时间过长、大量的日志、灾备同步延迟等多种问题。

3、对于集中式数据库，可以暂停灾备同步，对主库进行备份、打快照或利用数据库本身闪回等功能，测试完成后进行恢复，再进一步恢复主备同步。是否需要重新搭建备库视数据库功能和方案而定，例如主机或存储层面快照一般可恢复至初始状态，无需重搭灾备链路。

4、对于分布式数据库，如副本分布在多个数据中心，无法阻止测试数据扩散至灾备，可以考虑在数据中心间使用逻辑同步功能，全网测试前断开集群复制，避免脏数据写到其他中心，测试后设法恢复同步。

同行交流共识总结

在金融行业国产数据库容灾建设的探讨中，专家们普遍认为存在五大核心难点，包括多活架构设计、故障处理、异构数据库间的数据同步、多数据中心的运维问题以及全网测试中的脏数据同步问题。针对这些问题，专家们提出了一系列共识性的建议和解决方案。

在多活架构设计方面，首先需充分考虑自身业务特点以及RPO、RTO的要求。数据库只是整体架构中的一部分，需根据整体要求选择合适的部署方式，同样，应用也需要做出相应的调整。

在工具选择方面，一般建议首选数据库自带功能，当无法满足时考虑商用或开源软件，选型时需考虑多方面因素，但功能要求与国外数据库基本类似。

在运维方面，关键在于确保灾备端的配置和数据一致性，这需要通过定期的参数对比和数据同步策略来实现。对于可预期的动作，如演练、全网测试，可以积累经验，通过脚本、工具等方式实现自动化，减少人工操作造成的不确定性。

综上所述，虽然国产数据库在容灾建设上面临挑战，但通过合理的设计、工具选择和运维管理，可以有效提升容灾能力和数据安全性。专家们的经验分享为金融行业国产数据库的容灾建设提供了宝贵的参考和指导。国产数据库已度过“儿童期”，逐渐走向成熟，从能用到好用的过程中，需要大量的场景验证和经验积累，更需要各位同行的经验分享，这也是社区存在的目的和意义。