达梦数据库容灾切换演练：九步清单与 RTO 实测指南
【摘要】 达梦容灾建设完成后，复制链路正常≠容灾可用。本文提供九步切换演练流程，涵盖停写、增量追平、数据一致性校验、对象检查、应用切换与反向复制。通过NineData的数据复制与对比能力，将容灾从文档转化为可验证、可审计的业务连续性能力，确保切换真正可靠。
达梦数据库容灾建设完成后，最危险的误区是认为“复制任务在运行，容灾就一定可用”。
复制链路正常、延迟很低，只能证明数据正在持续传输；它不能直接证明历史全量数据、增量变更、表结构和异常恢复后的数据完全一致。真正可用于容灾切换的依据，应该是一组可查看、可追溯、可复核的数据一致性证据。
NineData 支持达梦到达梦的数据复制、同步延迟观测、数据一致性对比、任务监控、异常告警和差异修复支撑。通过定期演练，团队可以将“同步是否正常”的判断，升级为“数据是否可验证一致、业务是否可恢复”的持续治理机制。
RTO 和 RPO：演练前先明确要证明什么
容灾演练不能只写“切换成功”，而应明确两项指标：
-
RPO：允许丢失多少时间范围内的数据，通常由复制延迟衡量。
-
RTO：从宣布故障或开始切换，到核心业务恢复可用所用的时间。
对于达梦容灾场景，RTO 不仅包含数据库切换，还包括停止旧生产端写入、等待增量追平、校验关键数据、处理 Sequence、Trigger 和权限、切换应用连接、刷新连接池、验证核心业务以及记录实际恢复时间。
NineData 的复制状态、同步延迟、数据对比结果和执行日志，可作为 RPO 与 RTO 实测过程中的关键证据。
达梦原生高可用与 NineData 的关系
DMDataWatch、DMDSC、DMMPP 等达梦原生组件，主要解决数据库高可用、主备切换、集群运行和本地架构可靠性建设。
NineData 的数据复制与一致性对比能力，更适合作为跨地域、跨环境、跨云或多数据中心场景下的数据流动与一致性验证补充。两者可组合使用：
-
达梦原生能力负责数据库可用性和故障切换；
-
NineData 负责结构、全量和增量数据复制，以及同步后的数据一致性校验；
-
同步延迟、对比结果和修复记录可作为容灾演练与业务切换的证据。
演练窗口如何规划？
不同团队不应套用固定分钟数。复制追平时间取决于当前延迟、业务写入量、日志积压、网络带宽和目标端写入能力；数据对比时间取决于表数量、数据量、对比范围和对比 RPS；应用切换时间则取决于连接池、DNS TTL、发布方式和服务架构。
首次演练建议预留充足窗口，并记录每个步骤的实际耗时。后续可基于实测数据建立更可靠的 RTO 基线。
| 阶段 | 主要影响因素 | 建议 |
| 停止旧端写入 | 应用架构、消息消费、定时任务 | 提前演练停写与恢复操作 |
| 增量追平 | 当前延迟、写入量、日志积压、网络与目标端性能 | 切换前提前观察延迟趋势 |
| 数据对比 | 数据量、关键表范围、RPS、源目标库负载 | 大范围对比安排在低峰期 |
| 应用切换 | DNS、连接池、服务发现、发布方式 | 与应用架构负责人提前预演 |
| 业务验收 | 核心链路数量、测试脚本、业务负责人响应 | 准备自动化验证脚本 |
第一步：定义演练范围与验收标准
先明确本次演练验证什么，而不是一开始就执行切换。
至少需要确定：
-
演练对象：达梦实例、Schema、关键表和业务模块；
-
演练类型：计划切换、故障模拟、断网恢复或回切演练；
-
RPO 目标：允许的最大同步延迟；
-
RTO 目标：核心业务恢复的时间上限；
-
验收标准：哪些核心接口、订单、交易或报表必须验证；
-
回退条件：哪些异常出现后必须停止切换并恢复原生产端。
建议将核心交易表、账户表、订单表、配置表和基础数据表划入首批校验范围，而不是只检查行数最多的表。
第二步：确认职责、窗口与通信机制
容灾切换不是 DBA 单独完成的操作，需要提前明确协作边界。
| 角色 | 主要职责 |
| DBA | 复制追平确认、数据对比、对象检查、切换与回切执行 |
| 应用运维 | 停止或切换应用流量、刷新连接池、验证应用连接 |
| 网络团队 | DNS、负载均衡、访问控制和跨地域网络确认 |
| 业务负责人 | 确认业务窗口、验收核心交易和签署演练结论 |
| 安全或权限负责人 | 确认容灾端账号、角色、权限与访问策略 |
演练开始前应建立统一沟通群、时间线记录表和升级路径。每个关键动作必须有执行人、确认人和完成时间。
第三步：检查 NineData 复制链路与日志基线
切换前，先确认 NineData 复制任务处于健康状态：
-
数据源连接、网络和账号权限正常；
-
结构、全量和增量复制任务运行正常；
-
达梦源端归档日志或增量日志读取配置满足要求；
-
日志保留窗口能够覆盖故障恢复和追平所需时间；
-
复制延迟满足 RPO 要求；
-
关键表不存在未处理的同步异常；
-
告警接收人、阈值和升级路径已配置；
-
源端和目标端容量、写入性能和网络带宽满足演练要求。
NineData 可在任务页面查看同步延迟、执行日志、增量线程状态和监控指标。若延迟持续扩大、日志积压或目标端写入响应异常，应先排障，不应带着隐患进入切换窗口。
第四步：停止旧生产端写入
正式演练开始后，先控制旧生产端写入。
常见方式包括：
-
应用进入维护模式；
-
暂停消息消费和异步写入；
-
将旧生产端应用账号调整为只读或限制写入；
-
通过负载均衡、网关或访问控制阻断新的写请求；
-
停止定时任务、批处理和外部同步任务。
这一阶段的目标是确保旧生产端不再产生新的独立业务写入，让增量复制有机会追平。
第五步：确认增量追平并执行一致性校验
停止旧生产端写入后，等待 NineData 增量复制任务追平。
演练记录中应包含：
-
停写时间；
-
增量任务追平时间；
-
切换前最后同步延迟；
-
关键表数据对比开始与结束时间；
-
数据对比结果；
-
差异处理记录。
NineData 支持在复制任务中开启数据一致性对比。对于包含增量复制的任务，可在增量数据首次与源端一致且同步延迟为
0 秒 后启动对比。建议至少完成：
-
核心业务表的数据对比；
-
关键 Schema 的结构对比；
-
关键金额、状态、主键和关联关系校验；
-
重要基础数据与配置数据校验；
-
增量窗口内新增、更新、删除数据抽查。
对大表和高并发表，可按分区、时间窗口、关键字段或业务范围分批校验，并观察源端和目标端 CPU、IO 与网络负载。
第六步：检查 Sequence、Trigger、权限与外部依赖
数据复制完成，不代表容灾端已经具备生产写入条件。
切换前应确认：
-
Sequence：目标端下一个取值高于生产端已使用的安全范围，避免主键冲突；
-
Trigger：避免同步 DML 重复触发审计、汇总、通知或外部调用；
-
用户与权限：应用账号、角色、对象权限和表空间配额满足生产运行；
-
存储过程和作业任务：不存在遗漏、禁用或错误的定时任务；
-
外部连接：应用配置、数据库白名单、中间件和网络策略已切换；
-
监控与告警：容灾端数据库、复制和业务告警已经生效。
建议将上述内容固化为对象清单，每次演练逐项确认，而不是依赖个人经验。
第七步：切换应用访问入口并启动业务
完成数据和对象验证后，切换应用至容灾端。
数据库访问入口可能通过连接串、DNS、负载均衡、Kubernetes Service、服务发现、数据库代理或云厂商代理切换。具体方案应由应用架构负责人在演练前确认，并在测试环境完成预演。
常见动作包括：
-
更新数据库连接地址或服务发现配置；
-
切换 DNS、负载均衡或网关路由；
-
刷新应用连接池；
-
启动应用写入能力；
-
启动消息消费、批任务和外部接口；
-
启用容灾端必要的 Trigger 与作业任务。
切换完成后，应立即验证应用连接、核心读写接口、事务处理、异常处理及外围系统状态。
第八步：实测 RTO，并记录演练证据
RTO 不应凭感觉判断，而应按时间线计算：
RTO = 核心业务恢复可用时间 - 演练开始或故障确认时间
建议记录四个时间点：
| 时间点 | 含义 |
| T0 | 宣布故障或开始切换演练 |
| T1 | 停止旧生产端写入 |
| T2 | 增量复制追平，关键数据对比通过 |
| T3 | 应用完成容灾端切换，核心业务验证通过 |
其中，
T3 - T0 是本次实测 RTO；T2 - T1 可反映复制追平和数据验证所需时间。同步延迟、对比结果、任务日志、应用监控和业务验收记录，应一并归档，形成容灾演练证据。
第九步：建立反向复制并准备回切
容灾端承接业务写入后，它已成为新的生产端。此时需要为未来回切建立数据基础。
建议执行：
-
确认旧生产端不再存在独立写入；
-
明确当前容灾端为权威数据源；
-
建立“容灾端 -> 原生产端”的反向复制；
-
完成反向复制的预检查、初始化与数据校验；
-
记录回切所需恢复的 Sequence、Trigger、权限和应用配置。
需要明确：建立反向复制不等于完成回切。
回切是一次独立的生产切换，应在反向复制追平、数据对比通过、对象检查完成后，按照同样的九步流程重新执行，并重新实测回切 RTO。
演练异常处理速查表
演练不应只准备成功路径。发生异常时，先暂停后续步骤，评估是否满足回退条件，再由对应责任人处理。
| 异常场景 | 建议处理方式 |
| 数据对比不一致 | 确认权威数据源，查看差异详情；必要时生成修复 SQL，经 SQL 审核和审批后修复，再重新对比 |
| 复制延迟无法追平 | 检查源端日志积压、日志保留、网络带宽、目标端写入性能和任务异常；未达到 RPO 前不切换 |
| 应用切换后连接失败 | 检查连接串、端口、DNS、白名单、网络策略、数据库服务状态和连接池配置 |
| 核心业务验证失败 | 立即停止扩大流量，保留现场日志；判断是否回退，避免双端继续独立写入 |
| 回退操作超时 | 使用预先准备的回退脚本和最大回退时间阈值；必要时按既定故障等级升级处置 |
| Sequence 或 Trigger 异常 | 暂停写入，修正 Sequence 安全值或 Trigger 状态后再继续验证 |
| NineData 任务调用或告警异常 | 检查服务地址、网络连通性、访问凭证、数据源配置与任务状态；保留日志用于复盘 |
达梦切换演练检查清单
| 阶段 | 检查项 | 状态 |
| 演练前 | 演练范围、RPO、RTO 与验收标准已定义 | ☐ |
| 演练前 | 职责、窗口、通信机制和回退条件已确认 | ☐ |
| 演练前 | NineData 复制链路、日志基线和告警正常 | ☐ |
| 切换中 | 旧生产端写入已停止 | ☐ |
| 切换中 | 增量复制已追平，关键数据对比通过 | ☐ |
| 切换中 | Sequence、Trigger、权限与外部依赖检查完成 | ☐ |
| 切换后 | 应用访问入口已切换，连接池已刷新 | ☐ |
| 切换后 | 核心业务读写和异常处理验证通过 | ☐ |
| 切换后 | RTO 已记录，证据材料已归档 | ☐ |
| 回切准备 | 反向复制已建立，数据校验计划已确认 | ☐ |
总结
达梦容灾切换的关键，不是“把备用库拉起来”，而是在有限时间内证明数据可信、对象完整、应用可用，并为后续回切保留基础。
NineData 支持达梦到达梦的数据复制、同步延迟观测、数据一致性对比、任务监控、异常告警和差异修复支撑。通过“复制追平、数据对比、对象检查、应用切换、RTO 实测、反向复制”九步流程，团队可以将容灾从静态方案文档，转化为可执行、可验证、可审计的业务连续性能力。
建议先在隔离或测试环境完成 PoC，验证复制追平、数据对比、应用切换与回切流程，再进入正式容灾演练。
【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）