达梦主备集群：重启与主备切换 · 交互版

目标：先弄清监视器跑在哪一台机器上，再记下它的程序路径与加载的配置文件——后面连接、启停都靠它们。

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

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

# 2) 本机没有？看有没有注册成系统服务（确认监视器基本都是服务常驻）
systemctl list-units --type=service | grep -i DmMonitor
# 命中示例：DmMonitorServiceDBMM.service  loaded active running

# 3) 服务方式起的，命令与参数从服务定义里看
systemctl cat DmMonitorServiceDBMM | grep ExecStart

# 4) 辅助佐证：谁在写监视器日志，监视器就在哪台
ls -lt --time-style=+'%m-%d %H:%M' /dmdata/dmmon/DAMENG/log/ | head -3

确认在这台之后：再记下程序路径与 path= 后面的配置路径。

# 进程行里同时给出这两段：
# dmdba 1624 1 0 18:13 ? 00:00:07 /home/dmdba/dmdbms/bin/dmmonitor \
#   path=/dmdata/dmmon/DAMENG/dmmonitor_auto.ini
#   ↑ 程序本体（软件目录 bin/ 下）        ↑ 它加载的配置

• 目录规律：达梦所有可执行文件都在软件目录的 bin/ 子目录下——dmserver、dmmonitor、disql、dmrman 无一例外。bin/ 前面那段就是这台机器的软件目录。
• 确认软件目录：echo $DM_HOME；数据与配置目录看 ps -ef | grep dmserver 输出里 dm.ini 所在路径。两者通常是分开的（本演示：软件在 /home/dmdba/dmdbms，数据与配置在 /dmdata）。
• 陷阱一：有程序、有配置 ≠ 有进程。集群部署时主备两台通常都装全了软件，bin/dmmonitor 两台都在；配置文件也可能两台各留一份。只有 ps 里的进程行（或服务状态 active running）才算"监视器跑在这台"。
  实测（本演示环境）：主库 135 上 /home/dmdba/dmdbms/bin/dmmonitor 文件存在、dmmonitor_manual.ini 也在，但 ps 里只有 dmwatcher 和 dmserver，没有监视器；真正的确认监视器在备库 136，是系统服务 DmMonitorServiceDBMM 拉起来的。照"有配置就是这台"去判断，100% 判反。
• 陷阱二：dmmonitor（两个 m）不是 dmonitor。少写一个 m 时，ps -ef | grep dmonitor 只会匹配到 grep 自己那一行——看起来像"监视器根本没跑"，实际进程一直好好在跑。这一步搜错，后面全跟着错。
• 两台都找不到怎么办：别急着认定"集群没监视器"。① 监视器可能装在第三台机器上（生产上推荐独立部署）——查部署台账或逐台 ps；② 也可能当前压根没起，那就自己起一个普通监视器（下一步），效果一样。只要配置里 [GRP1] 段的 MON_DW_IP 指向集群两个守护进程地址，在任意一台装了达梦的机器上起监视器都能管整个组——这才是"从哪个节点连都一样"的正确含义（说的是连守护进程，不是 ps 查进程）。
• 程序路径与配置路径各现场不同（/home/dmdba/dmdbms/bin/…、/opt/dmdbms/bin/…、/dmdata/… 都常见），一律以你自己 ps 输出里那一段为准，别照搬示例。

目标：进入监视器交互界面，后续所有管理命令都在 [monitor] 提示符下执行。

# 先进到配置文件所在目录
cd /dmdata/dmmon/DAMENG

# 复制一份配置，只把 MON_DW_CONFIRM 改成 0 —— 这就是普通监视器，能与确认监视器共存
sed 's/^MON_DW_CONFIRM.*/MON_DW_CONFIRM = 0/' dmmonitor.ini > dmmonitor_normal.ini
# 本演示环境已有现成的 dmmonitor_manual.ini（= 0），效果相同，直接用即可

# 用这份普通监视器配置启动（程序路径换成步骤 1 记下的那段）
/home/dmdba/dmdbms/bin/dmmonitor path=/dmdata/dmmon/DAMENG/dmmonitor_normal.ini

# 回车后提示符变为：
[monitor]

# 退出监视器用 exit（写 quit 会报"输入命令非法"）

• 为什么先复制一份配置：确认监视器全局只能有一个。如果集群已经把确认监视器做成服务在跑（很常见），再用同一份 MON_DW_CONFIRM = 1 的配置启动，会被直接顶回来——Exist multiple CONFIRM dmmonitor, can only startup one!。把 MON_DW_CONFIRM 改成 0，就是普通监视器，随时可以再起、与确认监视器并存不冲突。
• 判断依据只有这一个参数：配置文件里 MON_DW_CONFIRM，0 或未配置＝普通（非确认）监视器，1＝确认监视器。两个监视器的启动命令一模一样，差别只在这个值。别拿文件名猜——现场叫 dmmonitor_auto.ini 的那份经常就是 = 1，叫 dmmonitor_manual.ini 的才是 = 0；连之前先 grep MON_DW_CONFIRM 配置文件 看一眼。
• 为什么普通监视器够用：它不承担自动接管职责，但状态查看与人工管理命令（stop group / startup group / switchover）都能执行——计划内重启与切换完全足够。不要为了操作去停正在服务的确认监视器，那会制造「无确认监视器」的风险窗口。
• 什么时候必须用确认监视器：需要「主库故障后由监视器自动选出备库接管」时。此时要另配一份 MON_DW_CONFIRM = 1 的配置并常驻运行；只做计划内维护则不必。
• 小坑：配置文件属主。用 dmdba 启动、而 ini 属主是 root 时，会先打印一行 os_file_open_normal_rw error! ... Permission denied——不影响读取和后续操作，但很容易被误认为启动失败。把 ini 属主改成运行用户即可消除。
• show / login / stop group 这些是监视器内部命令，必须敲在 [monitor] 提示符下——敲进 Linux shell 只会 command not found。

目标：重启前先确认集群是健康的：实例 OPEN、角色正确、主备日志同步到位。

# [monitor] 提示符下执行（不需要 login）
show

# 真实输出是「一个实例一个表块」，完整列序为：
# WTIME  WSTATUS  INST_OK  INAME  ISTATUS  IMODE  RSTAT  N_OPEN  FLSN  CLSN
# 下面只摘关键列，对照着看你自己的输出：
# INAME        ISTATUS  IMODE    RSTAT  N_OPEN  FLSN   CLSN
# DB1          OPEN     PRIMARY  VALID  8       51662  51662
# DB2          OPEN     STANDBY  NULL   8       51662  51662   ← 备库侧 RSTAT 可能为 NULL

• 四个判读点：① ISTATUS 与 IMODE 都是 OPEN；② IMODE 一主一备（PRIMARY / STANDBY）——主备角色看 IMODE，不是 RSTAT；③ RSTAT 只作参考：主库侧通常 VALID，备库侧实测可能为 NULL（switchover 切回后持续 NULL，实例仍正常 OPEN），它表示 REDO 有效性，不是健康红线；④ 两侧 FLSN / CLSN 一致。
• FLSN/CLSN 是主备日志同步进度。业务已停的停机窗口内两侧应基本一致；业务在跑时有少量差值属正常（备库重演有毫秒级延迟），差值持续扩大才是异常。
• 组信息在实例表块之后：往下还有一段 GROUP / OGUID / MON_CONFIRM / MODE / MPP_FLAG——核对组名、OGUID，以及「当前这个监视器是不是确认模式」，看这一段最快（本页用普通监视器，这里应是 FALSE）。
• 更细诊断用 tip：逐实例报告运行是否正常、能否被其他实例加入，末尾给一句「所有组中的活动实例运行正常」。

目标：停止、启动、切换都是管理类命令，必须先登录监视器，否则会被拒绝。

# [monitor] 提示符下执行
login
# 会连着问两行：先「用户名:」再「密码:」（口令不回显）
# 成功后输出：登录监视器成功!

• show / tip 这类查看命令不需要登录；stop group / switchover 这类管理操作必须登录，未登录会被拒绝并提示 未登录监视器或服务器公钥发生变化，请重新登录!
• switchover 的登录校验在二次确认之后：敲完 YES 才检查登录状态——没登录的话等于白答一次确认，切换根本不会执行。所以顺序一定是「先 login，再 switchover」。
• 停组之后 login 一定失败，别以为是口令错：实例全停时敲 login 会得到 当前没有活动实例或守护进程状态不匹配(不是STARTUP/OPEN/RECOVERY状态)，登录信息校验失败——此时直接执行 startup group 就行，它不校验登录；等实例起来再 login 做切换。

目标：一条命令停掉整个守护组（主备实例 + 守护进程），顺序由监视器保证。

# [monitor] 提示符下、已 login 后执行
stop group

# 组名可省略；显式写等价
stop group GRP1

# 监视器按实例逐个推进（先主后备），逐条打印进度（实测输出）：
# STOP实例DB1[PRIMARY, OPEN, ISTAT_SAME:TRUE]的守护进程
# STOP实例DB1[PRIMARY, OPEN, ISTAT_SAME:TRUE]的守护进程成功
# STOP实例DB2[STANDBY, OPEN, ISTAT_SAME:TRUE]的守护进程成功
# 通知实例(DB1)SHUTDOWN
# 通知实例(DB1)SHUTDOWN成功，请等待实例完全退出
# 通知实例(DB2)SHUTDOWN成功，请等待实例完全退出
# 通知组(GRP1)的守护进程执行清理操作
# 退出组(GRP1)中所有活动实例成功

• 这一步会真正停库，业务中断。务必先确认已进入停机窗口、应用侧已断开连接。
• 停的次序（先主后备）由监视器自动保证，不需要手工干预。
• 没有二次确认：实测敲完 stop group GRP1 回车就直接执行，不会再问 Y/N——手别抖，敲之前确认窗口已开。
• 耗时：两节点实测约 20 秒（20:20:42 开始，20:21:02 输出「退出组(GRP1)中所有活动实例成功」）。
• 怎么确认真的停了：别只看监视器输出，回到操作系统查 ps -ef | grep dmserver 应无实例进程、ss -lnt | grep 5666 无监听，两个 DmServiceDMSERVER* 单元变成 inactive (dead)。
• 守护进程（dmwatcher）不会随之消失：实测停组后 watcher 进程仍在、对应 systemd 单元仍是 active——这正是下面 startup group 能成功的前提。

目标：一条命令拉起整个守护组；备库会自动跟主库走。

# [monitor] 提示符下、已 login 后执行
startup group GRP1

# 一个监视器只配一组时，组名可省略，等价：
startup group

# 实测输出是逐条日志，不是 show 那种表格：
# STARTUP实例DB1[PRIMARY, SHUTDOWN, ISTAT_SAME:TRUE]的守护进程
# 守护进程(DB1)状态切换 [SHUTDOWN-->STARTUP]
# 实例DB1的守护进程配置有自动拉起，请等待守护进程将其自动拉起
# STARTUP实例DB2[STANDBY, SHUTDOWN, ISTAT_SAME:TRUE]的守护进程
# 启动组(GRP1)中的所有实例成功
# 实测约 20~25 秒后恢复：DB1 OPEN/PRIMARY、DB2 OPEN/STANDBY

• GRP1 这个组名从哪来：不是随手起的，它就是监视器配置文件里的组段名——打开配置文件能看到一行 [GRP1]，下面列着本组的 MON_DW_IP（各守护进程的 IP:PORT）。组名改了，命令里的 GRP1 也必须跟着改。
• 同段里还有 OGUID：MON_INST_OGUID 必须与各节点 dmwatcher.ini 里的 INST_OGUID 完全一致，否则监视器连不上守护进程。
• 组名可以省略：监视器自己的命令帮助写的就是 startup group [group_name]——方括号即可选。实时主备/读写分离一个监视器只配一组，省略与写上等价；多组并存（如 MPP 主备）时必须指定。
• 这条命令是让 dmwatcher 去拉起实例，不是监视器自己起进程。若 dmwatcher 没在跑，会报 监视器还未收到组(GRP1)的守护进程消息，并以「启动组(GRP1)中的所有实例失败」告终——这时先把两节点的守护进程服务起起来，再回来敲 startup group。
• 不要看到「ERROR」就以为失败：启动过渡期 show 会短暂显示 WSTATUS=STARTUP、ISTATUS=SHUTDOWN、INST_OK=ERROR，这是实例还没 OPEN 的正常中间态，等 20~25 秒再看。
• 实例已经在跑会怎样：监视器逐个报告 实例DB1[PRIMARY, OPEN, ISTAT_SAME:TRUE]已经处于运行状态，末尾补一句「不符合启动组(GRP1)中的所有实例条件」——不会重启实例，也不会报错退出。
• 命令不对称：停是 stop group，起是 startup group——写成 start group 会被监视器直接拒绝（输入命令非法）。
• 只有不走监视器、改用操作系统服务分别启停 dmwatcher/dmserver 时，才需要自己把关启动顺序。

目标：计划内维护做主备角色互换：不丢数据，原备库升主、原主库降备。

# 前置：两实例均 OPEN、（停机窗口内）FLSN/CLSN 基本一致、已 login
switchover
# 不写参数即可：监视器自动挑当前备库，并在确认提示里把目标填好

# 二次确认（实测文案，目标由监视器填）：
# 此操作需谨慎, 将会导致主库发生切换, 是否继续使用GRP1.DB2执行SWITCHOVER操作(YES/NO/Y/N)?
Y

# 回答 Y 后逐条跑完（实测全程约 4 秒）：
# 守护进程(DB1)状态切换 [OPEN-->SWITCHOVER]
# 实例DB1 / DB2 执行 SP_SET_GLOBAL_DW_STATUS(0, 6) 成功
# ALTER DATABASE MOUNT → 原主降 STANDBY、原备升 PRIMARY → ALTER DATABASE OPEN FORCE

• 目标可以不写：实测直接敲 switchover 就能切，监视器自动选当前备库，并把目标填进确认提示（格式 组名.实例名，如 GRP1.DB2）。要显式指定就按这个格式写 switchover GRP1.DB2；目标是将被升为 PRIMARY 的备库，写成当前主库没有意义，写成不存在的名字会被拒：实例名(xxx)无效或尚未收到实例消息! 外加一句「输入命令非法」。
• 实测耗时与结果：从回答 Y 到两实例重新 OPEN 约 4 秒（20:21:56.3 → 20:21:57.0）。本次连切两次（DB1→DB2、再切回 DB1），每次都回到库内用 v$instance 的 MODE 复核 PRIMARY / STANDBY 确已互换，两侧 FLSN=CLSN。
• switchover vs takeover：switchover 用于计划内切换（主备都健康，不丢数据）；takeover 用于主库故障后备库强行顶上（可能丢数据）。不要混用。
• 登录校验在二次确认之后：未登录时答完 YES 只会得到 未登录监视器或服务器公钥发生变化，请重新登录!，切换不会执行。实例刚重启过尤其容易掉登录态，动手前重新 login 一次。

目标：确认集群回到健康状态，收工。

# [monitor] 提示符下执行
show

# 共同项（两种情形都要满足）：
# 1) 两个实例的 ISTATUS 都是 OPEN
# 2) FLSN / CLSN 重新趋于一致（备库追平需要一点时间）
#    RSTAT 主库侧 VALID、备库侧可能 NULL，不作为判据
#
# 角色项（看 IMODE，按你走到哪一步挑一组核对，别套错）：
# A 只重启、没做第 7 步 → 角色应保持原样：DB1 仍 PRIMARY、DB2 仍 STANDBY
# B 做过第 7 步切换   → 角色应已互换：DB1 变 STANDBY、DB2 变 PRIMARY

• 标准别套错：没做第 7 步却看到角色变了，或者做了切换角色却没变，都算异常——先看 show 的 IMODE 列和实例日志，别急着收工。
• 若此时业务已恢复写入，FLSN/CLSN 有少量差值属正常——「一致」要在「业务已停」前提下看才算数。