学习达梦集群时，先接触的是主备、读写分离和异步备库。这类集群的主线比较清晰：主库产生日志，备库接收并重演日志，监视器或客户端再参与切换、路由和访问控制。
但 DSC 不是这条路。DMDSC 的核心不是"多份数据互相同步"，而是"多个数据库实例共同访问同一份数据"。这也是学习 DSC 时最需要先扭转的地方：它不是主备的另一种写法，而是共享存储架构下的多实例协同。
本文基于两节点 DSC 学习记录和本地手册《DM8数据共享集群》整理，重点放在架构理解、组件职责、部署规划、关键配置影响和常见误区，不展开完整命令流水账。
一、整体认识：DSC 和主备不是一类集群
DMDSC，全称 DM Data Shared Cluster，也就是达梦数据共享集群。它的典型形态是：多个 DMSERVER 实例运行在不同主机上，通过共享存储访问同一套数据库文件；每个节点拥有自己的 CPU、内存和进程，但数据库数据文件、控制文件等核心文件位于共享存储上。
主备集群更像"多份数据靠日志追平"，DSC 更像"多个实例围绕一份数据协同工作"。因此 DSC 的关键问题不是日志怎么发给备库，而是多实例同时访问同一份数据时，如何处理缓存一致、全局锁、节点故障和共享存储管理。
来源： 《DM8数据共享集群》2.2.6 DMDSC 集群、2.2.2 共享存储。
可以用下面这个对比先建立直觉：
| 对比项 | 主备/读写分离 | DSC |
|---|---|---|
| 数据组织 | 主备各有数据副本，通过日志同步 | 多个实例共享同一份数据库文件 |
| 写入角色 | 通常主库负责写入 | 多个实例可同时提供服务 |
| 核心矛盾 | 日志传输、同步延迟、角色切换 | 缓存交换、全局锁、共享存储可靠性 |
| 关键组件 | watcher、monitor、MAL | DMSERVER、DMCSS、DMASM、DMCSSM |
这个对比也决定了学习重点。学主备时要多看归档、守护、监视器和服务名；学 DSC 时要多看共享存储、CSS、ASM、DCR/VOTE、缓存交换和节点状态。
二、DSC 由哪些部分组成
手册中对 DMDSC 的组成描述比较完整：它主要由数据库实例、共享存储、DMASM 或 DMASM 镜像、本地存储、通信网络、DMCSS 和 DMCSSM 等部分组成。
来源： 《DM8数据共享集群》2 DMDSC 概述、2.2 基本概念。
从学习角度看，可以把它拆成四层。
1. 数据库实例层：DMSERVER
DMSERVER 仍然是对外提供 SQL 服务的数据库实例。不同的是，在 DSC 中每个节点都运行自己的实例，实例之间不是主备关系，而是共同访问共享存储上的同一套数据库。
这意味着应用可以连接不同节点，节点也都能参与业务处理。系统吞吐能力可以通过多个实例承接请求提升，但前提是节点间协调成本不能过高。
2. 集群控制层：DMCSS
DMCSS 是集群同步服务，负责监控各节点运行状态，处理启动、故障、重加入等流程。每个 DSC 节点都需要配置 DMCSS 服务，这些 DMCSS 服务本身也组成一个 DMCSS 集群。
手册里提到，DMCSS 会通过 VOTE 磁盘或 DCRV 磁盘读取和写入心跳信息，并据此判断被监控对象状态。也就是说，DMCSS 不是简单的后台进程，它承担了集群控制面的职责。
来源： 《DM8数据共享集群》2.2.8 DM 集群同步服务、5 DMCSS 介绍。
3. 存储管理层：DMASM
DMASM 是 DM 自动存储管理器，可以理解为面向 DSC 共享块设备的专用分布式文件系统。它负责在块设备上管理磁盘组和文件，供数据库实例访问共享数据。
这里有个容易踩的点：DMASM 不是通用文件系统。应用程序一般不能像访问普通目录那样直接操作它，而是通过 DMASM 相关接口或工具管理。
来源： 《DM8数据共享集群》2.2.7 DM 自动存储管理器、10 DMASM 介绍。
4. 运维观察层：DMCSSM
DMCSSM 是集群监视器，用于查看集群状态、执行部分集群控制命令。它不直接承载业务数据，但对技术支持来说很重要，因为很多集群状态、故障处理、节点重加入都需要通过监视器观察。
来源： 《DM8数据共享集群》2.2.9 DM 集群监视器、15.1 DMCSSM 监视器。
三、部署规划先看三件事：存储、网络、节点角色
DSC 部署不是先写配置文件，而是先确认基础环境是否支撑这种架构。最重要的是共享存储、网络和节点规划。
1. 共享存储规划
DSC 依赖多台主机共同访问的共享存储。学习实验中常见规划会把盘划分为 DCR、VOTE、日志磁盘组、数据磁盘组等用途：
| 名称 | raw 路径 | 用途 | 空间 |
|---|---|---|---|
sdb |
/dev/raw/raw1 |
DCR，保存集群注册表和集群配置 | 1024M |
sdc |
/dev/raw/raw2 |
VOTE，表决盘，用于确定节点状态 | 1024M |
sdd |
/dev/raw/raw3 |
REDO LOG，存放实例日志相关内容 | 40960M |
sde |
/dev/raw/raw4 |
DATA，存放数据库数据 | 按数据量规划 |
-- |
/dev/raw |
DCR_EP_ASM_LOAD_PATH，ASM 磁盘扫描路径 |
路径配置 |
这张表可以把 DSC 的存储层先分成两类：一类是控制面，例如 DCR 和 VOTE，负责集群配置、心跳和节点判断；另一类是数据面，例如 REDO LOG 和 DATA，承载数据库日志和数据文件。控制面路径一旦错了，影响的是 CSS 和集群状态；数据面异常，则更多体现为 ASM 磁盘组、数据库实例或读写访问异常。
DCR 盘：集群配置和状态的基础
DCR 可以理解为 DSC 集群的配置注册区。初始化 DCR 时，dmasmcmd 会把 dmdcr_cfg.ini 中定义的集群组、节点名称、节点序号、端口、VOTE 路径等信息写到这里。后续 DMCSS、DMASM、DMSERVER 启动时，会通过 DCR 找到自己属于哪个组、自己是哪个节点、应该和哪些节点通信。
也就是说，DCR 里保存的是"这个集群应该长什么样"。它容量不需要很大，但路径必须稳定、内容必须可靠。如果 DCR 路径指错，或者重启后 raw 绑定漂移，CSS 可能读不到正确的集群配置，表现为集群无法正常启动、节点身份异常、组信息不正确，或者某个节点明明配置过却无法加入对应组。
VOTE 盘：节点心跳和故障判断依据
VOTE 是表决盘，主要服务于 DMCSS 的磁盘心跳机制。DMCSS、DMASM、DMSERVER 等被监控对象会定期在 VOTE 盘自己的区域写入状态、时间戳和命令执行结果。DMCSS 控制节点会周期性读取这些信息，判断节点是否还活着、是否需要启动故障处理、是否可以执行节点重加入。
所以 VOTE 盘本质上是"集群状态交换板"。它的容量同样不需要很大，但对稳定性要求高。它不适合和高 IO 数据文件混在一起承受压力，否则心跳写入或读取延迟可能导致误判。实际规划中，VOTE 和 DCR 经常单独划小盘，就是为了把集群控制信息和业务数据 IO 隔离开。
REDO LOG 盘：实例日志和恢复链路
REDO LOG 盘用于存放各实例的联机日志。DSC 虽然共享一份数据文件，但每个数据库实例都有自己的运行进程和日志记录。实例执行事务时，会把事务变化写入本实例对应的联机 REDO 日志；发生实例故障或节点恢复时，系统再依赖这些日志进行重做和恢复。
所以 REDO LOG 盘承载的是"每个实例做过什么修改"的恢复依据。日志盘 IO 太差，会影响事务提交和恢复效率；日志路径规划不清，也会增加故障排查难度。这里还要注意：DSC 共享的是数据文件，不代表所有实例共用同一个联机日志文件，各实例日志要按节点分别规划。
DATA 盘：数据库共享数据主体
DATA 盘承载数据库的数据文件、控制文件等主体内容，是 DSC 共享存储里容量需求最大的部分。各节点上的 DMSERVER 最终都会通过 ASM 访问这里的数据文件：查询时从这里读取数据页，修改后相关脏页也会落回这里。
所以 DATA 盘承载的是"所有实例共同操作的那份数据"。DATA 盘规划时要重点看容量、IO、链路冗余和扩展能力。它不是简单挂载一个大盘就结束，还要考虑 ASM 磁盘组管理、后续数据增长、存储故障以及多节点并发访问时的性能。
/dev/raw 扫描路径：ASM 如何找到这些盘
表里的 /dev/raw 对应 DCR_EP_ASM_LOAD_PATH，表示 ASM 启动时扫描裸设备的路径。ASM 会到这个目录下扫描 raw 设备，读取磁盘头信息，识别哪些设备属于 ASM 磁盘组，再把这些磁盘组提供给数据库实例使用。
所以这个路径决定了"ASM 去哪里找盘"。这里要注意两点：第一，DCR 和 VOTE 的路径通常在配置中明确指定，不能因为设备名变化而漂移；第二，DATA、REDO 等 ASM 磁盘虽然有磁盘头信息辅助识别，也仍然依赖正确的设备绑定和权限。生产环境一般会用 UUID、WWID、多路径别名或 udev 规则固定设备路径。
生产环境中，共享存储不只是"所有节点能看到同一块盘"这么简单，还要考虑设备路径稳定、IO 能力、链路冗余和故障隔离。实验环境可以用虚拟共享盘理解流程，但不能把实验网络和存储规划直接搬到生产。
来源： 《DM8数据共享集群》2.2.2 共享存储、17.3 心跳说明、17.10 块设备路径变化。
2. 网络规划
DMDSC 集群网络至少要区分对外服务网络、MAL 高速内网和共享存储网络。对外服务网络用于客户端连接，MAL 高速内网用于节点间通信，共享存储网络用于数据库实例和共享存储之间通信。
缓存交换、节点状态判断、实例间通信都对网络稳定性敏感。如果把业务访问、心跳和高速通信混在一起，排查时可能出现"业务流量影响集群判断"的问题。
来源： 《DM8数据共享集群》2.2.4 通信网络、2.2.11 MAL 链路。
3. 节点和组件规划
两节点 DSC 学习环境中，通常会有两个数据库实例、两个 CSS 服务、两个 ASM 服务，可选配置监视器。规划时要明确每个节点的 DMSERVER、DMCSS、DMASM 端口和序号，避免不同组件端口混淆。
我学习时比较容易混的是：CSS、ASM、DB 都是不同层次的组，它们在 dmdcr_cfg.ini 中有不同组类型和节点信息。不要只记住"有两个节点"，还要知道"哪个组有两个节点"。
来源： 《DM8数据共享集群》2.2.5 集群和集群组、9.1 DMDCR_CFG.INI。
四、几个关键配置文件分别影响什么
DSC 配置文件较多，如果只按步骤抄，搭完后仍可能不知道问题应该从哪里看。下面按"影响什么行为"来理解。
1. dmdcr_cfg.ini：集群总蓝图
dmdcr_cfg.ini 定义集群有哪些组、每个组有哪些节点、各节点的名称、序号、端口和心跳相关信息。它后续会写入 DCR 盘，因此可以理解为 DSC 集群的基础户籍信息。
这里配置错，影响的不是单个数据库参数，而是整个集群对成员关系的识别。例如节点名、节点序号、组类型、VOTE 路径或端口写错，都可能导致 CSS、ASM 或 DB 组无法按预期启动。
来源： 《DM8数据共享集群》9.1 DMDCR_CFG.INI。
2. dmdcr.ini：本机身份和 DCR 入口
dmdcr.ini 告诉本机服务去哪找 DCR、MAL 配置，以及当前节点的序号。它和 dmdcr_cfg.ini 的区别在于：dmdcr_cfg.ini 更像全局蓝图，dmdcr.ini 更像本机身份证。
两台机器的 dmdcr.ini 通常不会完全一样，尤其是本机节点序号。若本机序号配置错误，服务可能会以错误身份加入集群，后续 CSS、ASM、DB 组状态都会异常。
来源： 《DM8数据共享集群》9.2 DMDCR.INI。
3. dmasvrmal.ini：ASM 节点间通信
dmasvrmal.ini 主要描述 ASM 节点之间如何通过 MAL 通信。它影响的是 ASM 层面的节点通信，不要和数据库实例之间的 MAL 配置混为一谈。
如果 ASM 通信配置异常，可能表现为 ASM 服务无法正常协同、磁盘组管理异常，最终影响数据库实例访问共享存储。
来源： 《DM8数据共享集群》9.3 DMASVRMAL.INI、10 DMASM 介绍。
4. dminit.ini：初始化时决定共享数据结构
DSC 初始化时，数据文件、控制文件、日志文件路径和实例专属配置都需要提前规划。数据文件通常放在共享的数据磁盘组，联机日志则按实例分别规划。
这里要特别注意：初始化参数决定数据库底层结构，后面不能像普通文本配置一样随便改。页大小、大小写敏感、字符集、日志大小、数据路径等，都要在初始化前确认。
来源： 《DM8数据共享集群》12.1 基于 DMASM 的 DMDSC。
5. dmarch.ini：DSC 环境中的归档完整性
DSC 中每个节点都有自己的日志。为了恢复和备份时能够拿到完整日志，归档配置不能只按单机理解。手册中提到，DMDSC 集群可通过远程归档让任意节点访问到集群所有节点产生的完整归档日志。
所以 dmarch.ini 不只是"开归档"，它影响备份恢复、故障节点恢复、节点间归档可见性等问题。
来源： 《DM8备份与还原》2.1.1.2 远程归档、3.3.5.2.2.3 DMDSC 环境下的数据库恢复。
6. 核心配置项速查
DSC 文件多，参数也多，但真正影响集群能否启动、能否加入、能否恢复的，通常集中在这些位置。
dmdcr_cfg.ini：定义整个集群长什么样
DCR_N_GRP：定义集群组数量。CSS、ASM、DB 组都要被纳入规划，数量不匹配会影响 DCR 初始化后的组识别。DCR_VTD_PATH：指定 VOTE 磁盘路径。路径错误或重启后变化，会直接影响磁盘心跳和故障判断。DCR_OGUID：集群标识。同一套 DSC 内保持一致，不同集群不要复用，避免集群身份混乱。DCR_GRP_TYPE/DCR_GRP_NAME/DCR_GRP_N_EP：定义组类型、组名和组内节点数。CSS、ASM、DB 组要分清，不能只按"几台机器"理解。DCR_EP_NAME/DCR_EP_SEQNO：定义节点名称和节点序号。序号重复或错位，会导致节点身份异常。DCR_EP_HOST/DCR_EP_PORT：定义节点通信地址和端口。CSS、ASM、DB 各有自己的端口规划，端口混用会导致服务启动或通信异常。DCR_EP_SHM_SIZE/DCR_EP_ASM_LOAD_PATH：ASM 相关配置，影响 ASM 共享内存和裸设备扫描路径。
dmdcr.ini：定义本机是谁、从哪里读集群信息
DMDCR_PATH：指向 DCR 磁盘。路径不对，本机服务就找不到集群基础配置。DMDCR_SEQNO：本机节点序号。不同节点必须区分，并与全局配置中的节点顺序对应。DMDCR_MAL_PATH：指向 ASM 的 MAL 配置文件，影响 ASM 节点间通信配置加载。DMDCR_LINK_CHECK_IP：用于网络异常时辅助判断链路问题，降低误判和脑裂风险。DMDCR_ASM_STARTUP_CMD/DMDCR_DB_STARTUP_CMD：影响 CSS 是否能自动拉起 ASM 或 DB。初次搭建未完成前不宜过早启用，避免服务反复拉起失败。
dmasvrmal.ini：定义 ASM 节点之间怎么通信
MAL_INST_NAME：ASM 实例名，要和 ASM 组节点名称对应。MAL_HOST：ASM 节点通信地址，通常应走心跳或内部高速网络。MAL_PORT：ASM MAL 通信端口，要和 DB 实例 MAL 端口区分。
dminit.ini：决定 DSC 数据库的初始化结构
DCR_PATH/DCR_SEQNO：告诉初始化程序这是 DSC 环境，并指定从哪个节点发起初始化。SYSTEM_PATH/CTL_PATH/MAIN/ROLL/SYSTEM：决定共享数据文件和控制文件放在哪个 ASM 磁盘组。LOG_PATH：每个实例自己的联机日志路径。DSC 共享数据文件，但各实例日志要分别规划。CONFIG_PATH：每个实例生成配置文件的位置。多节点环境中不要把不同实例配置混在一起。PAGE_SIZE/EXTENT_SIZE/CASE_SENSITIVE/CHARSET：初始化后调整成本高，必须在建库前确认。
dm.ini 与 dmarch.ini：影响归档、恢复和节点日志完整性
ARCH_INI=1：启用归档配置文件。DSC 环境做备份恢复、故障恢复时通常绕不开归档。ARCH_TYPE=LOCAL：本地归档，用于保存本节点归档日志。ARCH_TYPE=REMOTE：远程归档，用于让节点间共享归档日志，保证恢复时能拿到完整日志链。ARCH_DEST/INCOMING_PATH：归档目的地和接收路径。远程归档路径要和对端真实本地归档路径对应，否则恢复时容易缺日志。ARCH_SPACE_LIMIT：归档空间上限。上限过小会导致归档清理过早，影响故障恢复和历史恢复能力。
dm_svc.conf：影响客户端如何连接 DSC
CLUSTER=(DSC)：告诉客户端这是 DSC 集群服务名。LOGIN_DSC_CTRL=(1)：登录时优先连接 DSC 控制节点，适合按集群控制节点管理连接入口的场景。LOGIN_MODE：影响客户端选择节点的方式。连接不上时，不要只查数据库端，也要确认客户端是否真的读取了这个服务名配置。
这些参数可以总结成一句话：dmdcr_cfg.ini 管集群蓝图，dmdcr.ini 管本机身份，dmasvrmal.ini 管 ASM 通信，dminit.ini 管初始化结构，dmarch.ini 管日志完整性，dm_svc.conf 管客户端入口。排查时先判断问题属于哪一层，再去看对应文件。
五、机制理解：缓存交换、全局锁、心跳
DSC 的机制可以先抓三个关键词：缓存交换、全局锁、心跳。
1. 缓存交换
多个实例共享同一份数据，但每个实例有自己的内存缓存。节点 A 修改过的数据页，节点 B 后续可能也需要访问。如果每次都从共享存储读取，性能会受影响。因此 DSC 引入缓存交换，让节点间尽可能通过网络传递 Buffer 数据页，减少磁盘访问。
这也是为什么 DSC 对 MAL 高速内网有要求。网络不稳定或延迟较高，会直接影响缓存交换效率。
来源： 《DM8数据共享集群》4.4 缓存交换。
2. 全局锁和并发协调
单机数据库只需要管理本实例内的锁和缓存；DSC 是多实例共享数据，必须把锁和资源访问提升到集群层面理解。否则两个节点同时访问或修改同一类资源，就可能出现一致性问题。
因此 DSC 的性能并不是节点越多越好。如果多个节点频繁争抢相同热点数据页，缓存交换和锁协调成本会上升，反而可能抵消扩展收益。
来源： 《DM8数据共享集群》4.2 封锁管理、4.4 缓存交换、17.2 性能调优相关说明。
3. 心跳与故障判断
DMCSS 依赖 VOTE 磁盘或 DCRV 磁盘上的心跳信息判断节点状态。被监控对象会定期写入状态信息，DMCSS 控制节点再读取这些信息，决定是否执行启动、故障处理或重加入。
这解释了为什么 VOTE/DCRV 盘不能随意和高 IO 数据文件混放。心跳盘如果被 IO 压力拖慢，集群可能误判节点异常。
来源： 《DM8数据共享集群》2.2.10 心跳机制、5.2 心跳信息、17.3 心跳说明。
六、常见误区
误区一：把 DSC 当成主备
DSC 不是主库写、备库追日志的模式。它的多个实例共同访问共享数据，重点在共享存储和全局协调。
因此，排查 DSC 问题时不要只盯"主备同步延迟"这类主备思路，而要看 CSS、ASM、DCR/VOTE、共享存储、缓存交换和节点状态。
误区二：只关注 DMSERVER，忽略 CSS 和 ASM
在单机部署中，数据库实例能启动基本就能进入下一步。但 DSC 中，DMSERVER 只是业务实例层。CSS 和 ASM 异常时，数据库实例即使有启动动作，也不代表集群可用。
建议排查时先确认 CSS，再确认 ASM，再看 DB 组和 DMSERVER。
误区三：只验证启动，不验证故障处理
DSC 的价值在高可用和多实例协同。如果只验证节点能启动、客户端能连接，学习是不完整的。至少还要观察节点停止、重加入、监视器状态、共享存储路径变化、网络异常时的表现。
误区四：忽略设备路径稳定
共享存储设备名变化会影响 DCR 和 VOTE 路径。即使 DMASM 文件系统本身可以通过块设备头信息识别 ASM 磁盘，DCR 和 VOTE 的路径仍然是配置中明确指定的。生产环境必须保证路径稳定。
来源： 《DM8数据共享集群》17.10 块设备路径变化。
七、排查思路：按层次看，不要一上来改配置
1. 先看存储层
确认共享存储是否所有节点可见，DCR/VOTE 路径是否稳定，DMASM 磁盘组状态是否正常。如果共享存储不稳定，上层数据库现象会非常混乱。
2. 再看 CSS 层
通过 CSS 或监视器查看集群状态，确认 DMCSS 控制节点是否正常、心跳是否正常、是否有故障节点或正在故障处理的节点。CSS 是集群控制层，很多后续动作都依赖它。
3. 再看 ASM 层
确认 DMASM 服务是否正常，磁盘组是否可用，数据文件所在磁盘组状态是否正常。ASM 层不稳，DMSERVER 对共享数据的访问就没有基础。
4. 最后看 DB 组和客户端
确认 DMSERVER 实例状态、归档状态、客户端连接配置和业务访问现象。如果只是客户端连不上，还要区分是服务名问题、端口问题、实例状态问题，还是集群状态问题。
可以把常见问题简化成几条判断：
- 节点无法加入：优先看节点序号、DCR 配置、CSS 状态、网络和共享存储。
- ASM 起不来：优先看裸设备路径、磁盘组、ASM MAL 配置和权限。
- DB 实例异常：优先看 ASM 是否正常、实例配置路径、归档和 DCR 信息。
- 运行卡顿：关注缓存交换、热点页、全局锁等待、MAL 网络和共享存储 IO。
- 故障处理不符合预期：看 DMCSS 状态、VOTE/DCRV 心跳、故障节点 active 标记和监视器输出。
来源： 《DM8数据共享集群》5.6 状态检测、5.7 故障处理、19.2 DMCSSM 接口。
八、继续深化的学习点
一、节点故障和重加入实验。重点记录故障前后 CSS、ASM、DB 组状态变化，而不是只记录"服务是否起来"。
二、共享存储路径变化或设备识别实验。这个对理解 DCR、VOTE、ASM 磁盘头信息很有帮助。
三、性能观察。通过热点表、多节点访问、等待事件和 IO 指标观察缓存交换、全局锁协调带来的影响。
九、总结
DSC 的学习重点不是背配置文件，而是理解它为什么需要这些配置。主备集群的主线是日志复制和角色切换，DSC 的主线是共享存储、多实例协同和集群控制。
把这条主线理清之后，DMCSS、DMASM、DMCSSM、DCR、VOTE、缓存交换、全局锁这些概念就不会再是散的名词。后续遇到 DSC 问题，也能先判断问题属于存储层、控制层、ASM 层、数据库实例层还是客户端访问层，再决定应该看哪个配置和哪类日志。
参考资料
- 本地手册：《DM8数据共享集群》《DM8备份与还原》