KES灾备与异地多活完整方案这篇是《电科金仓数据库从入门到精通》的第十九篇。前面其实咱们聊过高可用主备集群也聊过国密安全、国产化适配这些事。但是呢那些方案啊往往仅仅只是局限在同一个机房里面或者说在同一个城市的内部。如果碰上机房断电了或者火灾了甚至是城市级别的灾害出现了。这时候本地主备集群就会整体失效业务也就彻底跑不起来了。对于金融、省级政务、能源这些核心系统来说监管那边的意思是明确的。你必须得具备异地灾难恢复的能力。很多单位其实会搞混一个事。就是把“主备高可用”和“异地灾备”当成一回事了。怎么搞的呢简单粗暴地把本地备机搬到异地去就觉得是灾备了。网络抖动的情况他不管数据一致性也不看切换演练更是没有。RTO、RPO这些指标直接忽略。那真遇到灾难的时候你猜怎么着发现灾备库的数据严重滞后根本就没法接管业务。这章呢我就结合几个省级政务、城商行真实的灾备项目经验来聊。本地高可用啊同城灾备啊异地灾备啊还有异地多活这些怎么选型、怎么部署、同步策略是什么、切换怎么演练、风险点在哪我都会讲。所有配置方案都是贴合电科金仓KES V9R1C10官方规范的。你直接拿过去就能当灾备建设的实施方案来用。一、 本章学习导读1.1 学习目标分清高可用、同城灾备、异地灾备、异地多活这些概念到底有啥差异。能够结合你的业务去选一个合适的灾备架构深刻理解RTO、RPO这两个灾备核心指标。能看懂监管对政务金融的指标要求是怎么写的掌握电科金仓异地WAL归档灾备、DTS增量同步灾备这两种主流的实现方式学会灾备环境怎么完整部署日常怎么做监控数据一致性怎么去校验掌握灾难发生时完整的切换流程回滚操作怎么搞能够自己组织灾备演练识别异地灾备里那些高频的风险。比如网络延迟、同步滞后、数据冲突还有演练流于形式的情况1.2 本章重点灾备核心指标RTO、RPO概念与行业指标参考四种灾备架构对比与业务选型WAL归档异地灾备部署实战DTS增量同步异地灾备配置与校验灾难切换完整操作步骤、灾备年度演练流程真实省级政务异地灾备落地案例二、 为什么一定要建设异地灾备很多人其实会有个疑问。本地不是已经搞了一主两备的高可用集群了吗为什么还要费劲去建异地灾备呢本地主备集群它解决的是什么问题呢是单台服务器故障的问题。比如说某一台机器宕机了备机自己就顶上去了。但是如果出现的情况是机房整体断电了呢或者是机房着火了光缆被挖断了再极端一点城市区域性灾害出现了。那整个机房就全部失效了。本地所有的主节点、备节点会全部同时瘫痪。金融监管、政务等保规范里面对核心业务是有硬性要求的。也就是说关键业务你不能把所有的东西都放在同一个机房里面。灾备啊不是说你在远方搭了一套数据库就完事了。灾备最可怕的情况是什么呢不是灾难本身发生了。而是灾难真的来了你发现灾备库根本用不了。我见过不少项目是这样的。灾备库就常年摆在异地机房里。从来不做数据校验也不做切换演练。等到真正出事故了才发现灾备库长期同步都是中断的。数据差了好几天完全没法接管业务。灾备建设其实分四个环节。架构部署常态化监控一致性校验还有定期切换演练。这四个缺一个都不行。三、 灾备两大核心指标 RTO 与 RPO所有的灾备方案设计啊都是围着这两个指标转的。不管你是写方案文档还是去做项目验收这两个指标就是评判灾备能力的标尺。RTO恢复时间目标灾难发生之后业务要恢复正常运行需要花多少时间。举个例子RTO30分钟。这就代表灾难出现了最多允许业务中断30分钟然后就得恢复对外服务。RPO恢复点目标灾难发生之后最多允许你丢失多长时间的数据。举个例子RPO5分钟。这就代表极端故障的情况下最多把最近5分钟的数据丢了不能再多了。行业通用参考标准普通政务非核心业务RTO ≤4小时RPO ≤30分钟。也就是不那么核心的业务政务核心办件、能源营销系统RTO ≤60分钟RPO ≤10分钟城商行、金融账务核心RTO ≤30分钟RPO ≤5分钟注意一下。指标不是越小就越好的。指标要求越高的话硬件成本、网络成本是会成倍往上涨的。你得结合业务实际的诉求去平衡一下不要盲目去追求那种极致的指标。四、️ 四大灾备架构选型对比4.1 本地主备高可用单机房架构就在同一个机房内部1主N备VIP自动做故障切换。RTO秒级~30秒RPO≈0优势成本低切换速度也快短板没法抵御机房级别的灾难适用业务基础的高可用其实不能当做灾备来用。4.2 同城灾备同一城市两个不同机房主集群在A机房灾备节点部署在本市B机房。两个机房距离大概几十公里吧用光纤专线打通。RTO15‑60分钟RPO 1‑5分钟优势网络延迟低同步稳定成本比异地要低短板没法抵御城市级别的灾害适用大部分省级、地市级政务核心系统。4.3 异地灾备跨城市相隔几百公里以上生产中心在A城市灾备中心部署在另外一座城市。通过运营商专线去传数据。电科金仓实现的方式分两类WAL归档灾备、DTS增量同步灾备。RTO30‑120分钟RPO 5‑30分钟优势可以抵御城市整体故障了短板公网或者专线的网络延迟高会存在一定的数据滞后。专线建设成本也高适用银行、省级政务、央企核心业务。4.4 异地多活双中心同时对外提供读写两个异地的机房两套集群同时去承担业务的读写流量。RTO接近0RPO≈0优势任何一个城市出故障了业务这边几乎是感觉不到的短板架构极其复杂会出现跨机房数据冲突的情况。改造成本极高适用头部金融、超大型全国性平台。普通政务项目的话很少采用。选型建议绝大多数的政企项目我建议优先选「本地主备高可用 异地灾备」这个组合方案。异地多活这个东西不要盲目去上。五、 电科金仓两种异地灾备实现方案实战电科金仓做异地灾备主流其实就两套技术路线。一个是WAL归档复制灾备另一个是DTS数据同步灾备。这两个东西原理不一样适用的场景往往也不一样。5.1 WAL归档异地灾备方案原理生产库这边呢会一直生成WAL预写日志。然后通过专线把这些日志传到异地灾备机房去。灾备节点拿到日志后就一直在那里重放。通过这种方式来实现数据同步。优点数据一致性高原生内核实现的不去解析SQL缺点灾备节点只能只读不能写。网络中断的话会堆积WAL文件等网络恢复了它再自动追平。5.1.1 生产库配置本地主库修改生产库的kingbase.confwal_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.confstandby_mode on restore_command cp /data/kes_archive/%f %p启动灾备实例它就会持续重放WAL日志了。灾备库会一直保持只读状态。5.1.3 监控重点监控WAL归档推送是不是在持续产生新文件监控灾备库重放的日志位点去算一下数据滞后时间专线网络一中断就得告警防止日志一直堆积长期不同步。查询灾备滞后程度的SQLSELECTnow()-pg_last_xact_replay_timestamp()ASreplica_lag;5.2 DTS增量同步灾备方案原理用到的工具是电科金仓的DTS迁移工具。它去抓生产库的增量变更把变更日志解析完再同步写进异地灾备库里面去。优点灾备库是可以读写的支持异构源库甚至可以是Oracle。网络断了恢复之后可以自动续传缺点属于逻辑同步DDL操作的话需要额外去管控。部署简要流程建一个DTS任务源端连接生产集群目标端连接异地灾备库先执行一次全量初始化开启增量同步持续去捕获DML还有部分DDL开个定时任务做两边数据的行数、抽样数据一致性比对配置一下同步中断的告警。适用场景源库是Oracle迁移过来的、希望灾备库可以做报表查询的项目。六、 灾难切换完整操作流程灾难切换其实分两种情况。一种是真实灾难故障切换另一种是定期演练切换。有个重要原则得说一下。切换是不可逆的。一旦你把灾备提升为主库了等原生产中心恢复之后你是不能直接切回去的。需要重新去做同步链路。6.1 WAL归档灾备切换步骤① 第一步确认生产中心是不是彻底失效了。得确认生产机房的网络、服务器是完全不可用的。千万不要误操作。② 在异地灾备节点执行提升操作把备库切换成可读写的主库sys_ctl promote-D/opt/KingbaseData③ 校验一下灾备库的状态确认数据库可以读写了。执行个简单的增删改验证一下。④ 去修改业务系统的数据库连接地址切换指向异地灾备的IP。⑤ 做业务回归验证把核心业务流程跑通。⑥ 原生产机房故障修复好之后不能直接切回。需要把旧生产库作为新的备机重新搭建同步链路。6.2 DTS逻辑同步灾备切换步骤① 确认生产环境是不是彻底不可用了② 把DTS同步任务停掉③ 确认灾备库数据是完整的然后让业务应用切换连接到异地灾备库④ 业务全流程验证⑤ 原生产环境修复好之后反向搭建一个DTS同步。等数据追平了再找个时间切回去。6.3 回滚说明灾备切换一旦完成了是不存在一键回滚的。你想切回原机房的话得重新搭建同步等数据追平了再执行二次切换。这也是演练的时候要重点关注的。七、 灾备常态化运维与年度演练规范灾备环境搭完了不等于这事就结束了。80%灾备失效的情况往往仅仅只是因为平时不维护、不演练。7.1 每日巡检必做项检查WAL归档或者DTS同步任务的运行状态看看是不是中断了检查灾备数据滞后时间看看RPO是不是还在指标范围内抽样比对一下生产库、灾备库核心表的行数做个简单的数据一致性校验专线网络状态监控网络一抖动就及时告警。7.2 每月校验抽取核心业务表做多条业务记录的抽样比对。核对一下关键的业务字段。7.3 年度灾备演练监管要求政务金融项目的话监管一般会要求你每年至少得开展一次完整的灾备切换演练。演练流程演练前先输出演练方案、回滚预案。选一个业务低峰的时间窗口模拟生产中心故障执行灾备提升、业务切换执行业务功能、数据完整性的验证记录下实际的RTO、RPO看看有没有达到设计的指标演练结束重新搭建同步链路把业务切回生产中心输出正式的演练报告归档留存。等保、监管检查的时候要看的。⚠️ 演练不是简单看灾备库能不能启动就行了。你必须把业务真正切过去跑一段时间。很多隐藏的问题只有真实切换之后才会暴露出来。八、 真实案例某地级市政务异地灾备落地8.1 项目背景某地市政务一网通办平台核心办件业务。监管要求做异地灾备。生产中心本市政务机房一主两备灾备中心隔壁城市政务云机房指标要求RTO ≤60分钟RPO ≤10分钟方案选型WAL归档异地灾备找运营商拉专线打通两地机房。8.2 实施过程异地机房部署同版本的电科金仓服务器配置ssh免密生产库WAL归档持续推送到异地灾备库基于生产的物理备份做初始化搭建standby归档重放配置监控告警归档推送失败、同步滞后过大、专线中断这些情况要实时告警编写切换操作手册明确每一步该敲什么命令开展年度完整的灾备切换演练。8.3 遇到的现实问题运营商专线偶尔会出现网络抖动的情况。WAL文件推送就堆积了。这个呢通过监控及时发现并处理了第一次演练的时候发现灾备磁盘空间规划得不够。演练前赶紧扩容了磁盘8.4 落地效果✅ 日常灾备持续同步数据滞后基本维持在几秒级别✅ 完整演练实际RTO约42分钟满足60分钟指标✅ 通过政务系统安全专项检查✅ 形成完整运维手册、演练报告。九、⚠️ 异地灾备高频踩坑汇总把本地主备当成异地灾备全部节点放在同一个机房机房故障全部挂掉不满足监管要求。灾备环境只是搭起来从来不校验数据真出事发现数据严重缺失。不做完整的切换演练只启动灾备看看能不能登录没有真实切换业务大量隐藏问题无法暴露。忽略专线网络质量公网直接跑灾备同步网络波动大同步频繁中断。切换之后幻想一键回滚灾备提升为主库之后旧环境不能直接复用需要重新搭建同步。灾备服务器配置远低于生产切换之后CPU、内存扛不住业务流量。也就是说灾备硬件配置要和生产看齐。WAL归档磁盘空间没做监控归档文件把灾备磁盘打满重放停止。十、✅ 本章总结与下一章预告读完这章你怎么去区分不同的灾备架构怎么去看懂RTO、RPO这些核心指标这些你应该清楚了。WAL归档、DTS这两种异地灾备的部署你自己也能去搞了。包括灾难切换怎么操作常态化巡检怎么做年度灾备演练的整套流程你都掌握了。政务金融监管对灾备建设的要求你也就知道怎么去满足了。本章核心收获理解了RTO、RPO这两个灾备核心指标能看懂行业的指标要求分清了本地高可用、同城灾备、异地灾备、异地多活各自的适用边界掌握了WAL归档异地灾备的完整配置还有DTS逻辑灾备方案掌握了灾难切换的完整操作步骤明白了切换之后的回滚限制掌握了灾备日常巡检、年度演练的标准流程能识别异地灾备项目里的高频风险点规避“灾备建了却没法用”的问题。