“信创数据库一次到位”架构实践和落地难点之同行共识探讨总结

从该投票结果可以看出，在信创数据库的同城容灾方案设计方面，52%的受访者更倾向于厂商最佳实践方案。他们认为厂商凭借其专业技术和对产品深入的了解，所提供的方案在通用性、稳定性以及与产品的适配性上具有一定优势，能够在较大程度上满足多数场景下的同城容灾需求，并且可能在实施难度和成本控制方面也有较好的平衡。

而选择适合用户自身的定制化方案的比例为48%，这部分用户则更看重方案与自身业务特点、架构、规模以及特殊需求的契合度。他们意识到每个金融机构的业务模式和要求都存在差异，通用的厂商方案可能无法完全覆盖自身的特殊情况，定制化方案能够更好地应对自身独特的风险挑战，以实现更精准、高效的同城容灾保障，确保在面临故障或灾难时业务的连续性和数据的安全性能够得到最大程度的维护。

从这两个问题的投票结果来看，多数（56%、60%）受访者倾向于在迁移到信创数据库后不使用其函数、存储过程高级特性。这主要是考虑到减少迁移过程中的兼容性问题以及对系统稳定性的潜在影响，选择在应用层替换了数据库高级特性，同时降低对单一数据库产品的依赖。在当前阶段引入新的高级特性并非必要之举，他们更注重维持既有业务的稳定，以此降低迁移后的风险并减少学习成本的投入。

在信创数据库的监控手段选择上，大部分（64%）受访者倾向于将其整合到用户原有平台，这部分用户更注重监控体系与原有监控架构的协同性与连贯性。原有平台往往已集成了多种监控工具与流程，将信创数据库监控整合进来，能够利用已有的资源与经验，降低额外的建设成本与学习成本，便于统一管理与运维，使监控数据能够在熟悉的环境中进行汇总、分析与处理，有助于快速发现问题并及时响应，从而保障数据库乃至整个业务系统的稳定运行。

而选择使用数据库产品自带平台进行监控的占比36%。这部分人员可能认为数据库产品自带平台在针对自身数据库特性的监控功能上具有独特优势，能够提供更为精准、深入的数据库运行状态信息，其功能与数据库的契合度更高，能更好地挖掘数据库内部潜在的问题与风险，在一些特定场景下，可能更有利于对数据库进行精细化管理与性能优化，从而提升数据库的运行质量与可靠性。

从这一投票结果可知，绝大多数（92%）的受访者认为信创数据库产品同城机房的强同步技术有必要具备 “网络抖动” 探测能力并在网络抖动时实现自动降级。在金融业务场景中，数据的完整性、一致性以及业务的连续性至关重要。网络抖动可能会对同城机房强同步过程中的数据传输造成干扰，导致数据同步延迟、错误甚至中断等问题。具备 “网络抖动” 探测能力并能自动降级，可有效应对此类突发情况，保障数据在不稳定网络环境下依然能够以相对合理的方式进行同步，最大程度降低因网络波动对业务的负面影响，维持金融业务系统的稳定运行，减少因数据同步异常而引发的潜在风险与损失，这体现了金融从业人员对数据库同城机房强同步技术稳定性和可靠性的高度重视以及对可能出现的网络风险的防范意识。

从该投票结果来看，大部分（76%）受访者倾向于在信创数据库集群间的同步基于数据库层的复制。这表明多数人认为数据库层的复制在技术成熟时具备明显优势。数据库层的复制往往能与数据库自身的功能和特性紧密结合，可针对数据库的逻辑结构、事务处理等进行精细化的同步操作，在数据一致性、完整性保障方面更具针对性和灵活性，能够更好地满足金融业务对数据准确性和可靠性的严格要求，并且在数据库的管理与配置上更便于统一规划与调控，有利于提升数据库集群整体的协同性与稳定性，使数据在不同节点间的同步更贴合金融业务的复杂逻辑与流程需求。

而选择基于存储层的复制仅占24%。这部分人可能考虑到存储层复制在某些特定存储架构下可能具有一定的性能优势，例如在处理大规模数据块的传输时可能效率较高，但相对而言，其对数据库内部逻辑和业务语义的理解与适配性不如数据库层复制，在应对金融业务复杂的数据关系和频繁的事务操作时，可能在数据一致性保障等方面面临更多挑战，不过在一些以存储资源为核心考量且数据逻辑相对简单的场景下，存储层复制仍可发挥其独特作用。

从投票结果可知，数据库性能指标和高可用性相关指标被所有受访者认为是信创数据库监控配置所必需的维度，这充分体现了在金融领域对于信创数据库运行效率与业务连续性保障的高度重视；数据库配置和运行状态指标得到92%的认可，表明大部分人意识到监控数据库的配置参数以及实时运行状态，能够帮助运维人员深入了解数据库的工作情况，及时发现配置错误、异常状态等问题，以便快速采取措施纠正，保障数据库的正常运行；系统资源指标有88%的选择率，意味着多数人认识到数据库的运行离不开系统资源的支持，通过监控这些指标可以提前预警资源不足的情况，进行合理的资源调配与优化；安全相关指标被68%的受访者看重，这反映出在金融行业数据安全的重要性。

从投票结果来看，数据库进程维度和操作系统、主机维度均获得92%的高选择比例，这表明在信创数据库的规范化应急体系建设中，这两个维度被广泛认为是极为关键的部分。数据库进程的稳定运行是数据库正常工作的核心保障，对其进行监控与应急规划，能够及时处理进程崩溃、死锁等异常情况，确保数据库业务操作的连续性。而操作系统与主机作为数据库运行的基础环境，其稳定性直接影响数据库的性能与可用性，针对这一维度构建应急场景是必不可少的，可有效降低因基础环境问题引发的数据库风险。

数据库会话维度有88%的认可度，多数人认为会话异常可能导致用户操作失败、数据不一致等问题，通过对会话维度的应急规划，如监控会话数量、会话时长、会话状态等指标，能够在会话出现异常时及时进行干预，保障用户正常使用数据库服务并维护数据的准确性。

数据中心维度得到64%的选择率。数据中心涵盖了众多的硬件设备、网络设施以及复杂的架构布局，一旦数据中心出现大规模故障，如电力中断、网络核心设备故障等，将对数据库产生全局性的影响。针对数据中心维度构建应急场景，有助于在面对此类重大事故时，能够快速切换资源、恢复服务，减少对金融业务的整体冲击与损失。

从投票结果来看，60%的受访者认为金融行业核心业务系统信创数据库需要类似RAC架构。反映出这些受访者认可该架构在金融核心业务场景中的价值。类似RAC架构的高可用性设计允许在部分节点故障时，系统仍能持续稳定运行，自动进行故障切换与负载均衡，确保金融业务的连续性，有效降低因数据库故障导致的业务中断风险，保障金融交易的顺利进行以及金融数据的完整性与安全性，维护金融市场的稳定运行秩序。

2.1 同行分享——金融行业信创数据库一次到位架构实践及难点

来自某股份制银行的孔再华老师进行了《金融行业信创数据库一次到位架构实践及难点》的分享，孔老师借大型金融机构案例，深入且系统地讲解了信创数据库容灾与应急体系构建、构建中面临的问题及解决思路。

在容灾体系构建上，标准化环境极为关键。如数据中心硬件设施，服务器型号、存储容量、网络带宽等都需按标准设定，以保障切换时的兼容性。体系建成后，流程编排和常态化切换演练必不可少。流程编排可优化各组件交互流程，明确故障检测到备用库启动等步骤顺序。常态化演练可模拟各类故障，提升实战能力。切换时，宜用自动化平台，因其可依预设规则精准快速切换，减少人工操作的不确定性与风险，如智能监控异常后自动切换备用库及调整网络路由。

应急体系的成功取决于多要素。有效的监控方案是“眼睛”，全方位监测数据库性能、状态及系统资源指标，异常时触发响应机制。标准化流程是“骨架”，规定故障发现至业务恢复各环节操作。完善的处理方案尤其是“三板斧”是核心“武器”，包括常见故障快速处理策略、备用资源调配机制和业务降级恢复策略，如数据库进程故障时先自动重启，失败则切换备用进程并深入分析修复，期间合理调配备用资源，保障核心业务并逐步恢复业务正常。

2.2 共识探讨——容灾方案如何设计，同城机房、异地机房采用什么部署方式，什么同步方式，RPO/RTO如何满足，切换方案怎么制定？

来自某金融单位的董亮老师首先进行了经验分享，董老师着重介绍了数据库替换方面的经验，随着系统建设的三代发展，其数据库产品也从最初的Oracle替换为DB2，后续又从DB2替换为开源数据库，再到当前的信创数据选型，在替换过程中总结了大量实践经验，主要分享了如下两条经验：一是规范制定方面，在第二代系统建设过程中便进行了严格规范，禁用存储过程、触发器等数据库高级特性，将业务逻辑转至业务层，仅用基本增删改查操作，借助工具自动生成相关语句，后续切换数据库时着重进行SQL兼容性修改，使得工作量相对较小；二是代码转换与测试方面，代码转换大多依靠工具自动实现，业务逻辑上层的改动不大，但切换过程中的测试工作量要超过开发工作量。

在容灾建设方面，当前已达成两地多中心的容灾布局，后续还将实现三地多中心的部署架构。在同城容灾环境下，能够进行同步操作，RPO近乎为零；而在异地容灾环境中，采用异步方式，RPO无法达到零值，鉴于业务自身的特性，更侧重于保证系统可用性，对于一致性问题借助应用系统层面手段予以弥补，现阶段主要依靠自主研发的数据同步工具来提供相关的技术支撑与保障。

【核心问题1】在两地三中心的分布式架构中，运营商网络抖动的情况较为常见。这种网络抖动极易致使同城另一中心的同步写操作出现故障，进而导致主中心进入长时间等待状态。在此情形下，如何在性能与数据强一致性之间进行权衡并达成平衡？

孔再华老师观点：可以优先考虑采用数据库日志复制的日志流模式。在这种日志流模式下，同城机房并非仅有一个备机，而是能够设置两个备机。如此一来，在数据同步与备份过程中，便能提供更多的冗余与保障，增强系统整体的稳定性与可靠性，有效降低因单个备机故障或其他突发情况导致数据丢失或业务中断的风险，进一步提升数据库运行环境应对复杂状况的能力。在同步线路方面，不依赖单一运营商线路，而是会购置多家运营商的多条线路。这样便能确保在某一条线路出现问题时，其他线路仍可维持通信。同时，还有线路隔离的问题，当线路监控发现丢包等异常情况时，需将故障线路及时切断，待人工检查确认无误后，再自动恢复线路连接。这种隔离保护机制贯穿于各个不同环节。

总结起来主要有以下两方面要点：其一，在存储链路层面，务必做好自动检测与隔离工作。其二，在数据库层面，可将存储链路的复制转换为数据库日志的复制形式。并且，对于数据同步至备机房的要求，并非强制两个节点都必须同步成功，只要任意一个节点同步成功即可。通过采取这样的方式，能够有效解决因网络抖动而引发的长时间响应问题。

【核心问题2】当前高可用软件与数据库产品并非原生关系，二者耦合度较低，这种低耦合状况容易致使数据库切换出现异常，影响整个系统的稳定性与可靠性，可能在关键时刻引发业务中断等不良后果，给高可用带来潜在风险与挑战，有何应对建议？

孔再华老师观点：我们先是对历史问题与需求进行了全面总结，随后自主设计研发了高可用软件，这样便能依据自身需求定制功能。但若是使用数据库产品自带的软件，我们唯一能做的就是向厂家提出需求，让其将我们所需的功能点添加进去，并且在测试环节要全方位覆盖这些需求点，确保不会出现问题。不过这只是基于我们自身条件所走的路径，比较特殊，仅能供大家参考借鉴。

阳文灿老师观点：我们遇到的问题和严老师较为接近，目前我们在实践和调研中也发现，各厂家在高可用切换方面的规范做法与实现路径差异较大，这给用户的高可用切换方式制定带来较大挑战。正如孔老师所说，我比较认同不能摒弃以往经验。例如在分布式数据库方面，有些厂家推荐单集群跨中心部署方式，而有些则倾向于集群间同步方式。若之前的存量数据库多采用集群间或数据库单体间同步方式，从经验与体系角度出发，继续沿用原有高可用架构体系或许更契合自身情况，有熟悉的管理经验与切换流程，降低切换操作风险。

【核心问题3】如果信创数据库需要做同城双活部署（两中心都承载对外业务），有哪些设计要点，如何避免同城节点之间的脑裂现象？

林春老师观点：同城双活部署有诸多问题需要去优化解决，首先在应用层面需进行单元化处理，虽然流量的跨机房情况难以完全避免，但应尽可能减少，以降低因机房之间网络交互可能带来的风险与性能损耗，保障业务运行的稳定性与高效性，提升整个系统在分布式架构下应对复杂网络环境与业务压力的能力。在此过程中，有一个极为关键的要点需要留意，即业务系统是否对网络时间敏感。倘若业务系统对网络时间不敏感，那么采用当前方案通常不会存在较大问题。然而，若业务系统属于网络时间敏感型，就必须针对性地开展一系列优化措施，以此确保业务系统在网络时间敏感的情境下，依然能够稳定、高效地运行，避免因网络时间因素而引发诸如数据传输延迟、业务逻辑错误或系统性能下降等不良状况，保障整个业务流程的顺畅与准确执行。在我们使用的数据库产品上，我们也设置了仲裁副本，仲裁副本只同步日志，可以节省较多的硬件资源。

胡中豪老师观点：要不要做双活，还是跟这个系统的重要程度有关系，因为做双活在硬件成本上确实会高很多。为了实现同城双活，我们在同城的两个机房配备了四条万兆光纤并加设波分设备，可见在网络建设方面投入巨大、下足功夫。此外，表组的技术也使用了，正如之前其他老师所提及的，要竭力避免分布式事务，减少跨机房事务。在应用方面我们也进行了大量优化工作，对于跨机房跨节点的事务，只要有优化的可能，都尽力予以优化处理，以此提升系统整体的稳定性、可靠性与运行效率，减少因跨机房跨节点操作可能引发的各类风险与性能问题，确保业务在复杂架构下能够平稳运行。

3.1 华为专家：GaussDB极致高可用方案分享

华为数据库高可用容灾解决方案架构师张琼老师重点分享了《GaussDB极致高可用介绍》，涵盖了高可用的挑战、GaussDB高可用关键技术、容灾方案以及基于Dorado双集群方案的详细说明。张琼老师介绍了GaussDB在金融级高可用性方面的解决方案，包括多层级冗余设计、跨区域容灾技术、全量和增量备份、PITR（Point-in-time Recovery）和闪回技术等。同时，还介绍了GaussDB的HA（High Availability）功能组件、冗余设计、集群管理与故障检测、备机接管技术、数据闪回技术、坏块预防与标记、数据恢复技术以及多层次容灾能力。此外，还详细阐述了Dorado的可靠性设计、数据高可靠保护、盘级可靠保护、同城双集群实现故障隔离、SSA高效简单共享访问协议技术以及组件解耦等关键技术。

GaussDB的备机接管采用多级流水线处理，把回放流程分多个阶段，类似工厂流水线高效协作，减少等待时间。页面级并行回放以页面为单位，借助多核能力对多页面事务同时处理，加速数据回放。通过优化调度队列，有效解决事务排队及管理低效问题，使回放性能从 70W 跃升至 150W，并且能在主机故障时让备机在秒级迅速升主，有力保障业务连续性与高可用性。

在容灾方案上，GaussDB支持单集群跨中心、同步双集群、异步流式、同步双集群+异地流式、1拖N流式等多种容灾方案，同方案在成本、性能、数据一致性以及恢复速度等方面各有侧重，企业可依据自身业务特性、数据重要性程度以及预算等因素综合考量。

3.2 金融同行数据库专家与华为专家对话探讨

某金融用户提问1：目前信创数据库产品在含有异地机房的多中心多活容灾方案上是否有部署方案或指导性意见？

华为张琼老师观点：在数据中心的业务布局与容灾考量方面，通常在单个机房业务量相对较少时会采用单元化策略。无论是基于分布式标准组还是应用拆分来实现单元化，核心思路均为将数据完全拆分，使各单元数据间尽可能无关联。例如设置单元一、单元二、单元三等，且各单元主节点可分布于不同数据中心，同城数据中心间常采用此类方式。然而，存在部分报表类查询业务，其需访问所有单元数据，虽时效性要求不高，但在同城架构下尚可处理，若将单元放置于异地则可能面临较大延迟问题。

对于同城有两个数据中心的情况，能够实现 RPO（恢复点目标）等于零的数据不丢失，但如果容灾机房仅为一个数据机房，与同城情况不对等，当同城某单元对应的异地节点故障时，该单元数据可能出现纠错等问题。理想状态是容灾中心也有两个机房，生产中心同样为两个机房，业务能干净拆分，通过异步或同步方式传输数据，且对于报表类查询，若对数据新鲜度要求不高，如查询几分钟甚至一小时之前的数据均可接受，那么这样的架构便能在一定程度上满足业务需求与容灾要求，关键在于容灾机房与生产机房的对等性以及报表类业务对数据新鲜度的要求这两个核心要点。

某金融用户提问2：核心系统当前不只是承担联机交易，夜间批量对数据库的压力还是非常大的，而且晚上的批处理都是一些大事务。GaussDB目前在典型的两地三中心部署方案中，对主备副本之间的延迟是怎么应对的？

华为张琼老师观点：在处理批量业务时，从数据库层面来看，对于同城情况，一般要求时间控制在两毫秒以内。通常会在两个数据中心设置同步备机，以此确保恢复点目标（RPO）等于零。不过，这里对网络时间有着严格要求，必须在两毫秒以内，一旦超过，将会对整个业务性能产生极大影响。而异地机房由于采用异步进行日志传输，所以网络时间即便稍大一些，对整体性能的影响也相对有限。GaussDB其日志是实时生成的，只要对表有修改操作，相应日志就会立即产生，并非等到事务提交时才一次性生成大量日志。在修改过程中，每有更改就会有日志实时同步，仅在最终提交时有单独的提交日志。即便批量操作较大导致日志量增多，也会按照实时同步的机制进行处理，不会将修改先存储在自己的线程或会话中等到批量提交时才写日志，以此表明在面对相关情况时，自身的日志处理机制不存在问题。

某金融用户提问3：在跨中心的强同步方案中，GaussDB采用存储复制替代了数据库复制，为什么会选择采用存储复制？

华为张琼老师观点：在同步设计方面存在两种常见方式，一种是基于数据库层的复制，另一种是基于存储的复制。GaussDB存储复制方式的优势在于能够实现两个集群的良好隔离，形成完全独立的两套集群体系。每个集群只需要管理自己的状态，降低了网络分区的影响。采用存储复制方案的备机群可以提供只读服务。

本次交流活动通过全面深入的探讨，在信创数据库金融领域应用的多个关键维度达成了丰富的共识与成果。从投票共识反映出行业对各类决策难点的多元思考与权衡，同行分享提供了实践经验与应对思路，共识探讨针对具体问题给出了切实可行的解决方案，厂商分享则展示了先进技术与产品方案。这些成果将为金融行业信创数据库的选型、部署、运维等工作提供极为宝贵的参考依据，有力推动金融领域数据库国产化进程的稳健发展。展望未来，随着技术的不断创新与实践经验的持续积累，信创数据库在金融行业必将迎来更加成熟、高效与广泛的应用，为金融业务的数字化转型与安全稳定运行奠定更为坚实的基础。

如有任何问题，可点击文末阅读原文，到社区原文下评论交流

觉得本文有用，请转发或点击在看，让更多同行看到