DSC 共享存储故障原因分析

达梦数据共享集群的核心不是多份数据靠日志追平，而是多个实例共同访问同一份数据。数据文件、控制文件、联机日志和归档，最终都落在共享存储上。因此，一旦共享存储出现 I/O 超时、路径漂移、空间写满或元数据不一致，集群往往会直接进入踢节点、强制停库、卡在恢复阶段等严重状态。

1. 共享存储对DSC至关重要

DSC 的控制面和数据面都依赖共享盘：

层次	组件	依赖的共享存储	异常时常见表现
控制面	DMCSS	DCR 盘、VOTE 盘	心跳丢失、节点被剔除、SYS HALT
存储面	DMASM	ASM 磁盘组（DATA / LOG / ARCH）	磁盘组 OFFLINE、连接 ASM 失败
数据面	DMSERVER	数据文件、控制文件、REDO、归档	页 I/O 超时、卡在 After Redo、实例被强制停止

DMCSS 会通过 VOTE 盘写入和读取心跳。共享存储延迟一旦超过集群可容忍阈值，控制节点不会等，而是为了保护整体可用性，对故障节点下发强制停止。这就是DSC的架构设计，共享存储不可用时，继续让该节点读写，风险高于踢出该节点。

2. 物理与硬件层面的原因

这是导致共享存储故障最直接的一类，具体表现为 I/O 响应严重超时或中断。

2.1 I/O 超时与性能瓶颈

存储设备本身性能不足、阵列高负载、备份窗口与业务高峰重叠，都会让 I/O 请求堆积。

于本地虚拟机两节点 DSC 异常复盘中，日志呈现出非常典型的恶化曲线：

数据页 I/O 等待从超过 3 秒恶化到 27 秒，随后飙升至 87 秒
重做日志刷盘等待从 18 秒 恶化到 78 秒
随后收到 CSS 下发的 SYS HALT，实例被强制踢出，以保障集群整体可用性

备份任务、全表扫描、大批量归档切换，都可能在同一时间把共享盘打满。在处理时，不能只盯着数据库进程，要同步看存储延迟、队列深度和备份窗口。

2.2 硬件故障与链路抖动

磁盘损坏、HBA 卡故障、光纤线缆松动、交换机端口闪断、多路径（multipath）抖动，都会让磁盘心跳异常。集群监视器里常见类似描述：

0 号磁盘组的 0 号核心数据盘 I/O 异常

操作系统侧则可能出现 sd 设备 reset、mpath 路径 failed/reinstated、HBA link down 等记录。这类问题的特点是：数据库日志只是结果，根因在链路。

2.3 磁盘空间耗尽

这一条经常被忽略，后果却很重。归档日志、ASM 磁盘组、文件系统配额一旦写满：

日志应用中断
节点可能卡在 After Redo，无法完全 OPEN
服务表现为“进程还在，业务已经不可用”

DSC 的归档必须规划在共享存储（ASM 磁盘组或共享文件系统）上，并且要有空间上限与定期清理策略。单机思路里“本地 /dmarch 写满再扩”在 DSC 上会直接变成集群级故障。

3. 配置与环境层面

很多故障并不是硬件坏了，而是配置或环境导致共享存储访问异常。

3.1 磁盘识别与权限

Linux 重启后，/dev/sdb、/dev/sdc 这类盘符可能改变。如果 dmdcr.ini、udev、raw 绑定依赖盘符而不是 UUID / WWID / 多路径别名，节点就会找不到 DCR、VOTE 或 ASM 盘。

另外，多节点对同一块共享盘的属主、属组、权限必须一致（通常 dmdba:dinstall，权限满足 ASM/CSS 读写）。一个节点 660、另一个节点 640，或 SELinux/权限不一致，都会表现为“这台机器起不来，那台机器却正常”。

3.2 网络与虚拟化

DSC 至少要区分：

业务网：对外提供数据库服务
MAL / 心跳网：节点间通信与状态判定
存储网：主机到共享存储

心跳不通或延迟过高，也可能被判定为存储/节点故障。虚拟化环境（尤其 VMware）还要注意共享盘相关参数，例如 .vmx 中的 disk.locking、SCSI 总线共享模式、磁盘置备方式。配置不正确，轻则识别不到共享盘，重则多节点同时锁定导致 I/O 异常。

3.3 时间不同步与启动顺序

节点间时间差过大会干扰心跳时间戳和故障判定。NTP/chrony 必须稳定。

DSC 服务有严格启动顺序：

CSS  →  ASM  →  数据库实例（DMSERVER）

停止顺序相反：

DMSERVER  →  ASM  →  CSS

顺序错误时，最常见的报错是 ASM 连接失败、failed to connect dmasmtool、数据库起不来。若配置了 CSS 自动拉起 ASM/DB，也要确认拉起命令和依赖服务注册正确，避免半自动半手动把顺序打乱。

4. 集群逻辑与运维层面

4.1 集群元数据不一致

典型路径：

某节点因故障被剔除
其他节点继续更新 DCR / 控制文件 / 数据页
故障节点本地配置仍停留在旧状态
该节点带着之前的信息重新加入，因配置不匹配无法启动

处理原则是：以共享存储上的集群控制信息为准，先用监视器看清组状态，再决定是重加入、修复配置，还是按流程做节点恢复。不要在未确认 DCR/控制文件状态时，用本地旧文件“覆盖回去”。

4.2 关键文件位置错误或损坏

归档误配到本地路径：备份、恢复、节点重加入会缺日志
手动删除数据文件，却未同步更新控制文件 dm.ctl：实例启动失败
DCR / VOTE 被误初始化、误格式化：整个集群信息被破坏

4.3 虚拟机快照回滚

对 DSC 节点做快照回滚非常危险：虚拟机本地状态回到过去，共享存储仍停留，必然造成元数据撕裂。生产 DSC 禁止对单节点做快照回滚来“快速恢复”。

5. 分层排查思路

出现问题后，按下面顺序取证，每一层都先留日志和命令输出，再决定是否重启。

物理硬件 / 存储链路
        ↓
操作系统 / 多路径 / 网络 / 时钟
        ↓
集群配置（DCR、ASM、归档、权限）
        ↓
集群状态与数据库日志（CSS / ASM / 实例）

重点检查三项：

I/O 性能：iostat 看延迟和队列，判断是不是性能瓶颈
关键配置：各节点 dmdcr.ini 身份正确、磁盘用 UUID/WWID、归档在共享存储
集群状态：监视器里节点、磁盘组、是否正在故障处理

下面进入可执行的上机验证。路径、服务名、磁盘名请按现场替换；示例以两节点 DSC、DMASM、安装目录 /dmdbms 为基准。

6. 上机验证

6.1 验证一：集群状态（控制面）

目的： 先分清是“整簇存储挂了”还是“单节点被踢”。

# 进程是否还在
ps -ef | grep -E 'dmcss|dmasmsvr|dmserver' | grep -v grep

# 服务状态（服务名以实际注册为准）
/dmdbms/bin/DmCSSServiceCSS status
/dmdbms/bin/DmASMSvrServiceASM status
/dmdbms/bin/DmServiceDMS status

启动监视器（独立终端，不要和业务操作混在一起）：

/dmdbms/bin/dmcssm ini_path=/dmdbms/config/dmcssm.ini

在监视器中重点看：

各节点 CSS / ASM / DB 是 Open 还是故障处理中
是否有节点被剔除、是否正在重加入
是否提示磁盘组或核心数据盘 I/O 异常

通过标准： 至少有一个节点的 CSS 为控制节点且状态正常；若全部 CSS 异常，优先怀疑 DCR/VOTE 或存储链路，而不是先重启数据库。

6.2 验证二：共享盘还能看见、路径有没有发生漂移（硬件 + OS）

目的： 确认盘在、路径稳定、权限一致。

lsblk -o NAME,SIZE,TYPE,WWN,SERIAL,UUID
blkid
multipath -ll
ls -l /dev/mapper/asm-* /dev/dm/asm-* 2>/dev/null

对比两节点：

同一块 LUN 的 WWN / UUID 必须相同
绑定后的稳定路径（/dev/mapper/... 或 /dev/dm/asm-...）必须相同
属主属组建议均为 dmdba:dinstall

检查 udev / 多路径是否用 UUID 而不是 sdX：

grep -nE 'sd[a-z]|UUID|wwid|alias' /etc/udev/rules.d/* /etc/multipath.conf 2>/dev/null
grep -nE 'sdb|sdc|/dev/sd' /dmdbms/dsc_config/dmdcr.ini /dmdbms/dsc_config/dmdcr_cfg.ini

通过标准： 配置文件中 DCR、VOTE、ASM_LOAD_PATH 指向稳定设备名；重启前后设备名不变。若仍写着 /dev/sdb，即使当前能用，也视为隐患。

查看内核与链路：

dmesg -T | grep -iE 'I/O error|reset|offline|mpath|fibre|qla|lpfc|link down' | tail -n 80
journalctl -k -b --no-pager | grep -iE 'I/O error|multipath|sd ' | tail -n 80

异常信号： 频繁 offline/reset、路径 failed 后又 reinstated，对应硬件或链路抖动，而不是单纯 SQL 慢。

6.3 验证三：I/O 是否超时（性能瓶颈）

目的： 用系统工具判断延迟和队列，对应复盘里“页 I/O 87 秒、刷盘 78 秒”这类问题。

安装 sysstat 后执行（持续 30 秒，间隔 1 秒）：

iostat -x 1 30 | tee iostat.txt

重点看共享盘对应设备（多路径看 dm-X 或 mpathX）：

指标	健康参考	危险信号
`await` / `r_await` / `w_await`	通常数毫秒到几十毫秒	持续数百毫秒，甚至秒级
`avgqu-sz`	低队列	长期高队列且 `await` 同时升高
`%util`	有余量	长期接近 100%，同时吞吐上不去

补充：

# 当前谁在做 I/O
iotop -o -b -n 5 2>/dev/null | tee iotop.txt

# 数据库内部等待（库可连时）
disql SYSDBA/Dameng@1234@127.0.0.1:15236 <<'SQL'
SELECT * FROM V$INSTANCE;
SELECT NAME, STATUS FROM V$DATABASE;
-- 等待与 I/O 相关视图以现场版本为准
SELECT * FROM V$SYSTEM_EVENT WHERE WAIT_CLASS LIKE '%I/O%' OR EVENT LIKE '%I/O%';
SQL

对照实例日志中的超时关键字：

grep -nE 'IO 操作耗时|disk write uses|disk read uses|SYS HALT|强制停止|After Redo|ASM' \
  /dmdata/*/log/*.log /dmdbms/log/*.log 2>/dev/null | tail -n 100

通过标准： 业务高峰 await 仍在存储 SLA 内；出现秒级等待必须升级存储/备份窗口，而不是只调数据库参数。

实验环境可选（生产禁止）： 在备份窗口用 dd 对非数据库盘加压，观察 DSC 日志是否出现页 I/O 超时。不要对 DCR/VOTE/DATA 盘做写入压测。

6.4 验证四：空间是否耗尽（归档 / ASM / 文件系统）

df -h
df -i

ASM 磁盘组（ASM 正常时）：

/dmdbms/bin/dmasmcmd

lsdg
lsdisk

或使用 dmasmtool 连接 ASM 查看磁盘组总容量、剩余容量、状态（ONLINE/OFFLINE）。

库内确认归档在共享路径，而不是本地盘：

SELECT ARCH_NAME, ARCH_TYPE, ARCH_DEST, ARCH_FILE_SIZE, ARCH_SPACE_LIMIT
FROM V$DM_ARCH_INI;

通过标准：

ARCH_DEST 指向 ASM 归档磁盘组（如 +DMARCH）或共享文件系统，而不是某节点独有的 /dmarch
归档有 SPACE_LIMIT，并有定期删除作业
ASM 磁盘组剩余空间满足业务峰值与备份恢复窗口

卡住 After Redo 时： 先查归档盘/日志盘是否写满、ASM 是否 OFFLINE，再谈重启。写满时重启会再次卡在同一阶段。

6.5 验证五：配置一致性、权限、时钟、心跳网

5a. 本机身份与 DCR 入口

# 两节点分别执行，重点对比 DMDCR_SEQNO、DMDCR_PATH
grep -vE '^\s*$|^\s*#' /dmdbms/dsc_config/dmdcr.ini

注意：

DMDCR_PATH 必须指向同一块 DCR 盘的稳定路径
DMDCR_SEQNO 两节点必须不同，且与 dmdcr_cfg.ini 中的节点顺序一致
DMDCR_MAL_PATH、DCR_EP_ASM_LOAD_PATH 扫描目录两节点应能扫到同一批 ASM 盘

5b. 权限

ls -l /dev/mapper/asm-* /dev/dm/asm-* 2>/dev/null
id dmdba

5c. 时钟

timedatectl
chronyc tracking 2>/dev/null || ntpq -p 2>/dev/null
# 两节点时间差应在秒级以内，生产建议亚秒到毫秒级

5d. 心跳与 MAL 网络

ping -c 20 10.10.10.2
# 有条件时测延迟抖动
ping -i 0.2 -c 50 10.10.10.2 | tee ping_hb.txt
ss -nltp | grep -E 'dmcss|dmasm|dmserver'

通过标准： 心跳丢包为 0、延迟稳定；防火墙关闭或端口已放行；两节点时间同步。

5e. 启动顺序抽查（实验或维护窗口）

手动启停时必须遵守顺序。检查服务依赖是否在注册 CSS 时正确绑定：

# 注册 ASM/DB 服务时应依赖 CSS（现场以实际 unit 名为准）
systemctl list-dependencies DmCSSServiceCSS.service
systemctl list-dependencies DmASMSvrServiceASM.service

错误顺序的典型报错：failed to connect dmasmtool、ASM 未起来就启库。

6.6 验证六：归档位置、控制文件、元数据

-- 数据文件是否都在共享 ASM 路径
SELECT ID, GROUP_ID, PATH, STATUS FROM V$DATAFILE;

-- 控制文件
SELECT * FROM V$CONTROLFILE;

操作系统侧确认没有人把 ASM 文件“当普通文件删掉”：

# 仅示例：实际以 ASM 工具查询文件列表为准
# 禁止在未备份、未走变更的情况下对 ASM 磁盘做 dd / wipefs / mkfs

节点重加入前，用监视器确认该节点 active 标记、故障处理是否结束。本地 dmdcr.ini 与 DCR 盘内容冲突时，以 DCR 为准，按官方重加入流程处理，不要用旧节点文件覆盖共享盘。

6.7 验证七：虚拟化与快照风险（VMware 等）

systemd-detect-virt

若为 vmware：

与虚拟化管理员核对：共享盘 SCSI 总线为 共享（multi-writer / physical sharing）
.vmx 中与磁盘锁相关的配置（如 disk.locking）符合达梦 DSC 对共享盘的要求
确认没有对 DSC 节点做独立快照回滚

通过标准： 共享盘允许多节点同时打开；禁止用快照把单节点时间线单独倒回。

6.8 验证八：用一次“日志对照”把原因归到三类之一

把同一时间窗口的四类日志放在一起看：

来源	看什么
实例日志	页 I/O 超时、刷盘等待、SYS HALT、After Redo
ASM 日志	心跳中断、磁盘 trim/I/O fail、收到 CSS 停止命令
CSS / 监视器	踢节点、磁盘组 0 号盘异常、故障处理
OS / 多路径 / 存储	reset、路径抖动

对照归类：

日志组合	归类
页 I/O 从数秒恶化到数十秒 + 存储 await 升高 + 备份窗口	物理/性能
multipath 抖动 + HBA link down + 监视器磁盘 I/O 异常	硬件/链路
df/ASM 写满 + After Redo	空间耗尽
重启后找不到盘 + 配置写 `/dev/sdX`	配置/盘符漂移
仅单节点权限/SEQNO 错误，另一节点正常	配置/权限/身份
启库报连不上 ASM，CSS 未先起	运维启动顺序
踢节点后再加入配置不匹配	元数据不一致
快照回滚后控制文件与数据页对不上	运维误操作

本机示例截图：

7. 处理方式

先取证，再操作。重启会丢掉 iostat、多路径抖动等瞬时证据。
先修存储链路和空间，再拉集群。盘不可用时反复拉起只会反复 SYS HALT。
单节点异常时，优先保证仍存活节点继续提供服务。
元数据冲突时以共享存储上的 DCR/控制信息为准，禁止用本地旧文件覆盖。

磁盘绑定使用 UUID / WWID / 多路径别名，不用 sdX
DCR、VOTE 与 DATA/LOG 物理隔离，避免业务高峰打死心跳盘
归档在共享存储，设空间上限和清理作业
备份窗口避开业务高峰，并对共享盘做持续 iostat/nmon 监控
心跳网独立，时钟同步
服务按 CSS → ASM → DB 注册依赖，生产开启规范的自动拉起
禁止对 DSC 节点做快照回滚
变更删除数据文件必须同步控制文件，并走备份