核心数据库是业务系统的中枢。它一旦停摆，下游的订单、结算、报表会同时失去数据来源 —— 这类系统的保护目标不只是「数据别丢」，还包括「业务别停」。本方案以实时数据复制为主线，把数据库文件与事务变化持续同步到灾备端，让生产端出现故障时业务可以由灾备端承接。

一、方案概述

二、需求与挑战

在数据备份与容灾建设中，以下几类问题出现频率最高：

• 数据库是业务中枢，一旦中断，下游的订单、结算与报表环节会同时停摆
• 定时备份只能把数据恢复到上一个备份点，覆盖不了备份间隔内产生的交易
• 主备切换依赖人工判断与手工操作，切换过程长，且容易在过程中出现数据不一致
• 不同品牌、不同架构的数据库容灾手段差异大，多套体系并存会显著推高运维负担
• 跨数据中心的带宽成本与传输延时，是远距离容灾能否长期稳定运行的关键约束

三、方案架构与能力构成

方案按职责分层组织，各层之间通过标准接口衔接，便于按需组合与扩展。

实时数据复制与故障自动切换示意

四、核心能力

实时数据复制

以数据块与事务为单位连续捕获生产端变化，把数据库文件实时传输到灾备端，保持两端数据一致；生产服务器出现故障时，可以把生产应用动态切换到灾备端，业务的连续性得以保持。

日志级数据库复制

面向集群数据库采用基于 redo 日志分析的实时复制方式，通过 SCN 机制把数据从源端完整同步到目标端；复制可以细粒度到用户或表级别，只传递交易指令，传输的数据量极小，在低带宽链路上也能实现低延时的数据异步复制。

应用级高可用

方案关注的不只是数据文件，还包括数据库服务本身。生产端不可用时由灾备端接管数据库实例，把不可用时间压缩到可控范围内，避免「数据在、业务起不来」的尴尬局面。

一致性可核验

灾备端数据可以在线查看，并按周期比对生产端与灾备端的数据一致性，把「备份到底能不能用」从主观判断变成可核验的结果。

全图形化运维

数据复制的过程、状态与进度以图形化方式呈现，配置与切换操作都在控制台完成，降低日常运维对数据库专精人力的依赖。

五、产品与技术构成

方案所采用的产品与技术构成如下，可按业务规模与保护等级组合选用。

基于 redo 日志与 SCN 机制的数据库级复制流程

六、方案优势一览

七、典型应用场景

• 金融交易、资金清算等对数据一致性要求高、可中断窗口极小的核心账务系统
• 医疗 HIS、LIS 等需要 7×24 连续运行的业务系统
• 制造、能源行业的 ERP 与生产管理系统
• 政务与公共服务平台中对外提供连续服务的数据库
• 已经建成灾备机房、需要把核心数据库纳入容灾覆盖的企业

八、实施与交付

九、常见问题

数据库容灾和数据库备份是一回事吗？

不是。备份解决的是「数据丢了能不能找回来」，容灾解决的是「业务停了能不能继续用」。核心数据库一般两者都要做：备份用于应对误删与逻辑错误，容灾用于应对主机故障与机房级事故。

复制对生产数据库性能有影响吗？

复制以增量方式捕获变化并做压缩传输，对生产端资源的占用有限；实际影响与数据变更量、复制方式和网络条件有关，可在设计阶段通过测试评估。

集群数据库也能做实时复制吗？

可以。集群数据库通常采用日志分析方式实现数据库级复制，通过日志机制把事务变化同步到灾备端，避免直接复制数据文件带来的不一致风险。

切换一定是自动的吗？

视业务要求而定。对可以接受短时中断的系统，一般建议由运维人员确认后再切换，避免误判导致的非必要切换；对要求连续性的系统，可以配置自动切换并配套回切流程。

怎么确认灾备端真的能顶上去？

通过定期演练验证。方案提供在线数据核对与切换演练能力，可以在不影响生产的前提下检查灾备端是否具备承接条件。

如需针对具体业务系统做保护范围梳理、恢复目标设定与预算测算，欢迎联系东方华展：010-52850389 · 13911411199，或邮件至 hc@dfhz.com。