做达梦数据库运维这几年数据守护集群DM Data Watch和监视器Monitor这两个词几乎贯穿了所有高可用项目的交付和日常巡检。很多刚接触达梦的朋友会有一个误区觉得数据库做主备已经够用了监视器无非是看个状态。实际用下来完全不是这么回事——监视器才是整个数据守护集群真正值钱的组件之一。这篇文章我尽量把事情说透。不整那些浮在表面的概念直接从架构分工、配置实操、日常巡检、故障切换和排坑经验这几个维度聊。如果你正在做达梦数据库主备方案、准备上数据守护集群或者已经上了但还不太清楚监视器要怎么玩这篇内容大概率能帮你省下不少摸索时间。1. 先搞清楚数据守护集群里监视器到底是个什么角色1.1 一套完整的数据守护集群有哪些“成员”达梦数据守护集群的核心思想其实不复杂就是通过日志归档和日志传送让备库尽可能跟上主库的进度在主库出问题的时候顶上去。但真要落地成一套能交到运维手里、敢让业务跑在上面的方案那组成成员就比“一主一备”四个字要多不少了。以最常见的 DM8 一主一备或者一主两备为例整个集群至少有四类角色主库Primary承载业务读写所有事务在主库完成。备库Standby实时或者准实时接收主库的归档日志并重演正常情况下只读或完全不可访问等待接管。守护进程Dmwatcher部署在主、备库所在服务器上的独立服务负责监视数据库实例的状态并向监视器上报它也负责在本地执行监视器下发的切换、接管指令。监视器Dmmonitor独立运行的程序可以部署在集群节点上也可以部署在单独的机器上。它汇总整个集群所有守护进程上报的信息是整个集群“状态中枢”和“指令入口”。很多教程喜欢把守护进程和监视器混着讲我建议你在心里把这两者分清楚守护进程是“一线值班员”每个数据库节点上都有一个它盯着自己那一亩三分地监视器是“值班班长”它不直接盯数据库实例而是通过各个守护进程拿全局信息需要干预的时候也是把命令下发给守护进程去执行。1.2 监视器和守护进程的分工一个看门一个值守我见过不少刚上手达梦的同事一到集群节点上看到进程列表里有 dmwatcher 就以为监视器已经装了其实完全两码事。守护进程dmwatcher最重要的工作有两个一是实时监控本机数据库实例的 OPEN、MOUNT 状态以及主备角色二是维持自己和远端守护进程之间的通信状态把本机的状态广播出去。如果配置了自动切换AUTO 模式守护进程还承担故障检测和切换决策的辅助工作。监视器dmmonitor则是站在全局视角。它接收的是所有守护进程发来的状态消息它能看到的是“整个集群现在谁主谁备、日志同步是否正常、每个节点的守护进程是否存活、实例状态是否健康、是否存在脑裂风险”等。你可以这么理解守护进程负责把“单机事实”准确地报上来监视器负责把“全局事实”拼出来给运维看并在关键时刻做出切换决策。没有监视器集群主备倒换只能依赖人工登录节点去手动操作守护进程这在生产故障场景下是不可接受的。没有守护进程监视器就像没有传感器的中控台看到的全是空数据。1.3 为什么说监视器是整个集群的“驾驶舱”回到文章标题里“监视器详解”这个点。我为什么坚持把监视器当成驾驶舱而不是状态灯因为监视器不只是“看”状态的它还提供了几个关键能力全局状态可视一条命令直接看到所有节点状态而不用挨个登录服务器这在节点多、机房分散时尤其重要。人工干预入口主备切换、故障接管、强制切主这些高危操作都可以在监视器里统一发起比在服务器本地敲命令更安全因为它有全局信息做校验。历史留痕监视器可以把所有状态变化写入日志文件出问题后翻日志定位比什么描述都管用。自动切换决策当集群配置为自动切换模式时确认监视器负责在故障发生后协同守护进程完成自动故障切换这是整个高可用方案在最坏情况下的兜底机制。说直白一点如果你搭了一套数据守护集群但没有装监视器就相当于买了一辆车但没装仪表盘——车能跑但你不知道它什么时候会出问题。这也是为什么我建议所有使用达梦数据守护集群的团队不管环境多简陋至少都要部署一个独立的监视器。2. 监视器的工作原理和配置细节2.1 监视器是怎么做到“全局感知”的想用好一个组件还是得先知道它内部是怎么运转的。监视器的核心机制是依赖达梦数据库的 MALMedia Access Layer通信机制。简单解释一下达梦数据库在 dm.ini 中有 MAL_INI 参数开启这个参数后数据库实例之间、实例与守护进程之间、守护进程与监视器之间都会建立独立的通信链路。这些链路用于传输日志消息、状态心跳、控制指令等。每一个集群成员数据库实例、守护进程都会配置一个 MAL 地址而监视器则是通过守护进程上报的成员信息自动发现整个集群拓扑的。所以你会注意到一个细节dmmonitor.ini 配置文件里居然不需要配置主库备库的地址列表。监视器只要能在网络层访问到各节点的守护进程端口启动后通过守护进程之间的信息汇集就能把整个集群的拓扑和实时状态拉起来。这条设计我觉得很巧妙它意味着在集群扩容、缩容的时候监视器侧通常不用做任何配置变更。你只需要在新节点上把数据库实例、守护进程配好监视器下次刷新就能看到新成员。2.2 dmmonitor.ini 配置项详解监视器的配置主要集中在 dmmonitor.ini 文件里。这个文件比 dmwatcher.ini 简单得多因为监视器本身不直接管理数据库实例。DM8 下面最常见的配置大概是这样的# dmmonitor.ini MON_LOG_PATH /dm/data/log/monitor MON_LOG_INTERVAL 60 MON_LOG_FILE_SIZE 64 MON_LOG_SPACE_LIMIT 1024 LOG_DEST_LEVEL 5这几个参数的含义我逐个说一下MON_LOG_PATH监视器日志文件存放路径。这个路径一定要提前建好并且确保启动监视器的系统用户有写权限。我踩过最蠢的坑就是路径没建启动直接报错。MON_LOG_INTERVAL日志刷盘间隔单位秒默认是 60 秒。你可以理解成监视器把内存里的状态记录批量写到日志文件的间隔时间。想记录更细就调小但也会多消耗一些磁盘 IO。MON_LOG_FILE_SIZE单个日志文件大小上限单位 MB。超过这个值会滚动到下一个日志文件。MON_LOG_SPACE_LIMIT日志空间总上限单位 MB。超过这个值系统会删除最老的日志文件来释放空间避免日志把磁盘写满。LOG_DEST_LEVEL日志记录的详细级别范围是 0 到 5级别越高记录越细。日常建议用 5排障时信息最全如果你在意磁盘占用可以降到 3。有些场景下你还会看到配置了登录自动认证相关的选项但那些更多属于部署脚本自动化的范畴手工配置并不常见我在后面实操部分会提到。2.3 监视器的运行形态单机、多机、确认与非确认监视器在部署上很灵活可以单独一台机器也可以和数据库节点共用一台服务器。对于小规模环境直接把监视器部署在一台不太忙的数据库节点上完全可行生产环境我更推荐用独立的低配虚拟机或者物理机来跑避免和数据库抢资源。在多机部署的情况下就涉及到“确认监视器”和“非确认监视器”的概念了。简单来说确认监视器Confirmed Monitor在自动切换模式下集群里只会有一个确认监视器它拥有故障切换的最终决策权。非确认监视器Non-confirmed Monitor可以部署多个主要供运维人员日常查看状态和手工操作。区分这两种角色的关键在于 dmwatcher.ini 里的 DW_MODE 配置以及监视器是否被配置为确认监视器。如果你用的是自动切换模式一定要保证确认监视器长期在线——因为它一旦挂掉整个集群的自动切换能力会受到很大影响。这点我后面讲坑的时候会展开。3. 实操指南从部署到日常巡检3.1 一步步搭起一个新的监视器假设你现在已经有一套正常运行的达梦数据守护集群主备库和守护进程都起来了就差一个监视器。下面是完整的接入过程我按我常用的步骤写第一步创建日志目录mkdir -p /dm/data/log/monitor chown dmdba:dinstall /dm/data/log/monitor这里要注意如果你用 dmdba 用户启动监视器日志目录的属主必须是 dmdba否则启动时写不了日志文件。第二步创建 dmmonitor.inisu - dmdba vi /dm/data/dmmonitor.ini写入MON_LOG_PATH /dm/data/log/monitor MON_LOG_INTERVAL 60 MON_LOG_FILE_SIZE 64 MON_LOG_SPACE_LIMIT 1024 LOG_DEST_LEVEL 5第三步启动监视器cd /dm/bin ./dmmonitor /dm/data/dmmonitor.ini这里有一个小细节启动命令后面最好接绝对路径的配置文件不要只写文件名否则在不同目录下启动时容易找不到配置。启动成功后你会进到 dmmonitor 的交互界面提示符一般是monitor。这时候先执行show global info;如果能正常列出集群节点信息说明监视器已经成功接入集群。可以执行login登录然后开始你的巡检。3.2 高频运维命令实战监视器交互界面支持的命令不少日常运维真正高频用到的其实就那么几个。我按使用频率排个顺序show database xxx或者简写show database查看指定数据库实例的状态包括实例状态、归档状态、故障状态、角色、最近一次日志心跳时间等。这条命令基本每个巡检周期都要用。输出内容里最需要关注的是OGUID是否与集群一致、RSTAT是否是OPEN、WTIME是否还在正常增长。如果WTIME长时间不变化说明主备之间的通信可能卡住了。show watch info查看所有守护进程的状态。通过这条命令可以看到每个守护进程是否在线、心跳是否正常、各节点的连接状态。show global info查看全局汇总信息。它会把当前监视器视角下整个集群的主备关系、故障标记、切换状态一次性列出来。做切换演练前后我都会先执行这条命令确认基线状态。login / logout登录和退出。有些操作需要登录后才能执行比如 switchover、takeover。默认 dmdba 用户登录密码和数据库实例的 SYSDBA 密码不是一回事别搞混。switchover主备切换命令用于计划内的角色互换。执行时会校验主备库状态是否满足切换条件不满足时会直接报错。takeover备库接管命令在主库故障无法恢复时强制让备库提升为主库。命令行界面操作的时候我习惯把每个关键操作前后的 show 信息都截图或者复制下来存到当天的运维记录里。出了问题时这些输出就是最直接的事实依据。3.3 故障切换时监视器到底做了什么很多人关心一个问题主库宕机后监视器是怎么办事的这个过程分几种模式说你感受一下区别。如果你把守护进程的 DW_MODE 配成了 AUTO并且存在确认监视器那么主库故障后的大致流程是主库守护进程发现本地数据库异常向上报告确认监视器根据全局心跳信息结合 DW_ERROR_TIME 参数默认 30 秒判定主库是否真的失联确认主库故障后监视器选择一个处于健康状态的备库下发接管命令备库守护进程执行接管把备库切换成主库并通知其他节点更新角色。整个过程如果顺利业务中断时间通常在几十秒以内。如果 DW_MODE 是 MANUAL那么即使有监视器在线故障发生后也不会自动切换需要 DBA 登录监视器手工执行 takeover 或者 switchover。选择哪种模式取决于业务对恢复时间的要求。实话说自动切换虽然省心但前提是你的网络、存储、机房环境足够稳定。如果经常出现网络抖动或者存储卡顿自动切换反而可能误判造成不必要的切换。这个判断需要结合你实际的业务容忍度来做不要盲目追求自动化。3.4 配置文件和参数上的几个细节再补充几个配置文件里的常见参数这些在实际部署时几乎都会用到。# dmwatcher.ini DW_MODE AUTO DW_ERROR_TIME 30 INST_RECOVER_TIME 30这三个参数分别是守护进程工作模式、错误判定时间、实例恢复时间。生产环境里DW_ERROR_TIME 和 INST_RECOVER_TIME 通常设置 30 秒到 60 秒之间具体看业务对故障恢复时间和误判风险的权衡。如果设得太小比如 5 秒一次轻微的 IO 抖动就可能触发切换设得太大故障恢复时间就会变长。还有一个容易被忽略的配置是 dm.ini 里的DW_INACTIVE_INTERVAL。这个参数控制守护进程判定对端实例无响应的时间阈值如果网络不稳定建议适当调大避免频繁误报实例故障。监视器出发前先检查这几个文件是否同步正确dm.ini、dmwatcher.ini、dmmal.iniMAL 配置。很多时候监视器能看到节点但状态一直异常根源都是这几个文件配置不一致。4. 生产环境里那些容易踩的坑4.1 常见问题速查表我把实际运维中经常遇到的问题整理成一张表每个问题附上排查思路。这张表值得你存一份遇到问题的时候对照着看能少走不少弯路。症状可能原因排查与处理监视器启动报错提示无法连接守护进程守护进程未启动或网络端口被防火墙拦截用ps -ef | grep dmwatcher确认守护进程用 telnet 测试守护进程端口连通性show 命令看不到某个节点信息节点守护进程与监视器通信异常检查该节点 dmwatcher.ini 是否有误检查 MAL 配置和网络连通性确认监视器在线但自动切换没有触发DW_MODE 配的不是 AUTO或确认监视器不是唯一登录监视器执行 show watch info 确认模式检查各守护进程配置文件监视器日志目录报错无法写入日志目录权限不足或未创建创建目录并 chown dmdba:dinstall重启监视器切换过程中卡住一直显示 switching备库归档日志落后太多或备库 MOUNT 状态异常登录备库查看归档是否连续必要时先做主备日志补齐再切换监视器能登录但执行切换命令被拒绝当前监视器不是确认监视器权限不足确认当前监视器是否为确认监视器或改用确认监视器执行操作主库故障后新主库出现但应用连不上应用连接串还指向旧主库或连接池没做故障转移应用层配置多个节点地址开启连接池 failover 特性4.2 我记了很久的几条实操心得上面表格里是“问题导向”的速查思路下面我再分享几个我在真实项目里积累下来的体会这些往往不是文档里会写的东西。第一监视器日志别随手关。很多同事部署监视器时为了省事日志路径不配或者级别设得很低结果集群出了故障之后无据可查。其实监视器日志是定位集群脑裂、误切换、网络闪断这类问题最直接的材料。建议 LOG_DEST_LEVEL 至少设为 5日志空间给足保留周期按你审计要求来。第二多套环境最好用不同的监视器实例。有些项目会在一台机器上同时部署多套数据库环境每套环境都有自己的数据守护集群。如果共用一个监视器配置show global info 时会出现信息错乱。正确做法是每套集群一个 dmmonitor.ini、一个独立日志目录、一个独立监视器进程。第三自动切换环境一定要有确认监视器高可用方案。自动切换模式下如果确认监视器宕机集群虽然还能继续对外提供服务但一旦此时主库发生故障可能无法自动完成故障转移。这个风险必须提前跟业务方讲清楚。我见过一个项目确认监视器和主库在同一台物理机上结果主机宕机备库明明健康却干等在那里最后是人工登上去执行接管才恢复。后来我们把确认监视器单独挪到了第三台机器上。第四切换演练一定要常态化。不要等到真出故障了才第一次执行 switchover。计划内切换和故障接管还是有明显差别的建议每个季度至少做一次完整演练包括主库停机、监视器宕机、备库宕机、网络分区这几个场景。演练过程中记录切换耗时方便以后做恢复时间评估。第五数据库备份策略和切换策略要联动。有些环境主备切换很顺但切完发现新主库上的备份任务根本没跑起来因为备份脚本里写死了旧主库的地址。另外达梦的备份、还原和 dmp 导入导出是另一套体系建议在数据守护集群中就规划好逻辑备份在哪个库执行、物理备份在哪个库执行避免切换后乱成一锅粥。4.3 常见错误号比如 -3236 这类问题怎么看待热词里提到“迁移达梦错误号: -3236”这个错误号在很多达梦相关的操作中都会出现包括数据守护集群里做备份、导入 dmp 时也可能遇到。简单说错误号 -3236 通常和系统内存或文件描述符资源不足有关尤其是在大数据量导入导出时容易出现。遇到这种错误第一步先查操作系统层面的资源使用情况free -g看内存是否吃紧ulimit -n看文件数限制然后再看达梦数据库的 dmserver 日志有没有更详细的上下文。很多时候就是临时表空间或者排序区太大把内存顶爆了。在数据守护集群环境下我更建议你关注两点一是大事务在主库执行时归档日志会同步传到备库如果备库性能跟不上观察到的现象可能是备库应用延迟越来越大最终主库因为日志发送超时产生报错。这时候不能只盯着错误号本身要看整个同步链路。二是出现各种莫名其妙的导入导出报错的时先确认当前会话是连在主库还是备库。达梦备库默认不允许写操作很多导入任务连到备库上就会报错你以为是个错误号问题其实是指挥链路上的问题。5. 监视器的进一步应用从单套集群到运维体系5.1 把监视器数据融入到监控平台数据守护集群的监视器是运维体系里很关键的信息源但因为它是命令行交互工具天然不适合长时间挂屏盯。实际项目里我更建议把监视器输出的关键信息接到统一的监控平台。最常见的做法是写一个定时脚本每分钟执行一次show global info并把输出结构化提取主备状态、心跳时间、日志延迟等关键字段推送到监控系统。也有些人用达梦自带的动态性能视图直接在数据库侧采集主备状态效果差不多。这里提醒一句如果脚本用dmmonitor交互模式非交互执行要注意命令的输入输出重定向方式。一个比较稳的做法是在 shell 脚本里用管道把命令喂进去或者直接调用 dmmonitor 提供的 API 接口新版本有开放接口。不要在主备切换的时候因为监控脚本的副作用给生产添乱。5.2 应用层连接池与数据守护集群的配合光有数据库层面的高可用还不够应用侧也得知道主备切换后该连谁。这才是很多项目最后落地时的真正痛点。拿 Java 生态常见的 HikariCP 来说支持配置多个 JDBC 地址配合连接池的故障转移能力应用才能在数据库切换后快速恢复。达梦数据库的连接串支持类似jdbc:dm://host1:5236,host2:5236的多地址写法。配合 HikariCP 时可以设置 connectionTestQuery 为一个轻量查询比如达梦的SELECT 1并调整 maximumPoolSize、connectionTimeout 等参数让连接池在主备切换后能尽快感知并重建连接。我见过不少项目数据库切换演练做得漂漂亮亮结果应用到新主库的链路建立花了十分钟业务照样长时间中断。所以建议做切换演练的时候把应用连接恢复时间也纳入指标盯住连接池的日志。另外微服务架构里如果用了 Nacos 做配置中心还要确认 Nacos 是否适配了达梦数据库否则配置信息存储库可能还是 MySQL高可用就出现断层。5.3 信创迁移场景下的监视器选型思考这两年国产化迁移项目明显多了起来从 Oracle 迁移到达梦、从 SQL Server 迁移到达梦都很常见。迁移期间不只是把数据和存储过程搬过来高可用方案往往是验收的硬指标。达梦数据守护集群加监视器的组合承担的就是原 Oracle Data Guard 加 Grid Control 的职责。在这个场景下我对监视器部署有三条建议第一监视器尽量独立于主备节点部署。迁移项目里业务方对恢复时间要求通常很严格所以确认监视器最好单独一台机器能够抗住主备节点同时故障的极端场景。第二迁移初期用 MANUAL 模式手动切换稳定后再切 AUTO。新环境里网络、存储、应用负载都还没有形成稳定基线贸然开启 AUTO 模式容易造成频繁误切换。第三备份恢复方案要提前验证。迁移过程中经常用到 dmp 导入导出主备集群、备份任务和迁移工具之间往往是联动的建议制定详细的操作手册把监视器状态确认、备份任务切换、应用连接池调整这整个链路全部串起来。最后我把话收个尾做达梦数据守护集群运维这几年我最大的体会是高可用方案真正考验人的地方往往不是部署那一两次的成功而是长期运行中你能不能及时发现问题、准确判断状态、在关键时刻做出正确决策。监视器这个工具就是帮你把“看不见”变成“看得见”把“凭经验猜”变成“看数据说”。如果你现在正准备上一套数据守护集群我建议你从第一天就把监视器装好、日志开全、切换演练排进日程。如果你已经上了但还没认真看过监视器状态今天就可以先登录进去敲一条 show global info 看看集群的真实健康状况。别等故障找上门来才想起这个值班班长已经被你晾了三个月。