本文还有更多专家分享作出贡献，详见正文
（一）国产数据库使用两地三中心的的多活架构下，应用层面如何设计？是否也需要对应实现多活的应用改造？相关的改造工具是自研还是主要由厂商提供？
应用由于是无状态的，其本身的高可用较容易实现，一般借助基于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、对于集中式数据库，可以暂停灾备同步，对主库进行备份、打快照或利用数据库本身闪回等功能，测试完成后进行恢复，再进一步恢复主备同步。是否需要重新搭建备库视数据库功能和方案而定，例如主机或存储层面快照一般可恢复至初始状态，无需重搭灾备链路。
更多专家分享可点击文末阅读原文，也可到社区原文下评论交流
觉得本文有用，请转发或点击在看，让更多同行看到
资料/文章推荐：
欢迎关注社区以下 “数据库”技术主题 ，将会不断更新优质资料、文章。地址：https://www.talkwithtrend.com/Topic/597
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场
