问题3：
主备集群下，数据库进程为什么要以mount状态启动，不以mount启动，主备集群能起来吗？
主备集群如何实现读写分离？读写分离的原理？结合例子说明。
监视器什么时候使用takeover ？什么时候使用switchover？有什么区别及风险？
如何检查主备库是否同步到一致？如果不一致怎么处理？
如何判断备库是否能追得上主库？监视器show展示的状态说明。flsn和clsn的区别

一、搭建指南

本文档的实操部分可以参考本人写的《达梦8两节点实时主备集群搭建与高可用测试》，该文章详细记录了从创建虚拟机、安装数据库到配置主备同步的完整过程，可作为搭建主备集群的参考依据。

参考链接：达梦8两节点实时主备集群搭建与高可用测试

二、为什么数据库进程必须以 MOUNT 状态启动？

数据守护系统启动时，所有数据库实例默认处于 MOUNT 状态，守护进程处于 Startup 状态。启动流程如下：

1. 实例以 MOUNT 状态启动，读取初始化参数文件，打开控制文件，分配共享内存，启动后台进程
2. 登录主数据库修改数据库模式为 PRIMARY，登录备数据库修改数据库模式为 STANDBY
3. 启动主备库上的守护进程
4. 监视器接管后，自动将实例从 MOUNT 切换到 OPEN 状态

不以 MOUNT 启动的后果：

• 如果在 OPEN 状态下修改数据库模式，会报错 [-720]: 守护进程处于活动状态，或当前配置(ALTER_MODE_STATUS)不允许该操作
• 守护进程无法正常管理实例状态，集群无法组建

关键操作（守护进程启动前完成）：

-- 主库
SP_SET_OGUID(453331);
ALTER DATABASE PRIMARY;

-- 备库
SP_SET_OGUID(453331);
ALTER DATABASE STANDBY;

踩坑点：必须在启动守护进程前完成模式设置，否则报错 [-720] Dmwatcher is active。

三、读写分离的原理与验证

读写分离集群在双机热备的基础上将用户写和读的会话事务分别放在主库和备库上执行。写事务被分发到主库执行，读事务分发到备库执行，由接口负责读写事务的分发。

实现原理：

• 主库（Primary）负责所有的写入和修改操作
• 备库（Standby）在实时同步主库数据的同时，帮主库分担查询（SELECT）的压力
• 客户端接口（如 DM JDBC、DPI 等）根据 dm_svc.conf 文件完成自动分流

实操验证：

在主库写入数据：

./disql SYSDBA/Admin2026@localhost:5237
CREATE TABLE test_rw (id INT, name VARCHAR(50));
INSERT INTO test_rw VALUES (1, 'read_write_test');
COMMIT;
SELECT * FROM test_rw;

输出：

操作已执行
影响行数 1
操作已执行

行号     ID          NAME           
---------- ----------- ---------------
1          1           read_write_test

在备库查询数据：

./disql SYSDBA/Admin2026@localhost:5236
SELECT * FROM test_rw;

输出：

行号     ID          NAME           
---------- ----------- ---------------
1          1           read_write_test

在备库尝试写入（应报错）：

INSERT INTO test_rw VALUES (2, 'should_fail');

报错：

[-710]: 试图在STANDBY模式下，修改用户库

结论：主库可读写，备库只读，读写分离验证通过。

四、监视器：TAKEOVER 与 SWITCHOVER

监视器（dmmonitor）是数据守护系统的重要组成部分，用于监控集群运行情况、获取主备库状态、执行管理命令。

4.1 TAKEOVER（故障接管）

使用场景：主库发生故障（进程崩溃、网络中断、硬件故障）时，将备库切换为主库继续对外提供服务。

触发方式：

• 自动接管：配置确认监视器且为自动切换模式时，确认监视器自动检测主库故障并通知备库接管
• 手动接管：在监视器中执行 takeover 命令

命令格式：

choose takeover GRP1
takeover GRP1.GRP1_RT_02

风险：可能存在数据丢失（主库未同步的 Redo 日志）；强制接管可能引发组分裂。

4.2 SWITCHOVER（计划内切换）

使用场景：计划内维护（软硬件升级、系统维护）时，主备库角色互换。

命令格式：

choose switchover GRP1
switchover GRP1.GRP1_RT_02

4.3 主备切换完整实操过程

步骤1：查看可切换的备库

在监视器命令行中输入：

choose switchover GRP1

输出：

Can choose one of the following instances to do switchover:
1: GRP1_RT_02

说明：系统列出了可切换的备库实例 GRP1_RT_02（对应 IP 192.168.201.90，端口 5237）。

步骤2：登录监视器

login

输出：

用户名: sysdba
密码:
[monitor] 登录监视器成功!

说明：监视器用户名默认为 sysdba，密码与数据库 SYSDBA 密码相同（本环境为 Admin2026）。

步骤3：执行切换

switchover GRP1.GRP1_RT_02

输出：

此操作需谨慎, 将会导致主库发生切换, 是否继续使用GRP1.GRP1_RT_02执行SWITCHOVER操作(YES/NO/Y/N)?
y
[monitor] 开始切换实例GRP1_RT_02
[monitor] 通知守护进程GRP1_RT_01切换SWITCHOVER状态
[monitor] 守护进程(GRP1_RT_01)状态切换 [OPEN-->SWITCHOVER]
[monitor] 切换守护进程GRP1_RT_01为SWITCHOVER状态成功
[monitor] 通知守护进程GRP1_RT_02切换SWITCHOVER状态
[monitor] 守护进程(GRP1_RT_02)状态切换 [OPEN-->SWITCHOVER]
[monitor] 切换守护进程GRP1_RT_02为SWITCHOVER状态成功
[monitor] 实例GRP1_RT_01开始执行ALTER DATABASE MOUNT语句
[monitor] 实例GRP1_RT_01执行ALTER DATABASE MOUNT语句成功
[monitor] 实例GRP1_RT_02开始执行ALTER DATABASE MOUNT语句
[monitor] 实例GRP1_RT_02执行ALTER DATABASE MOUNT语句成功
[monitor] 实例GRP1_RT_01开始执行ALTER DATABASE STANDBY语句
[monitor] 实例GRP1_RT_01执行ALTER DATABASE STANDBY语句成功
[monitor] 实例GRP1_RT_02开始执行ALTER DATABASE PRIMARY语句
[monitor] 实例GRP1_RT_02执行ALTER DATABASE PRIMARY语句成功
[monitor] 实例GRP1_RT_01开始执行ALTER DATABASE OPEN FORCE语句
[monitor] 实例GRP1_RT_01执行ALTER DATABASE OPEN FORCE语句成功
[monitor] 实例GRP1_RT_02开始执行ALTER DATABASE OPEN FORCE语句
[monitor] 实例GRP1_RT_02执行ALTER DATABASE OPEN FORCE语句成功
[monitor] 实例GRP1_RT_02切换成功

切换过程解读：

阶段	操作
1. 切换准备	两个守护进程从 OPEN 切换为 SWITCHOVER 状态
2. 挂起实例	主库和备库依次执行 ALTER DATABASE MOUNT
3. 角色互换	原主库降级为 STANDBY，原备库升级为 PRIMARY
4. 恢复服务	两个实例执行 ALTER DATABASE OPEN FORCE，切换完成

步骤4：验证切换结果

在监视器输入 show：

show

输出：

EP INFO:
INST_IP         INST_PORT  INST_OK   INAME            ISTATUS     IMODE     FLSN    CLSN
192.168.201.90  5237       OK        GRP1_RT_02       OPEN        PRIMARY   53889   53889
192.168.200.18  5236       OK        GRP1_RT_01       OPEN        STANDBY   53889   53889

切换后状态：

实例	端口	原角色	新角色	状态
GRP1_RT_02	5237	STANDBY	PRIMARY	OPEN
GRP1_RT_01	5236	PRIMARY	STANDBY	OPEN

步骤5：验证新主库可读写

./disql SYSDBA/Admin2026@localhost:5237
INSERT INTO test_rw VALUES (888, 'switchover_ok');
COMMIT;
SELECT * FROM test_rw WHERE ID=888;

输出：

影响行数 1
操作已执行

行号     ID          NAME         
---------- ----------- -------------
1          888         switchover_ok

步骤6：验证新备库只读

./disql SYSDBA/Admin2026@localhost:5236
INSERT INTO test_rw VALUES (999, 'should_fail');

报错：

[-710]: 试图在STANDBY模式下，修改用户库

4.4 TAKEOVER 与 SWITCHOVER 对比

对比项	TAKEOVER（故障接管）	SWITCHOVER（计划内切换）
触发方式	故障自动触发 或 手动命令	手动命令
场景	主库突发故障（宕机、网络中断）	计划内维护、升级
数据一致性	可能存在少量数据丢失	无数据丢失（切换前确保同步）
操作流程	备库直接升级为主库	先降级原主库，再升级备库
风险	可能引发组分裂	操作时主库有写入可能短暂阻塞

五、同步检查与状态理解

5.1 如何检查主备库同步一致

在监视器输入 show，对比主备库的 FLSN 和 CLSN。

正常输出：

EP INFO:
INST_IP         INST_PORT  INST_OK   INAME            ISTATUS     IMODE     FLSN    CLSN
192.168.200.18  5236       OK        GRP1_RT_01       OPEN        PRIMARY   53844   53844
192.168.201.90  5237       OK        GRP1_RT_02       OPEN        STANDBY   53844   53844

DATABASE(GRP1_RT_02) APPLY INFO FROM (GRP1_RT_01):
(RSEQ, SSEQ, KSEQ)[3224, 3224, 3224], (RLSN, SLSN, KLSN)[53844, 53844, 53844]

判断标准：

• 主备库 FLSN 完全相等 → 数据已持久化一致
• 主备库 CLSN 完全相等 → 日志已完全同步
• RSTAT = VALID → 复制状态正常
• 备库 APPLY INFO 中的 RLSN/SLSN/KLSN 与主库 CLSN 一致 → 日志应用完成

5.2 FLSN 和 CLSN 的区别

类型	全称	含义
CLSN	Current LSN	系统已经分配的最大 LSN 值，物理事务提交时分配
FLSN	File LSN	已经写入联机 Redo 日志文件的日志包的最大 LSN 值
RLSN	Redo LSN	备库已接收并重演的 LSN
SLSN	Send LSN	备库已接收的 LSN
KLSN	Keep LSN	备库已确认的 LSN

关系：

• 主库：CLSN ≥ FLSN（先产生日志，后持久化）
• 备库通过不断应用主库的 Redo 日志，使其 LSN 向主库的 LSN 逼近
• 当备库 FLSN == 主库 CLSN 时，数据完全同步

5.3 如何判断备库能否追上主库

方法：连续执行 show，观察备库 CLSN 变化趋势。

判断标准：

• 能追上：备库 CLSN 持续增加，最终等于主库 CLSN
• 追不上：备库 CLSN 停滞，或 RSTAT=INVALID

5.4 不一致怎么处理

自动追赶：备库 CLSN 持续增长且接近主库，无需干预。

追不上时排查：

1. 检查网络连通性：ping 备库IP
2. 检查 MAL 配置：确认 dmmal.ini 中 IP 和端口正确
3. 查看归档日志：ls -lh /data/dmarch1/
4. 查看监视器日志：tail -100 /data/dmlog/dmmonitor.log

重建备库（最可靠方案）：

# 主库联机备份
BACKUP DATABASE FULL BACKUPSET '/data/dmbackup/online_bak' ONLINE;

# 备库还原恢复
RESTORE DATABASE '/data/dmdata2/DAMENG/dm.ini' FROM BACKUPSET '/data/dmbackup/online_bak';
RECOVER DATABASE '/data/dmdata2/DAMENG/dm.ini' FROM BACKUPSET '/data/dmbackup/online_bak';
RECOVER DATABASE '/data/dmdata2/DAMENG/dm.ini' UPDATE DB_MAGIC;

5.5 监视器 show 状态字段说明

字段	含义	正常值
ISTATUS	实例运行状态	OPEN
IMODE	数据库模式	PRIMARY / STANDBY
RSTAT	复制状态	VALID
FLSN	已持久化日志位置（File LSN）	主备一致
CLSN	最新日志位置（Current LSN）	主备一致
INST_OK	实例是否正常	OK
WSTATUS	守护进程状态	OPEN
WCTLSTAT	守护进程控制状态	VALID

六、关键踩坑点与命令清单

关键踩坑点

踩坑点	说明
密码复杂度	必须含大小写字母和数字（如 Admin2026）
模式修改时机	必须在守护进程启动前设置 PRIMARY/STANDBY
备份前先启动	新初始化实例必须先正常启动一次，否则 dmrman 报错
INST_AUTO_RESTART	设为 1 时守护进程自动重启故障实例，不会触发 takeover
dmmal.ini	主库和备库内容必须完全一致
确认监视器数量	一个数据守护系统中，最多只能配置 1 个确认监视器

监视器常用命令

命令	说明
login	登录（用户名 sysdba，密码与数据库相同）
show	查看集群状态
tip	快速查看集群是否正常
choose takeover GRP1	查看可接管的备库
takeover GRP1.GRP1_RT_02	故障接管
choose switchover GRP1	查看可切换的备库
switchover GRP1.GRP1_RT_02	计划内切换

七、集群启动与关闭顺序

启动顺序：

1. 以 Mount 方式分别启动主、备数据库
2. 登录主库修改模式为 PRIMARY，登录备库修改模式为 STANDBY
3. 启动主备库上的守护进程
4. 启动监视器

关闭顺序：

1. 退出 DM 数据守护
2. 退出监视器
3. 关闭备机的守护进程
4. 关闭主机的守护进程
5. 关闭主机实例
6. 关闭备机实例