“你们这个主备到底能不能在关键时候顶上去”——这句话我几乎每次给客户做达梦数据库架构评审都会被问到。DM数据库的实时主备集群确实能扛住单点故障但“能扛”和“真正验证过能扛”是两码事。很多团队把主备部署完毕、监视器一切正常就当成交付完成结果等到生产环境真出问题那天才发现备库日志断档、监视器权限不对、切换脚本早就不兼容了。所以这一篇我打算聊聊怎么对DM数据库的实时主备做一次完整的故障模拟演练从架构原理、演练设计到具体制造故障、切换、恢复的全过程以及我踩过的那些坑。这篇更适合生产环境已经跑着DM双机、或者正在做主备方案选型的DBA和架构师看完之后你应该能照着设计出自己的演练方案。1. 故障演练前必须搞清楚的架构基础1.1 DM主备到底是怎么工作的先说底层机制。DM数据库的主备同步核心是redo日志的传输与重做。每次事务提交产生redo日志后主库通过MAL系统将日志实时或异步地发送给备库备库收到日志后进行重做从而保持数据一致。达梦在这之上又构建了一套完整的守护体系关键组件有三个主库Primary对外提供读写服务所有业务写入都走主库。备库Standby持续接收并应用主库的redo日志保持热备状态。守护进程dmwatcher和监视器dmmonitor守护进程负责监控本机数据库状态监视器则负责协调整个集群的切换决策。这里有个容易混淆的点主备自动切换并不是数据库进程自己直接决定的而是监视器在确认“主库不可用”之后向备库下发切换命令。所以演练时你不仅要在数据库层面制造故障还要观察监视器和守护进程的联动是否正常——很多主备集群“假正常”的问题就出在这条联动链路上。1.2 实时主备与异步备机的差异很多人在部署之前没想清楚业务到底需要哪种同步模式结果演练时才发现数据丢失容忍度与同步模式不匹配。达梦实时主备的核心特征是事务在主库上提交时redo日志已经同步到备库并完成归档接收因此主库发生故障时理论上可以做到不丢数据但代价是每次事务提交都有同步等待的开销业务高峰期主库响应时间会变长。异步备机则是主库本地提交完成后立即返回日志异步发送到备库性能影响小但故障时数据丢失窗口不可控。如果需要“零丢失”的业务场景比如订单库、账户流水必须选择实时主备如果只是做历史库、报表库的容灾异步备机就足够了。这一点在演练前面一定要和业务方对齐否则切换之后两边会对“数据到底丢没丢”产生很大分歧。1.3 演练目标故障转移与计划内切换是两条路故障模拟不是只验证“备库能不能变成主库”而是要区分两类切换路径计划内切换switchover主库本身没坏通过手动指令将主备角色互换。常用于机房维护、操作系统升级、数据库版本原地更新等场景。故障转移takeover/failover主库真正宕机或服务不可用备库被动接管成为新的主库。在DM监视器里这两条路径对应的指令并不相同自动故障转移还需要确认监视器是否配置了自动切换权限。演练的时候我建议两条路径都覆盖先做计划内切换验证日常维护能力再做故障转移验证应急能力顺序不要反因为计划内切换能先把正常流程跑通故障转移更有针对性。2. 怎么设计一次真实有效的故障演练2.1 先画清楚拓扑和职责边界我见过不少演练翻车的案例起因不是操作复杂而是连“谁是主、谁是备、监视器在哪台机器”都没在演练方案里写清楚。这里我给出一个常见的DM实时主备拓扑示例你演练前可以照着整理自己的角色安排建议如下主库主机192.168.1.10实例名GRP1_RT_01数据库服务dmserver。备库主机192.168.1.11实例名GRP1_RT_02数据库服务dmserver。独立监视器主机192.168.1.12运行dmmonitor工具。数据目录/dm/data归档目录/dm/arch守护进程配置文件dmwatcher.ini监视器配置文件dmmonitor.ini。这里要特别提醒一点监视器最好放在第三台独立主机上不要和主库或备库放在一起。如果监视器和主库同机主库宕机时监视器也可能跟着不可用自动切换就会失灵。这也是很多生产事故“备库明明活着却始终没人接管”的根源之一。2.2 明确演练的通过标准演练不能只为了“跑一遍流程”每个环节都应该有明确的通过标准否则演练结束后没办法判断主备集群是否真的合格。我自己常用的通过标准是这样几条主库故障发生后监视器能在设定的超时时间内检测到异常并在可接受的时间窗口内自动完成备库角色升级。切换后新旧主库的数据经过校验保持一致或者偏差在业务可接受范围内取决于你用的是实时主备还是异步备机。应用在更新数据库连接配置或者连接池自动重连之后能够正常读写新主库。原主库恢复后能重新以备库身份加入集群数据追平不再影响集群健康状态。这些标准最好在演练开始之前打印出来发给所有参与人演练结束后逐条打钩不要凭感觉说“感觉还行”。2.3 演练前的准备清单准备阶段如果偷懒演练现场就会出各种低级问题。我这里列一份完整的准备清单确认主备库都有最新的物理备份并保留备份文件在独立存储避免演练过程中意外操作导致数据不可恢复。检查归档日志连续性确保备库接收日志无中断可以通过dmmonitor的show health命令查看归档状态。确认监视器能正常登录并且监视器配置里已经指定了自动故障切换的权限。检查所有主机的时间同步时间偏差过大会导致心跳超时误判这是主备集群最常见却最容易被忽略的坑。在业务低峰期操作并通知相关研发、测试、运维同事避免演练过程中有人连接数据库执行DDL造成额外干扰。这份清单我每次演练都会检查一遍如果你发现备库归档断档那就先把断档问题解决否则故障转移后大概率丢数据。3. 故障模拟实操全过程3.1 场景一模拟主库实例崩溃进程级故障这是最直接的故障模拟方式适合验证监视器对实例异常退出的识别和自动切换能力。我通常选择直接kill掉主库的dmserver进程模拟类似OOM被杀或后台进程崩溃的情况。操作建议先登录主库主机确认当前主库状态再执行kill命令然后立刻转向监视器观察日志。需要注意一点建议一步一步来不要一开始就模拟拔网线之类的高级故障。先把最简单的实例崩溃跑通了再往复杂场景推进。3.2 场景二模拟主库主机宕机或网络隔离实例崩溃测试通过后我再升级难度模拟主库主机掉电或者网络隔离。这一步验证的不只是数据库守护逻辑还包含监控网络、系统层的心跳检测。具体做法可以用防火墙将主库的数据库服务端口、MAL通信端口全部丢弃或者直接关机观察监视器的检测行为。这个场景最大的价值在于验证故障发生的“不可预知性”。实例崩溃还会在系统日志里留下明确的退出痕迹而网络隔离时主库本身还在运行心跳消息发不出去守护进程和监视器只能依靠超时机制来判定故障这中间需要一定的判定时间这个时间是RTO的一部分必须在演练前和业务方说清楚。3.3 触发主备切换并观察角色变化当监视器确认主库不可用后会自动下发切换指令。如果你配置的是半自动模式则由DBA在监视器里手动执行切换指令。无论哪种模式切换过程中都应该重点观察这几个状态变化备库实例状态从Mount/Standby变为Open/Primary。新主库开启对外读写服务且继续保留归档日志记录。监视器日志中出现切换相关的记录并更新集群拓扑。这里我要特别强调一点不要只盯着数据库看还要看应用能不能连上。很多演练到此就结束了但实际业务不会自动切过去——你还要处理数据库连接地址、连接池配置、业务系统的数据源切换等问题。如果是生产环境建议提前将应用的数据源配置支持多地址Failover或者通过VIP漂移方案屏蔽后端变化。3.4 切换过程中的常见干预时机切换开始后我通常会忍住不手动干预除非出现以下情况备库数据不完整且不能接管需要临时挂载原主库进行紧急恢复监视器未检测到故障导致自动切换长时间未执行需要手动触发业务要求回切原主库需要终止切换流程。演练时最好提前约定一个“谁有权干预”的规则避免多人同时登录监视器操作产生指令冲突。4. 切换后的验证与故障恢复4.1 数据一致性验证主备切换完成不等于演练结束。数据一致性验证是演练中最容易敷衍的一环但也是业务方最关心的部分。我建议至少做三件事登录新主库查询关键业务表的记录数、最新时间戳与切换前记录的基准数据进行比对。如果主备集群里还有其他备库确认所有剩余备库能够继续同步新主库的redo日志不被“落下”。使用达梦的日志分析手段检查切换期间是否存在未传送到备库的日志记录判断数据丢失窗口。如果用的是实时主备且操作规范结果大概率是零丢失。但“大概率”不代表“一定”只有通过数据比对你才能在演练报告里给业务方一个确定的答复。4.2 原主库重新加入集群模拟演练中原主库并不是真的损坏只是被我们人为制造了故障。演练后期必须原主库重新加入集群否则集群长期处于单点状态后续再出问题就没有退路了。原主库重新加入集群的操作逻辑是先将原主库以Standby模式启动再从新主库重新同步数据最后确认日志追平并转换为正常的备库。这里有一个经常出错的细节不要用旧配置直接启动否则原主库可能因为你没清理旧的守护配置启动后仍然试图以主库身份运行导致集群脑裂。我个人习惯是在启动之前先检查dmmal.ini和dmwatcher.ini里的实例角色配置以及归档配置是否与新集群匹配。4.3 应用恢复与连接验证很多团队在主备切换验证后忽略了应用侧的恢复测试导致演练结束后业务仍处于故障状态。应用侧至少应该验证这几项连接池是否能在旧连接断开后自动重连到新主库。事务重试机制是否正常切库瞬间未完成的事务能否安全回滚。核心交易接口在切换前后是否能保持可用。如果你的环境是通过VIP漂移来实现应用透明访问那么还要验证VIP是否成功绑定到新主库并确认ARP缓存刷新情况。数据源、客户端缓存的问题往往在切换后几分钟内集中爆发这也是为什么演练要预留足够的观察窗口不要切完马上宣布成功。5. 常见问题与避坑实录5.1 故障演练高频问题速查表我把这些年演练过程中遇到的高频问题整理成了一张表方便你对照排查常见现象可能原因排查思路规避建议监视器迟迟不触发自动切换监视器权限配置不足或心跳检测周期过长检查dmmonitor.ini中的自动切换配置查看监视器日志演练前确认自动切换开关为打开状态切换后新主库无法对外提供服务新主库启动模式仍是Mount未切换到Open登录新主库查看实例状态在切换流程中增加状态校验步骤原主库恢复后重复抢占主库角色旧守护配置未清理启动时误判角色检查dmwatcher.ini及实例初始模式恢复前清理旧配置并修改启动参数备库日志追平时间过长归档日志积压过多网络带宽不足查看日志发送队列确认MAL配置定期归档清理提升网络带宽切换后部分业务连接报错连接池缓存了旧主库地址VIP未漂移检查应用日志和网络连接状态配置多地址Failover或VIP定期演练验证这张表不是标准答案但方向上值得参考。每个人环境不同关键是要建立一套自己的“异常现象—原因—动作”对照表演练后持续完善。5.2 演练最后别忘了恢复生产配置演练完成后整个环境应该恢复到最初状态新主库如果继续承担主库角色那么原主库已作为备库重新加入如果业务要求恢复到演练前的拓扑那么需要再做一次计划内切换。无论哪种路径最终要确保集群处于健康状态并重新检查日志同步和守护进程状态。最怕的情况是演练结束就下班留下一个“新主库在跑、旧备库还没追平”的中间状态这等于主动制造了一个新的故障隐患。我每次演练结束都有一个固定动作重新打开监视器跑一遍show health命令打印集群全貌截图存档确认所有节点都处于期望状态才签演练确认单。5.3 演练周期与演练报告DM实时主备故障模拟不是一次性工作而是需要周期性执行的运维动作。我通常是每季度做一次完整演练每次演练后输出包含切换时间线、数据校验结果、问题清单和改进建议的演练报告同时将演练中发现的问题纳入下个月的整改计划。这样循环下来主备集群的“可信度”会越来越高下次再被问到“到底能不能切换”的时候你就有实打实的数据和报告可以回答。6. 我的个人体会演练做得越多越发现主备集群的真正难点不在于“主备怎么切”而在于“切完之后整个系统能不能无缝继续服务”。数据库层面只是最小的一环网络、应用、监控、人员权限每个环节都可能在关键时刻拖后腿。在实际操作中我最大的一个感悟是先把业务方拉进演练复盘会把数据库层面的切换结果翻译成业务能够理解的语言比如“RTO可以做到多久”“数据丢失窗口是零还是有几秒”“什么时候可以恢复写入”。只有业务侧真正认可这套机制主备集群的存在才有意义否则DBA自己演练再熟练对组织来说价值都是打折的。最后再分享一个小技巧每次演练前我会临时关闭生产环境一些不必要的自动告警只保留主备集群相关的核心告警避免演练期间触发大量误报典型的告警疲劳反而会让人忽略真正的异常。演练结束后再恢复所有告警规则。这个动作虽然简单却能让整个演练过程清爽很多也方便事后复盘时聚焦关键日志。