2026-10-04  ·  高可用与集群

达梦主备集群:重启与切换的完整操作

高可用与集群

📋 想照着做?这篇有 交互操作版——左侧步骤卡片导航、命令一键复制,现场照着敲更方便:打开交互操作版 →

不想看文字?这里有 2 分 23 秒的视频演示
真实环境下的主备集群重启与切换全流程 —— 从查状态到 stop group / startup group / switchover,八步实操

不想看视频?这篇就是它的文字版。
配套视频演示的是真实环境下的操作,下面把每一步拆开写清楚 —— 可以照着做,也可以用来快速定位某一步。


一、先认清演示环境

这一节只是为了让你看懂后面的输出示例。你的环境路径和实例名大概率不同,照着换成自己的即可。

角色实例名IP守护状态
主库DB139192.168.16.139PRIMARY
备库DB138192.168.16.138STANDBY

后面每处需要替换成你自己环境的,我都会标出来。

先记住达梦的这条目录约定

达梦所有可执行文件,都在「软件安装目录」的 bin/ 子目录下。
dmserver、dmmonitor(监视器)、disql、dmap、dmrman…… 一个都没有例外。

安装目录的目录名惯例就叫 dmdbms —— Linux 上默认装到 /opt/dmdbms,也常见 /home/dmdba/dmdbms。上面演示环境因为单独做了目录规划,装在了 /data/dmdata,所以监视器是 /data/dmdata/bin/dmmonitor。

记住这个规律就够了:bin/ 前面那一段,就是这台机器上的安装目录,换成你自己的即可。

生产环境建议:软件和数据放开两个目录

业界通行做法是把软件目录和数据目录彻底分开,例如:

/u01/dmdbms/     ← 只放软件(约 2–3 GB):bin/、jar/、tool/、jdk/、doc/
/u02/dmdata/     ← 只放数据:数据文件、控制文件、联机日志、归档、备份

这么做有两个实实在在的好处:

  1. 升级更安全 —— 换版本时只替换软件目录,数据目录一个字节都不动;万一新版本有问题,回退旧软件目录就能恢复
  2. 扩容更方便 —— 数据目录可以单独挂一块大容量、高 IOPS 的盘;软件目录不用跟着搬

⚠️ 反过来说:不要把数据库软件装在数据目录下面。 数据目录是业务数据的地盘,混进软件文件后,做备份、迁移、磁盘扩容时都会变得很别扭。

想知道自己这台机器装在哪,两条命令:

# 1) 软件目录
echo $DM_HOME

# 2) 数据目录(dmserver 的 ps 输出里 path= 指向实例的 dm.ini,它所在目录就是实例目录)
ps -ef | grep dmserver

二、重启前:先确认集群是健康的

第 1 步:先确定监视器跑在哪台服务器上

ps 只能看见本机进程 —— 监视器是一个独立进程,只存在于启动它的那台机器上。你在主库上查不到它是正常的:它可能跑在备库,也可能跑在独立部署的第三台机器上。

# 0) 先确认"我现在在哪台机器上"(多节点环境最容易漏的一步)
hostname; hostname -I

# 1) 查本机有没有监视器进程([d] 写法能避开 grep 自己那一行)
ps -ef | grep -i '[d]mmonitor'

# 2) 本机没有?看有没有注册成系统服务(确认监视器基本都是服务常驻)
systemctl list-units --type=service | grep -i DmMonitor

# 3) 辅助佐证:谁在写监视器日志,监视器就在哪台
ls -lt /dmdata/dmmon/DAMENG/log/ | head -3

别被"有程序、有配置"骗了。 集群部署时主备两台通常都装全了软件,bin/dmmonitor 两台都有;配置文件也可能各留一份。只有 ps 里的进程行(或服务状态 active running)才能证明"监视器跑在这台"。
实测:主库 135 上 /home/dmdba/dmdbms/bin/dmmonitor 文件存在、dmmonitor_manual.ini 也在,但 ps 里只有 dmwatcher 和 dmserver —— 真正的确认监视器跑在备库 136,由系统服务 DmMonitorServiceDBMM 拉起。

两台都找不到也不必执着:只要手上有一份配置,在任意一台装了达梦的机器上起一个普通监视器即可(见第 3 步)。配置里 [GRP1] 段的 MON_DW_IP 指向集群所有守护进程地址,所以从哪台机器起监视器都能管整个组 —— 这才是"从哪个节点连都一样"的正确含义(说的是连守护进程,不是 ps 查进程)。

第 2 步:找到监视器进程和它的配置路径

监视器通常不在 PATH 里,先把它揪出来:

ps -ef | grep dmmonitor

会看到类似这样一行,记下它:

dmdba  1015  1  0 Dec17 ?  00:00:06 /data/dmdata/bin/dmmonitor path=/data/dmdata/dmmon/DAMENG/dmmonitor_auto.ini

这一行信息量很大,拆开看:

片段含义
dmdba运行监视器的系统用户
/data/dmdata/bin/dmmonitor监视器程序本体 —— 在软件安装目录的 bin/ 下($DM_HOME/bin/dmmonitor)
path=/data/dmdata/dmmon/DAMENG/dmmonitor_auto.ini它加载的配置文件(可以放在数据目录,和软件分开)

第 3 步:连上监视器

把上面那行里的 path= 去掉,剩下的整串就是启动命令:

/data/dmdata/bin/dmmonitor path=/data/dmdata/dmmon/DAMENG/dmmonitor_auto.ini

💡 路径太长懒得手打?用 Tab 补全。 演示里就是这么做的:

[dmdba@db139 ~]$ /data/dmdata/bin/dmmonitor /data/dmdata/dmmon/DAMENG/dmmonitor_
dmmonitor_auto.ini    dmmonitor_manual.ini

敲到 dmmonitor_ 连按两下 Tab,它会列出该目录下的候选。这里有两个:
dmmonitor_auto.ini 是自动模式配置,dmmonitor_manual.ini 是手动模式配置 —— 演示用的是 auto。

回车后进入监视器自己的交互界面,提示符会变成:

[monitor]

⚠️ 注意:后面所有命令都是在 [monitor] 提示符下敲的,不是操作系统命令,别敲到 shell 里去。

第 4 步:看一眼集群状态

show

输出长这样:

WTIME 2024-12-18 00:56:24  RTSTATUS 0  INST_OK  NAME DB138  STATUS OPEN  RISTAT OPEN  RSTAT STANDBY  VALID 3  FLSN 47822  CLSN 47822
WTIME 2024-12-18 00:56:24  RTSTATUS 0  INST_OK  NAME DB139  STATUS OPEN  RISTAT OPEN  RSTAT PRIMARY  VALID 3  FLSN 47822  CLSN 47822

只要盯住三个字段:

字段正常值说明
STATUSOPEN实例处于打开状态
RSTATPRIMARY / STANDBY实例的主备角色
FLSN / CLSN两侧基本一致主备数据同步进度 —— 这是最关键的一项

这两个数值怎么判读(重要)

场景现象说明
业务已停、无新写入(停机窗口内)两侧 FLSN/CLSN 几乎完全一致✅ 这才是可以放心重启的状态
业务还在跑两侧有一点差值✅ 正常 —— 备库重演本来就有毫秒级延迟
业务在跑、且差值持续扩大差值越拉越大⚠️ 备库跟不上,先排查归档链路再动手

一句话:"一致"要在"业务已停"的前提下看才算数。业务在跑时两侧数值不同,不代表集群有问题。

想看更细的诊断信息:

tip

它会输出每个实例的详细状态,以及监视器的模式提示。特别注意这一条:

[TIP] This monitor is not in CONFIRM mode. If PRIMARY instance error occurs in AUTO switch mode,
      this monitor cannot do auto takeover!!!

这句话的意思是:监视器当前不在 CONFIRM 模式。如果此时主库故障,监视器虽然会走自动切换(AUTO),但无法完成自动接管。生产环境要特别留意这个提示。


三、停止主备集群

第 5 步:先登录监视器

管理类命令(停止、启动、切换)必须先登录,否则会被拒绝:

login

按提示输入数据库管理员账号和口令(如 SYSDBA)。

第 6 步:停止整个守护组

stop group

监视器会按顺序执行:

Stop dmmonitor process of instance DB139[PRIMARY, OPEN, ISTAT_SAME_TRUE]
Stop dmmonitor process of instance DB138[STANDBY, OPEN, ISTAT_SAME_TRUE]
Notify instance[dmdba] shutdown
Instance DB139 shutdown success, please wait
Instance DB138 shutdown success, please wait

顺序是:先停主库(DB139),再停备库(DB138)。 监视器自己会保证这个次序,不用手工干预。

⚠️ 这一步会真正停掉数据库,业务会中断。 生产环境务必先确认已进入停机窗口,并且应用侧已经断开连接。


四、启动主备集群

第 7 步:启动整个守护组

startup group GRP1

⚠️ 注意命令不对称:停用的是 stop group,启动用的是 startup group —— 不是 start group。
写成 start group 监视器会直接回「输入命令非法」,并提示正确用法。这是实测踩过的坑。

输出(监视器会逐条推进守护进程与实例状态):

STARTUP实例GRP1_RT_02[PRIMARY, SHUTDOWN]的守护进程
守护进程(GRP1_RT_02)状态切换 [SHUTDOWN-->STARTUP]
STARTUP实例GRP1_RT_01[STANDBY, SHUTDOWN]的守护进程
守护进程(GRP1_RT_01)状态切换 [SHUTDOWN-->STARTUP]
...
STARTUP  OK  GRP1_RT_02  OPEN  PRIMARY  VALID
STARTUP  OK  GRP1_RT_01  OPEN  STANDBY

这个先后顺序同样由监视器自动保证,不需要手工干预 —— 备库会跟着主库走,主库没起来时它会先等待。

⚠️ 只有当你不用监视器、改用操作系统服务分别启停 dmwatcher / dmserver 时,才需要自己注意启动顺序。

第 8 步:再确认一次状态

show

验收标准:


五、主备切换

重启完成后,如果要做计划内的主备角色互换,用的是 switchover(区别于主库故障时的 takeover):

命令适用场景数据影响
switchover计划内切换,主备都健康不丢数据,角色互换
takeover主库故障、无法恢复备库强行顶上,可能丢数据

执行切换前必须确认三件事:

  1. 监视器里已经 login

💡 若刚才重启过实例,执行时可能提示
「未登录监视器或服务器公钥发生变化,请重新登录!」——
遇到就重新 login 一次即可(部分版本并不需要重新登录)。

  1. show 显示两个实例都是 OPEN;停机窗口内(业务已停)两侧 FLSN/CLSN 应基本一致
  2. 用普通监视器(MON_DW_CONFIRM = 0)同样可以执行 switchover

💡 两个容易搞错的点

① 不必为了操作监视器而停掉确认监视器。 一个集群只能有一个确认监视器,
但可以有多个普通监视器。普通监视器"仅用于监控守护系统状态与执行手动切换命令"
(官方原文),stop group / startup group / switchover 都能用。
需要临时操作时,复制一份配置把 MON_DW_CONFIRM 改成 0 起一个即可 ——
停掉正在服务的确认监视器反而会制造一段"无确认监视器"的风险窗口。

# 用普通监视器配置连上去(可与其他监视器共存)
sed 's/^MON_DW_CONFIRM.*/MON_DW_CONFIRM = 0/' dmmonitor.ini > dmmonitor_normal.ini
./dmmonitor path=./dmmonitor_normal.ini

② DW_MODE = AUTO 不影响计划内切换。 AUTO 只决定"主库故障时备库是否自动接管",
与人工发起 switchover 无关 —— 实测在 AUTO 模式下执行 switchover 完全正常。

切换命令会要求二次确认,输入 YES 后才真正执行:

此操作需谨慎, 将会导致主库发生切换, 是否继续使用GRP1.GRP1_RT_01执行SWITCHOVER操作(YES/NO/Y/N)?
YES

切换完成后同样用 show 确认:新的主库 RSTAT 变为 PRIMARY,原主库转为 STANDBY。


六、命令速查

操作系统层面

# 找到监视器进程与配置路径
ps -ef | grep dmmonitor

# 确认本机软件安装目录(可执行文件在它的 bin/ 下)
echo $DM_HOME

# 连上监视器($DM_HOME/bin/dmmonitor,路径换成你自己环境的)
/data/dmdata/bin/dmmonitor /data/dmdata/dmmon/DAMENG/dmmonitor_auto.ini

监视器交互界面内([monitor] 提示符下)

命令作用是否需要先登录
show查看各实例状态(STATUS / RSTAT / FLSN / CLSN)不需要
tip查看监视器与实例的详细诊断信息不需要
login登录监视器(管理操作的前置)—
stop group停止整个守护组(先主后备)需要
start group启动整个守护组(先主后备)需要
switchover计划内主备切换需要

七、四个容易踩的坑

1. 把监视器命令敲到了 shell 里。
show、login 这些是监视器内部命令,必须先在 [monitor] 提示符下才能用。在 Linux shell 里敲 show 只会报 command not found。

2. 没确认 FLSN/CLSN 就动手。
⚠️ 先分清场景:业务还在跑时,两侧 FLSN/CLSN 有一点差值本来就正常,不必卡着不动;
但在停机窗口内(业务已停、无新写入)两侧应当基本一致 —— 若此时仍明显不一致,说明备库有积压没追平,
贸然停库会拉长重启后的追平时间,期间集群不可用。先等它追平再操作。

3. 忽略了 not in CONFIRM mode 的警告。
这条 TIP 决定了主库真出故障时,监视器能不能自动接管。如果你依赖自动切换,务必按官方文档把监视器配成 CONFIRM 模式;只是做计划内维护的话,看到它就不用紧张。

4. 照抄别人环境里的路径。
达梦的安装目录没有唯一答案 —— /opt/dmdbms、/home/dmdba/dmdbms、/dm8、/u01/dmdbms、/data/dmdata 都见过。唯一不变的是:可执行文件一定在安装目录的 bin/ 下。
抄命令前先 echo $DM_HOME 确认自己的软件目录,别拿着本文演示环境的 /data/dmdata 硬敲 —— 十有八九会 No such file or directory。


看视频版 → 本文顶部同一篇文章内嵌的录屏演示(3 分 15 秒)

微信扫码添加 JC 微信扫码加我
备注「达梦」

卡在某一步了?

先对着 交互版 过一遍,每一步都有实测输出。还对不上,把卡在第几步、报错原文、版本号发我 —— 这三样就够判断了,不用发 dm.ini 或任何配置文件。

邮件:jiang-chuang@qq.com

现象和这几步都对不上?说明可能是版本或环境差异,把已经试过的命令和结果说一下,我能判断是文档该补,还是得单独看。
想让答案别人也能查到?在 Gitee 仓库 提 issue,回复公开可查。

← 返回目录