主库死活不 Open，WorkBuddy 十分钟揪出真凶——达梦数据守护 MAL 链路排错实录
一、故障现场：集群“活着”，但不可用
某信创项目在云主机上部署 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），实例间通过MAL（Messaging 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中真实可见的私网 IP，NAT 映射地址一律无效。看到 ini file ip does not match the local ips，即可直接锁定此因。
坑三：重启的“半吊子”——MAL 配置活在 dmserver 内存里
两处配置修正后，仅重启 dmwatcher，主库仍不 Open。这是第三个认知盲区：
MAL 链路信息由 dmserver 在启动时读入内存，dmwatcher 只是守护进程，无法刷新 dmserver 内存中的旧配置。只重启 dmwatcher，dmserver 仍按旧的端口与 IP 建链，改配置等于白改。
正确姿势是彻底重启 dmserver 实例。这一点与“改配置、重启服务即生效”的常规直觉相悖，也是文档中容易被一笔带过的细节。
四、修复与验证
根因明确后，修复流程标准化：
全停：两侧 dmwatcher、dmserver 停干净，不留残留进程；
改配置：
[MAL_INST2]中MAL_DW_PORT=65202、MAL_INST_DW_PORT=45202；MAL_HOST、MAL_INST_HOST全部改为私网 IP；按序启动：主库 dmserver 至 Mount → 备库 dmserver 至 Mount → 两侧 dmwatcher。顺序不可乱，否则 dmwatcher 建链失败再次进入保护状态；
验证：主库
V$INSTANCE显示PRIMARY/OPEN，备库STANDBY/OPEN，归档发送/接收状态正常，Redo 日志持续同步。
五、三条经验，写给每一位部署者
# | 教训 | 检查要点 |
|---|---|---|
1 | 描述对端的 | 按实例名逐行核对，勿凭记忆 |
2 | 云环境 | 报 |
3 | 修改 dmmal.ini 后必须彻底重启 dmserver | 只重启 dmwatcher 无效，配置在实例内存中 |
总结
达梦数据守护“宁可不 Open、也不冒险”的保守策略，短期看是“较真”，长期看是在守护数据安全——但对部署者的配置严谨性提出了更高要求：一个端口笔误、一个 IP 选错，保护机制就会果断拦下主库。
对团队而言，两点启示值得带走：其一，把“主库不 Open → 查 MAL 链路”固化为排错 SOP，可将此类故障的定位时间从小时级压缩到分钟级；其二，善用 WorkBuddy 这类能直连服务器、并行聚合多节点日志与配置的 AI 助手，让信息收敛效率倍增——工具负责把问题摆上台面，而理解底层机制，永远是你自己的功课。
今天话题就聊到这，欢迎留言交流。觉得内容有用，别忘了点赞转发给有需要的朋友，回见！