一、故障现场集群“活着”但不可用某信创项目在云主机上部署 DM8 数据守护主库 172.17.0.201、备库 172.17.0.202。归档配置、备份恢复、参数文件全部按文档完成dmserver 与 dmwatcher 进程正常55201、65201 等端口均在监听——一切看起来都对唯独主库状态死死卡在mode is primary, state is mount拒绝 Open。主库不 Open 意味着 5236 端口不对外服务应用连不上集群形同虚设。进程健康、端口监听正常常规检查一无所获故障被藏在了更底层。二、先讲架构主库 Open 前必须迈过的“三道门”要理解这个故障必须先理解达梦数据守护的启动时序。数据守护由四个角色协作主备数据库实例dmserver、驻留在每个节点的守护进程dmwatcher、作为集群裁判的监视器dmmonitor实例间通过MALMessaging Access Layer通信系统传输 Redo 日志与状态消息。在 DW_MODE AUTO 自动切换模式下dmwatcher 接管实例后并不会直接把主库从 Mount 推到 Open而是要依次完成加载 MAL 配置——dmserver 启动时将dmmal.ini读入内存建立对端连接画像MAL 建链——主备 dmwatcher 通过 MAL 通道互连校验 OGUID 与对端身份状态确认——主库拿到“备库已就绪、归档链路通畅”的确认后才被允许 Open。这套保守时序的本质是脑裂防护Split-Brain Prevention若主库在备库失联的情况下贸然 Open 承接写入两侧数据会迅速分叉后续切换与恢复将不可收拾。达梦宁可让业务暂时不可用也绝不冒数据撕裂之险。由此可以推出一条排错主线主库不 Open → dmwatcher 未收到备库确认 → MAL 链路未建立 → 问题必在 dmmal.ini、网络或端口三者之一。三、排错过程借助 WorkBuddy 逐层收敛本次排错借助了 AI 运维助手 WorkBuddy——它能直接 SSH 到两台云主机并行拉取两侧 dmwatcher 日志与配置文件进行比对省去了在两台机器间来回切换、肉眼核对端口的大量机械劳动。结合上述排错主线问题很快逐层暴露。坑一端口错位——“自己拨自己的手机号”WorkBuddy 汇总两侧 dmwatcher 日志后一条关键报错被高亮主库正在尝试连接172.17.0.202:65201返回errno(111) Connection refused。65201 是主库自己的 dmwatcher MAL 端口。对照配置发现dmmal.ini 中描述备库 DMDB02 的 [MAL_INST2] 段MAL_DW_PORT 与 MAL_INST_DW_PORT 误写成了主库的 65201/45201而备库实际监听 65202/45202。这个错误极具迷惑性进程在跑、端口在听表象像“网络不通”根因却是配置笔误——主库在 MAL 链路里“自己找自己”。若在防火墙、安全组层面排查将白白消耗数小时。坑二NAT 之惑——MAL 只认网卡上的真实 IP修正端口后故障依旧日志开始刷屏 ini file ip does not match the local ips。WorkBuddy 实测两台主机私网连通性发现本应运通的私网端口探不通随即比对两端 dmmal.ini 证实MAL_HOST 配置的是云主机的公网 IP。而云主机的公网 IP 经 NAT 映射至私网本机网卡上并不存在该地址。达梦 MAL 启动时会校验配置的 IP 是否真实存在于本机网卡——账对不上链路直接拒绝建立。这是云环境部署达梦的高频坑MAL_HOST与MAL_INST_HOST必须填写ifconfig中真实可见的私网 IPNAT 映射地址一律无效。看到 ini file ip does not match the local ips即可直接锁定此因。坑三重启的“半吊子”——MAL 配置活在 dmserver 内存里两处配置修正后仅重启 dmwatcher主库仍不 Open。这是第三个认知盲区MAL 链路信息由 dmserver 在启动时读入内存dmwatcher 只是守护进程无法刷新 dmserver 内存中的旧配置。只重启 dmwatcherdmserver 仍按旧的端口与 IP 建链改配置等于白改。正确姿势是彻底重启 dmserver 实例。这一点与“改配置、重启服务即生效”的常规直觉相悖也是文档中容易被一笔带过的细节。四、修复与验证根因明确后修复流程标准化全停两侧 dmwatcher、dmserver 停干净不留残留进程改配置[MAL_INST2]中MAL_DW_PORT65202、MAL_INST_DW_PORT45202MAL_HOST、MAL_INST_HOST全部改为私网 IP按序启动主库 dmserver 至 Mount → 备库 dmserver 至 Mount → 两侧 dmwatcher。顺序不可乱否则 dmwatcher 建链失败再次进入保护状态验证主库V$INSTANCE显示PRIMARY/OPEN备库STANDBY/OPEN归档发送/接收状态正常Redo 日志持续同步。五、三条经验写给每一位部署者#教训检查要点1描述对端的[MAL_INSTn]段端口必须写对端自己的按实例名逐行核对勿凭记忆2云环境MAL_HOST必须配本机真实私网 IP报ip does not match the local ips即此因3修改 dmmal.ini 后必须彻底重启 dmserver只重启 dmwatcher 无效配置在实例内存中总结达梦数据守护“宁可不 Open、也不冒险”的保守策略短期看是“较真”长期看是在守护数据安全——但对部署者的配置严谨性提出了更高要求一个端口笔误、一个 IP 选错保护机制就会果断拦下主库。对团队而言两点启示值得带走其一把“主库不 Open → 查 MAL 链路”固化为排错 SOP可将此类故障的定位时间从小时级压缩到分钟级其二善用 WorkBuddy 这类能直连服务器、并行聚合多节点日志与配置的 AI 助手让信息收敛效率倍增——工具负责把问题摆上台面而理解底层机制永远是你自己的功课。今天话题就聊到这欢迎留言交流。觉得内容有用别忘了点赞转发给有需要的朋友回见