KES灾备与异地多活完整方案

KES灾备与异地多活完整方案

这篇是《电科金仓数据库从入门到精通》的第十九篇。前面其实咱们聊过高可用主备集群，也聊过国密安全、国产化适配这些事。但是呢，那些方案啊，往往仅仅只是局限在同一个机房里面，或者说在同一个城市的内部。

如果碰上机房断电了，或者火灾了，甚至是城市级别的灾害出现了。这时候本地主备集群就会整体失效，业务也就彻底跑不起来了。对于金融、省级政务、能源这些核心系统来说，监管那边的意思是明确的。你必须得具备异地灾难恢复的能力。

很多单位其实会搞混一个事。就是把“主备高可用”和“异地灾备”当成一回事了。怎么搞的呢？简单粗暴地把本地备机搬到异地去，就觉得是灾备了。网络抖动的情况他不管，数据一致性也不看，切换演练更是没有。RTO、RPO这些指标直接忽略。那真遇到灾难的时候你猜怎么着？发现灾备库的数据严重滞后，根本就没法接管业务。

这章呢，我就结合几个省级政务、城商行真实的灾备项目经验来聊。本地高可用啊，同城灾备啊，异地灾备啊，还有异地多活，这些怎么选型、怎么部署、同步策略是什么、切换怎么演练、风险点在哪，我都会讲。所有配置方案都是贴合电科金仓KES V9R1C10官方规范的。你直接拿过去，就能当灾备建设的实施方案来用。

一、📘 本章学习导读

1.1 学习目标

1. 分清高可用、同城灾备、异地灾备、异地多活这些概念到底有啥差异。能够结合你的业务去选一个合适的灾备架构
2. 深刻理解RTO、RPO这两个灾备核心指标。能看懂监管对政务金融的指标要求是怎么写的
3. 掌握电科金仓异地WAL归档灾备、DTS增量同步灾备这两种主流的实现方式
4. 学会灾备环境怎么完整部署，日常怎么做监控，数据一致性怎么去校验
5. 掌握灾难发生时完整的切换流程，回滚操作怎么搞，能够自己组织灾备演练
6. 识别异地灾备里那些高频的风险。比如网络延迟、同步滞后、数据冲突，还有演练流于形式的情况

1.2 本章重点

• 灾备核心指标RTO、RPO概念与行业指标参考
• 四种灾备架构对比与业务选型
• WAL归档异地灾备部署实战
• DTS增量同步异地灾备配置与校验
• 灾难切换完整操作步骤、灾备年度演练流程
• 真实省级政务异地灾备落地案例

二、💡 为什么一定要建设异地灾备？

很多人其实会有个疑问。本地不是已经搞了一主两备的高可用集群了吗？为什么还要费劲去建异地灾备呢？

本地主备集群，它解决的是什么问题呢？是单台服务器故障的问题。比如说某一台机器宕机了，备机自己就顶上去了。

但是，如果出现的情况是机房整体断电了呢？或者是机房着火了？光缆被挖断了？再极端一点，城市区域性灾害出现了。那整个机房就全部失效了。本地所有的主节点、备节点，会全部同时瘫痪。

金融监管、政务等保规范里面，对核心业务是有硬性要求的。也就是说，关键业务你不能把所有的东西都放在同一个机房里面。

灾备啊，不是说你在远方搭了一套数据库就完事了。灾备最可怕的情况是什么呢？不是灾难本身发生了。而是灾难真的来了，你发现灾备库根本用不了。

我见过不少项目是这样的。灾备库就常年摆在异地机房里。从来不做数据校验，也不做切换演练。等到真正出事故了，才发现灾备库长期同步都是中断的。数据差了好几天，完全没法接管业务。

灾备建设其实分四个环节。架构部署，常态化监控，一致性校验，还有定期切换演练。这四个，缺一个都不行。

三、📊 灾备两大核心指标 RTO 与 RPO

所有的灾备方案设计啊，都是围着这两个指标转的。不管你是写方案文档，还是去做项目验收，这两个指标就是评判灾备能力的标尺。

💡RTO（恢复时间目标）：灾难发生之后，业务要恢复正常运行，需要花多少时间。

举个例子：RTO=30分钟。这就代表灾难出现了，最多允许业务中断30分钟，然后就得恢复对外服务。

💡RPO（恢复点目标）：灾难发生之后，最多允许你丢失多长时间的数据。

举个例子：RPO=5分钟。这就代表极端故障的情况下，最多把最近5分钟的数据丢了，不能再多了。

行业通用参考标准

1. 普通政务非核心业务：RTO ≤4小时，RPO ≤30分钟。也就是不那么核心的业务
2. 政务核心办件、能源营销系统：RTO ≤60分钟，RPO ≤10分钟
3. 城商行、金融账务核心：RTO ≤30分钟，RPO ≤5分钟

注意一下。指标不是越小就越好的。指标要求越高的话，硬件成本、网络成本是会成倍往上涨的。你得结合业务实际的诉求去平衡一下，不要盲目去追求那种极致的指标。

四、🏗️ 四大灾备架构选型对比

4.1 本地主备高可用（单机房）

架构：就在同一个机房内部，1主N备，VIP自动做故障切换。

• RTO：秒级~30秒；RPO≈0
• 优势：成本低，切换速度也快；
• 短板：没法抵御机房级别的灾难；
• 适用：业务基础的高可用，其实不能当做灾备来用。

4.2 同城灾备（同一城市两个不同机房）

主集群在A机房，灾备节点部署在本市B机房。两个机房距离大概几十公里吧，用光纤专线打通。

• RTO：15‑60分钟；RPO 1‑5分钟
• 优势：网络延迟低，同步稳定，成本比异地要低；
• 短板：没法抵御城市级别的灾害；
• 适用：大部分省级、地市级政务核心系统。

4.3 异地灾备（跨城市，相隔几百公里以上）

生产中心在A城市，灾备中心部署在另外一座城市。通过运营商专线去传数据。电科金仓实现的方式分两类：WAL归档灾备、DTS增量同步灾备。

• RTO：30‑120分钟；RPO 5‑30分钟
• 优势：可以抵御城市整体故障了；
• 短板：公网或者专线的网络延迟高，会存在一定的数据滞后。专线建设成本也高；
• 适用：银行、省级政务、央企核心业务。

4.4 异地多活（双中心同时对外提供读写）

两个异地的机房，两套集群同时去承担业务的读写流量。

• RTO接近0，RPO≈0；
• 优势：任何一个城市出故障了，业务这边几乎是感觉不到的；
• 短板：架构极其复杂，会出现跨机房数据冲突的情况。改造成本极高；
• 适用：头部金融、超大型全国性平台。普通政务项目的话很少采用。

💡选型建议：绝大多数的政企项目，我建议优先选「本地主备高可用 + 异地灾备」这个组合方案。异地多活这个东西，不要盲目去上。

五、🔄 电科金仓两种异地灾备实现方案实战

电科金仓做异地灾备，主流其实就两套技术路线。一个是WAL归档复制灾备，另一个是DTS数据同步灾备。这两个东西原理不一样，适用的场景往往也不一样。

5.1 WAL归档异地灾备方案

原理：生产库这边呢，会一直生成WAL预写日志。然后通过专线，把这些日志传到异地灾备机房去。灾备节点拿到日志后，就一直在那里重放。通过这种方式来实现数据同步。

优点：数据一致性高，原生内核实现的，不去解析SQL；
缺点：灾备节点只能只读，不能写。网络中断的话会堆积WAL文件，等网络恢复了它再自动追平。

5.1.1 生产库配置（本地主库）

修改生产库的kingbase.conf

wal_level = replica archive_mode = on # 将WAL归档同步到异地灾备服务器，也可以rsync推送至异地共享存储 archive_command = 'rsync -z %p kingbase@异地IP:/data/kes_archive/%f' max_wal_senders = 10 wal_keep_segments = 1024

⚠️ 需要打通生产到灾备机器ssh免密登录，保证rsync可以自动推送日志文件。

5.1.2 异地灾备库配置

灾备节点先用生产库的全量物理备份去做初始化。然后生成recovery.conf

standby_mode = on restore_command = 'cp /data/kes_archive/%f %p'

启动灾备实例，它就会持续重放WAL日志了。灾备库会一直保持只读状态。

5.1.3 监控重点

1. 监控WAL归档推送是不是在持续产生新文件；
2. 监控灾备库重放的日志位点，去算一下数据滞后时间；
3. 专线网络一中断就得告警，防止日志一直堆积，长期不同步。

查询灾备滞后程度的SQL：

SELECTnow()-pg_last_xact_replay_timestamp()ASreplica_lag;

5.2 DTS增量同步灾备方案

原理：用到的工具是电科金仓的DTS迁移工具。它去抓生产库的增量变更，把变更日志解析完，再同步写进异地灾备库里面去。

优点：灾备库是可以读写的，支持异构，源库甚至可以是Oracle。网络断了恢复之后可以自动续传；
缺点：属于逻辑同步，DDL操作的话需要额外去管控。

部署简要流程：

1. 建一个DTS任务，源端连接生产集群，目标端连接异地灾备库；
2. 先执行一次全量初始化；
3. 开启增量同步，持续去捕获DML，还有部分DDL；
4. 开个定时任务，做两边数据的行数、抽样数据一致性比对；
5. 配置一下同步中断的告警。

适用场景：源库是Oracle迁移过来的、希望灾备库可以做报表查询的项目。

六、🚨 灾难切换完整操作流程

灾难切换其实分两种情况。一种是真实灾难故障切换，另一种是定期演练切换。

有个重要原则得说一下。切换是不可逆的。一旦你把灾备提升为主库了，等原生产中心恢复之后，你是不能直接切回去的。需要重新去做同步链路。

6.1 WAL归档灾备切换步骤

① 第一步，确认生产中心是不是彻底失效了。得确认生产机房的网络、服务器是完全不可用的。千万不要误操作。
② 在异地灾备节点执行提升操作，把备库切换成可读写的主库：

sys_ctl promote-D/opt/KingbaseData

③ 校验一下灾备库的状态，确认数据库可以读写了。执行个简单的增删改验证一下。
④ 去修改业务系统的数据库连接地址，切换指向异地灾备的IP。
⑤ 做业务回归验证，把核心业务流程跑通。
⑥ 原生产机房故障修复好之后，不能直接切回。需要把旧生产库作为新的备机，重新搭建同步链路。

6.2 DTS逻辑同步灾备切换步骤

① 确认生产环境是不是彻底不可用了；
② 把DTS同步任务停掉；
③ 确认灾备库数据是完整的，然后让业务应用切换连接到异地灾备库；
④ 业务全流程验证；
⑤ 原生产环境修复好之后，反向搭建一个DTS同步。等数据追平了，再找个时间切回去。

6.3 回滚说明

灾备切换一旦完成了，是不存在一键回滚的。你想切回原机房的话，得重新搭建同步，等数据追平了再执行二次切换。这也是演练的时候要重点关注的。

七、📅 灾备常态化运维与年度演练规范

灾备环境搭完了，不等于这事就结束了。80%灾备失效的情况，往往仅仅只是因为平时不维护、不演练。

7.1 每日巡检必做项

1. 检查WAL归档或者DTS同步任务的运行状态，看看是不是中断了；
2. 检查灾备数据滞后时间，看看RPO是不是还在指标范围内；
3. 抽样比对一下生产库、灾备库核心表的行数，做个简单的数据一致性校验；
4. 专线网络状态监控，网络一抖动就及时告警。

7.2 每月校验

抽取核心业务表，做多条业务记录的抽样比对。核对一下关键的业务字段。

7.3 年度灾备演练（监管要求）

政务金融项目的话，监管一般会要求你每年至少得开展一次完整的灾备切换演练。
演练流程：

1. 演练前先输出演练方案、回滚预案。选一个业务低峰的时间窗口；
2. 模拟生产中心故障，执行灾备提升、业务切换；
3. 执行业务功能、数据完整性的验证；
4. 记录下实际的RTO、RPO，看看有没有达到设计的指标；
5. 演练结束，重新搭建同步链路，把业务切回生产中心；
6. 输出正式的演练报告，归档留存。等保、监管检查的时候要看的。

⚠️ 演练不是简单看灾备库能不能启动就行了。你必须把业务真正切过去，跑一段时间。很多隐藏的问题，只有真实切换之后才会暴露出来。

八、📝 真实案例：某地级市政务异地灾备落地

8.1 项目背景

某地市政务一网通办平台，核心办件业务。监管要求做异地灾备。

• 生产中心：本市政务机房一主两备；
• 灾备中心：隔壁城市政务云机房；
• 指标要求：RTO ≤60分钟，RPO ≤10分钟；
• 方案选型：WAL归档异地灾备，找运营商拉专线打通两地机房。

8.2 实施过程

1. 异地机房部署同版本的电科金仓服务器；
2. 配置ssh免密，生产库WAL归档持续推送到异地；
3. 灾备库基于生产的物理备份做初始化，搭建standby归档重放；
4. 配置监控告警：归档推送失败、同步滞后过大、专线中断这些情况要实时告警；
5. 编写切换操作手册，明确每一步该敲什么命令；
6. 开展年度完整的灾备切换演练。

8.3 遇到的现实问题

1. 运营商专线偶尔会出现网络抖动的情况。WAL文件推送就堆积了。这个呢，通过监控及时发现并处理了；
2. 第一次演练的时候，发现灾备磁盘空间规划得不够。演练前赶紧扩容了磁盘；

8.4 落地效果

✅ 日常灾备持续同步，数据滞后基本维持在几秒级别；
✅ 完整演练实际RTO约42分钟，满足60分钟指标；
✅ 通过政务系统安全专项检查；
✅ 形成完整运维手册、演练报告。

九、⚠️ 异地灾备高频踩坑汇总

1. 把本地主备当成异地灾备：全部节点放在同一个机房，机房故障全部挂掉，不满足监管要求。
2. 灾备环境只是搭起来，从来不校验数据，真出事发现数据严重缺失。
3. 不做完整的切换演练，只启动灾备看看能不能登录，没有真实切换业务，大量隐藏问题无法暴露。
4. 忽略专线网络质量，公网直接跑灾备同步，网络波动大，同步频繁中断。
5. 切换之后幻想一键回滚，灾备提升为主库之后旧环境不能直接复用，需要重新搭建同步。
6. 灾备服务器配置远低于生产，切换之后CPU、内存扛不住业务流量。也就是说，灾备硬件配置要和生产看齐。
7. WAL归档磁盘空间没做监控，归档文件把灾备磁盘打满，重放停止。

十、✅ 本章总结与下一章预告

读完这章，你怎么去区分不同的灾备架构，怎么去看懂RTO、RPO这些核心指标，这些你应该清楚了。WAL归档、DTS这两种异地灾备的部署，你自己也能去搞了。包括灾难切换怎么操作，常态化巡检怎么做，年度灾备演练的整套流程，你都掌握了。政务金融监管对灾备建设的要求，你也就知道怎么去满足了。

本章核心收获：

1. 理解了RTO、RPO这两个灾备核心指标，能看懂行业的指标要求；
2. 分清了本地高可用、同城灾备、异地灾备、异地多活各自的适用边界；
3. 掌握了WAL归档异地灾备的完整配置，还有DTS逻辑灾备方案；
4. 掌握了灾难切换的完整操作步骤，明白了切换之后的回滚限制；
5. 掌握了灾备日常巡检、年度演练的标准流程；
6. 能识别异地灾备项目里的高频风险点，规避“灾备建了却没法用”的问题。