数据守护配置规范以及常见问题解决

本文档旨在员提供一份清晰的达梦数据库数据守护集群搭建操作规程、配置规范以及常见故障的排查与解决方法。遵循此规范有助于构建稳定、高效的高可用数据库集群。

1 搭建前期规划与规范

1.1 环境要求

项目	规范要求
操作系统	建议使用相同的Linux发行版和版本号（如CentOS 7.9/麒麟V10）。确保`/etc/hosts`配置正确，主机名唯一。
达梦版本	所有节点必须完全一致（包括版本号、补丁版本）。
硬件配置	主备库硬件配置（CPU、内存）应尽可能相同，避免备库性能成为瓶颈。
网络	节点间网络延迟应<1ms，万兆网最佳。禁用防火墙或为MAL端口、守护进程端口、实例端口配置安全策略。
磁盘规划	`dm.ini`、`ARCHIVE_LOCAL1`（本地归档）、`ARCHIVE_REALTIME2`（实时归档）路径需提前规划，确保磁盘空间充足。

1.2 端口规划规范

为避免端口冲突，请提前规划并记录以下端口：

端口类型	作用	规范示例 (可自定义)
数据库实例端口	应用连接数据库的端口	32141 (主库), 32142 (备库1), 32143 (备库2)
MAL系统端口	节点间内部通信端口	52141, 52142, 52143 (通常与实例端口错开)
守护进程端口	守护进程间通信端口	55141, 55142, 55143
监视器端口	连接监视器的端口	6363 (默认)

1.3 归档模式选择

模式	一致性	性能	适用场景	配置关键字
REALTIME	强一致 (RPO≈0)	中	通用高可用场景，要求数据零丢失	ARCHIVE_REALTIME
TIMELY	强一致 (RPO≈0)	中	REALTIME的替代，机制略有不同	ARCHIVE_TIMELY
ASYNC	最终一致 (RPO>0)	高	异地容灾、日志分析	ARCHIVE_ASYNC

规范建议：生产环境核心系统强烈建议使用 REALTIME 或 TIMELY 模式。

2 数据守护集群搭建步骤概要

2.1 环境准备

在所有节点安装相同版本的达梦数据库。
配置操作系统参数（ limits.conf、sysctl.conf ）。
配置主机名和hosts解析。
创建用户和组（ dmdba:dinstall）。

2.2 数据库初始化

使用 dminit初始化数据库。

./dminit PATH=/dm8/data PAGE_SIZE=32 EXTENT_SIZE=32 CASE_SENSITIVE=N

2.3 配置文件准备

dm.ini：配置INSTANCE_NAME、PORT_NUM、MAL_INI、ARCH_INI。
dmmal.ini：配置MAL系统，所有节点的MAL配置必须完全一致。
dmarch.ini：配置归档。主备库的归档配置是相互的。
dmwatcher.ini：配置守护进程。DW_TYPE需明确是 GLOBAL还是 LOCAL。
dmmonitor.ini：配置监视器。MON_INST_NUM必须与实际配置的 MON_DW_IPx数量一致。

2.4 启动顺序

启动主库的数据库服务。
启动备库的数据库服务（此时处于Mount状态，等待恢复）。
启动所有守护进程 (dmwatcher)。
启动监视器 (dmmonitor)。
在监视器上执行 login登录，然后执行 show查看状态。

3 常见问题与解决

3.1 监视器启动报错

报错：ON_INST_NUM(3) is larger than 1, but total instance number(2) is less than it!

原因：dmmonitor.ini中的 MON_INST_NUM参数值与实际配置的 MON_DW_IPx条目数量不一致。

**解决：**检查并修改 dmmonitor.ini，确保 MON_INST_NUM的值等于 MON_DW_IP1, MON_DW_IP2...的实际数量。

3.2 监视器持续刷`[mraft] vote start`日志，但无法选出 Leader

原因：通常是因为只启动了一个监视器节点，但配置中 MON_INST_NUM大于1。单个监视器无法形成多数派选举。
解决：

如果是测试环境单监视器，可忽略，但需知自动切换功能不可用。
如果是生产多监视器环境，请检查并启动其他监视器节点，并确保网络互通。

3.3 备库一直处于RECOVER或MOUNT状态，无法OPEN

原因：归档日志不连续、网络中断、或主备库的归档配置错误。
解决：

检查主备库之间的网络连通性（telnet <备库IP> <MAL_PORT>），关闭防火墙。
检查主备库 dmarch.ini配置，特别是 ARCH_DEST的IP、端口、归档路径是否正确。
在主库执行 select * from V$ARCHIVE_STATUS;，在备库执行 select * from V$ARCHIVE_APPLY;查看归档发送和应用状态。

3.4 备库归档无效

报错：监视器执行show命令查看发现备库的归档是Invalid状态。

原因：

主库归档已经被清理，备库需要的历史日志已经没有了。
或者主库归档有无连续情况，比如人为删除了中间归档文件。
或者备库收到日志后，连续性校验失败，拒收主库日志。
或者备库并不属于集群等。

解决：

先执行check recover命令查看未启动recovery的原因。
可以尝试执行set database [group_name.]db_name recover time time_value命令，临时缩短恢复间隔，比如5s，在5s后查看recovery情况，如果失败，日志中会记录失败信息。
如果上述执行临时缩短恢复间隔的方法没有出现recovery，如果出现了1800s的情况，一般需要认为干预，比如通过备份还原方式，重建备库，让主、备库能够恢复正常的日志同步。