达梦确认监视器为何一定要部署在主备服务器以外的服务器

在达梦数据库数据守护集群的日常运维中，确认监视器是一个容易被忽视却至关重要的组件。很多初次接触达梦数据守护集群的 DBA 都会问一个核心问题：确认监视器为什么一定要部署在主、备服务器之外的独立服务器上？

一、确认监视器的核心作用
首先，我们回顾一下确认监视器的两个关键功能：

1. 故障自动切换的裁决者：当主库发生故障时，确认监视器负责判断是否满足切换条件，并向备库下达切换命令，使其升级为新的主库。
2. 脑裂的终极防御机制：在网络分区场景下，确认监视器通过仲裁机制，确保集群中能存在单一主角色能够继续提供服务。

二、部署在主库/备库上的致命风险
如果将确认监视器与主库或某个备库部署在同一台物理服务器上，将面临以下严重问题：
1.单点故障无法自动切换
假设监视器与主库共用服务器A。当服务器A发生硬件故障（如主板烧毁、电源损坏）或操作系统崩溃时：
• 主库进程挂掉（或无法访问）
• 监视器进程也随之挂掉（在同一台物理机上）
结果：集群失去了监视器。备库虽然存活，但监视器无法下达切换指令，自动故障切换失败，业务持续中断，直到人工介入。

故障模拟：
假设主库和确认监视器部署在同一台DM1服务器，DM1宕机

DM1 服务器宕机

备库没有自动切换成主库

2.脑裂问题
考虑经典的分区场景：主库所在的服务器A与备库所在的服务器B之间的网络中断，但两台服务器本身均正常。 监视器误判主库故障，自动将备库切换为主库，此时出现了双主状态。

故障模拟：
假设备库和确认监视器部署在同一台DM1服务器
模拟主库与备库之间的网络分区
iptables -A INPUT -s 192.168.3.247 -j DROP

检查DMSVR1状态，已从备库open切换成主库open状态

检查DMSVR02状态，从主库open状态切换成主库Suspend状态

3.资源争抢与性能干扰
监视器需要定期发送心跳、接收状态消息、进行切换决策。若与数据库实例共用服务器：
• 当数据库高负载（如大量排序、刷盘）时，监视器的决策可能被延迟。
• 监视器的网络心跳包可能被影响，导致误判（如将正常的主库标记为超时）。

https://eco.dameng.com