企业官网建设流程全解析

1. 项目背景与整体架构

1.1 为什么需要DSC？它到底解决了什么问题

先聊点实在的。国产数据库这几年的热度不用我多说，达梦DM8作为信创圈子里出镜率最高的关系型数据库之一，单机部署大家基本都会弄。但到了真正的生产环境，单机再怎么优化也逃不过两个瓶颈：一是性能天花板，一个数据库实例能用的CPU、内存、IO吞吐终究有限；二是单点故障，机器挂了、磁盘坏了、机房断电，整个业务跟着停摆。

达梦的DSC（Data Shared Cluster，共享存储集群）解决的就是这两个问题。它的架构思路和Oracle RAC、人大金仓的共享存储集群属于同类方案：多个数据库实例，通过高速网络互连，共享同一套底层存储数据。任何一个节点故障，业务可以由剩余节点继续接管，应用几乎无感知。

这套方案在信创替代项目中很常见，尤其银行、政务、能源这些对连续性要求极高的行业。我这次搭建的是标准的DSC双节点架构，存储层采用IP SAN方式，由Openfiler系统提供共享块设备。很多人可能问，为什么不用本地磁盘？因为DSC靠的就是“多节点共享同一份数据”，没有共享存储，这个架构就无从谈起。

1.2 存储方案选型：为什么用Openfiler搭IP SAN

达梦DSC官方文档里，存储支持两大类：SAN存储和NAS存储。其中SAN存储又分FC SAN和IP SAN。生产环境用FC SAN很正常，光纤通道延迟低、带宽有保障，但人家那是需要独立的光纤交换机和HBA卡的，整套下来成本不低。我们做测试、做POC验证，或者做一些中小规模的项目落地，用IP SAN足够应付。

Openfiler是一个开源的存储管理操作系统，底层基于Linux，可以把它理解成一个“专门为存储而生的小型服务器系统”。它支持通过iSCSI协议对外提供块存储，也就是IP SAN。iSCSI的底层走TCP/IP网络，所以完全不需要专用的光纤链路，两根网线就能把存储网络撑起来，对实验环境来说性价比极高。

我在这次搭建中用Openfiler做了两块共享存储卷：

• 一块用来放DCR（达梦集群注册表）和ASM元数据，简单说就是集群的“大脑”和“记事本”；
• 一块用来放数据库的数据文件和日志文件。

这种划分思路和生产环境的规划逻辑是一致的：控制信息与数据信息分离，万一数据卷出问题要重建，不会把集群配置信息也一起冲掉。

1.3 整体拓扑与节点规划

先给大家看一下我这套环境的基础规划，后面所有的操作步骤都是围绕这个规划来的，你可以把它作为自己搭建时的一个模板参考。

两个数据库节点之间还需要一条心跳网络（私网互联），我这里单独划了192.168.162.x网段做集群内部通信。关于网络的规划，有几点提醒一下：

• 存储网络与业务网络尽量分离，避免数据备份或大查询拖垮存储链路;
• 心跳网络不要和业务网共用同一个网卡，多节点通信会产生大量的仲裁包，混在一起容易互相干扰；
• 每个节点至少准备两块网卡，一块走业务，一块走集群通信。

操作系统方面，两个节点统一用麒麟V10 SP1，达梦官方在这类国产化操作系统上的适配做得很成熟。内核参数、用户创建、环境变量这些准备步骤，我在下面会详细写清楚，照着做基本不会踩坑。

2. 环境准备与Openfiler存储配置

2.1 操作系统基础配置

这一步虽然琐碎，但直接影响后面集群能否稳定运行。我看过太多人集群起不来，最后排查根本不是达梦配置问题，而是系统层面缺东西。

先创建达梦专用用户。达梦不允许用root直接跑数据库实例，官方推荐单独建一个安装用户：

groupadd -g 12349 dinstall useradd -u 12345 -g dinstall -m -d /home/dmdba -s /bin/bash dmdba echo "dmdba@123" | passwd --stdin dmdba

然后调整系统资源限制。这一步很关键，集群场景下每个节点需要同时运行多个进程，文件句柄、进程数、栈大小这些参数不够的话，实例启动到一半就会报错：

cat >> /etc/security/limits.conf << EOF dmdba soft nofile 65536 dmdba hard nofile 65536 dmdba soft nproc 65536 dmdba hard nproc 65536 dmdba soft stack unlimited dmdba hard stack unlimited EOF

内核参数也要调，尤其是共享内存和信号量相关的：

cat >> /etc/sysctl.d/91-dm.conf << EOF kernel.sem=32000 1024000000 32000 1024 kernel.shmmax=34359738368 kernel.shmmin=1 kernel.shmmni=4096 kernel.shmall=8388608 fs.file-max=6815744 net.ipv4.ip_local_port_range=9000 65500 net.core.rmem_default=262144 net.core.wmem_default=262144 net.core.rmem_max=4194304 net.core.wmem_max=1048576 vm.swappiness=10 EOF sysctl -p /etc/sysctl.d/91-dm.conf

这里面kernel.sem那几个数字我解释一下，它的格式是SEMMSL SEMMNS SEMOPM SEMMNI，分别对应信号量最大值、系统信号量总数、每次操作信号量数和信号量集数量。默认值在单机场景没问题，但DSC每个节点会有多个实例进程，信号量不够的话进程间通信会直接失败，报“无法创建信号量”之类的错误。

两个节点之间还要配好/etc/hosts，确保主机名能互相解析：

192.168.162.101 dmdb01 192.168.162.102 dmdb02 192.168.162.200 openfiler

这里有个细节容易被忽略：hostname必须和/etc/hosts里的一致，而且两个节点的hostname不能相同。达梦DSC在注册节点时依赖主机名做区分，如果hostname重复，第二个节点加入集群时大概率会报节点ID冲突。

2.2 Openfiler创建IP SAN共享存储

Openfiler安装过程就不赘述了，ISO装完以后通过https://IP:446访问管理界面，默认账号是openfiler，密码也是openfiler，登录后第一步先改密码。

接下来是创建共享卷的全流程，我在Openfiler 2.99.x版本上操作，界面略有差异但核心逻辑一致。

第一步：设置卷组

进入“Volumes”页面，在“Volume Groups”区域创建一个新的卷组，卷组名称随意，比如dsc_vg。卷组创建时需要选择物理磁盘，我这里把系统盘之外的整块磁盘都放进了这个卷组。

第二步：创建物理卷

在卷组下面点击“Create a block device”，这里要选择“iSCSI”类型，系统会把这个卷包装成一个块设备，提供给iSCSI Target使用。我创建了两个物理卷：

• dsc_quorum：容量10G，用来放DCR和ASM元数据；
• dsc_data：容量150G，用来放数据库文件和日志。

提示：容量规划上，quorum卷不用太大，10G绰绰有余，DCR文件本身只有几十MB。数据卷的大小根据实际业务数据量来定，但如果两个节点要跑比较大的压测，建议给足余量。Openfiler对单卷大小没有强制限制，Linux LVM最大支持到PB级别，不用担心。

第三步：配置iSCSI Target

进入“SAN”页面，找到“iSCSI Target”配置区。Openfiler默认生成一个IQN标识（类似iqn.2001-04.com.openfiler:nas），需要新增两个Target，分别对应两块卷。每个Target设置一个唯一的名称，比如：

• iqn.2001-04.com.openfiler:server.dsc-quorum
• iqn.2001-04.com.openfiler:server.dsc-data

然后把对应卷映射到Target上，卷和Target的关联关系通过“LUN Mapping”完成。注意每个卷只能映射给一个Target，不能跨Target重复挂载同一块卷。

第四步：配置网络ACL

这是新手最容易忽略的一步。Openfiler默认不会允许任何客户端访问Target，必须在Target的“Network ACL”中把两个数据库节点的存储网IP加入白名单，否则后面用iscsiadm登录时一直超时，找不到原因。

我在实际操作中发现一个技巧：Openfiler的iSCSI服务偶尔会出现Target已配置但客户端发现不了的情况，多数原因是Openfiler的系统时间不对导致iSCSI协商失败。登录Openfiler后先检查时间，差太多就先校准再继续。

2.3 数据库节点的iSCSI客户端配置

两个数据库节点上安装iSCSI客户端工具并连接存储：

# 安装iSCSI客户端 yum install -y iscsi-initiator-utils # 设置Initiator名称（各节点建议用不同的名称） echo "InitiatorName=iqn.2025-01.com.dmdb:client1" > /etc/iscsi/initiatorname.iscsi # 发现Target iscsiadm -m discovery -t sendtargets -p 192.168.162.200 # 登录Target iscsiadm -m node -T iqn.2001-04.com.openfiler:server.dsc-quorum -p 192.168.162.200 -l iscsiadm -m node -T iqn.2001-04.com.openfiler:server.dsc-data -p 192.168.162.200 -l

登录成功后验证块设备是否正常显示：

lsblk | grep sdb

正常情况下会看到两个大小不同的磁盘设备。还需要确保iscsi服务开机自启：

systemctl enable iscsid iscsi systemctl start iscsid iscsi

到这里，两个数据库节点都已经能看到共享的块设备了。所谓“共享”，就是这两块盘在物理上只有一份数据，但通过iSCSI协议同时暴露给了两个服务器使用，DSC集群就是在这份共享数据上构建的。

3. 达梦DM8的安装准备与数据库软件部署

3.1 安装达梦数据库软件

达梦DM8的安装包有两种形态，一种是集成开发环境的完整ISO，一种是精简的二进制tar包。集群环境建议用完整安装包，里面带DMInstall图形化安装工具和dminit等命令行工具，后面很多配置都要用到。

将安装包上传到两个节点后解压：

mkdir /dm8 && cd /dm8 mount /opt/dm8_20230809_x86_kylin10_sp1.iso /mnt cp -r /mnt/* /dm8/ chown -R dmdba:dinstall /dm8

执行安装：

su - dmdba cd /dm8 ./DMInstall.bin -q # 静默安装

如果不想用命令行静默安装，也可以用图形界面。但在服务器上通常没有图形环境，所以习惯上我都是用-q参数配合响应文件来装。响应文件里面有几个关键参数：

安装路径=/dm8/dmdbms 数据库类型=典型安装 安装组件=服务器、客户端、监控工具

安装完成后，设置环境变量。达梦的环境变量很简单，就两个核心变量：

cat >> /home/dmdba/.bash_profile << EOF export DM_HOME=/dm8/dmdbms export PATH=$DM_HOME/bin:$PATH export LD_LIBRARY_PATH=$DM_HOME/bin:$LD_LIBRARY_PATH EOF source /home/dmdba/.bash_profile

两个节点都要装，步骤完全一样。

提示：达梦安装路径建议不要带中文和空格，否则后续DCR配置、ASM注册等环节容易出一些莫名其妙的路径问题。我见过有人装在/usr/local/dm database这种路径下，后续配置各种转义麻烦，最后重装了。

3.2 达梦DSC的组件架构理解

在动手配置之前，先花点时间把DSC的组件架构说清楚，因为很多人在配置时搞不清每个配置文件和进程的作用，后面出问题也不好排查。

达梦DSC集群由三类进程组成：

这三个进程的关系是这样的：DMCSS负责“管人”的，节点间互相探活、决定谁做老大；DMASM负责“管地”的，把裸设备格式化成达梦自己的ASM磁盘组，管理数据文件的分配和扩展；DMSERVER是“干活”的，用户在它上面跑SQL，它把数据通过DMASM写入共享磁盘。

对应到配置文件上：

• dmdcr_cfg.ini：描述集群节点的拓扑和资源分配，DMCSS读取;
• dmasvrmal.ini：DMASM实例的MAL通信配置，类似网络“名片”;
• dmmal.ini：数据库实例的MAL通信配置;
• dmarch.ini：归档配置，DSC环境必须开启归档。

启动顺序是严格的：先启动DMCSS，DMCSS启动成功后启动DMASM，DMASM把ASM磁盘组挂载后，最后才轮到DMSERVER。这个顺序乱了，任何一个环节都会失败。

3.3 共享存储的进一步分区与设备绑定

虽然Openfiler已经给了两块共享盘，但达梦DSC对存储设备有个明确要求：DCR和ASM磁盘必须使用裸设备。所谓裸设备，就是不能被文件系统格式化、不能被操作系统当普通文件管理的块设备，达梦进程直接读写这些设备的原始扇区。

具体操作是先看两个节点上识别到的共享盘是否一致：

# 节点1和节点2分别执行 lsblk --output NAME,SIZE,TYPE,SERIAL

确认两个节点的设备名和大小都一致，再继续。/dev/sdb和/dev/sdc在两个节点上必须对应同一个远端卷，如果发现设备名错位，一定要先修正。

达梦提供了一条命令来绑定裸设备，在安装包/dm8/dmdbms/bin下：

cd /dm8/dmdbms/bin ./dmsmcfg -LIST_DEV /dev/sdb ./dmsmcfg -LIST_DEV /dev/sdc

这条命令会返回一个RAW设备路径，类似/dev/raw/raw1和/dev/raw/raw2。达梦要求DCR和ASM磁盘通过这种RAW设备来访问，后续的配置文件中引用的也是这个RAW路径。

如果系统里没有自动创建RAW设备节点，需要手动执行绑定：

raw /dev/raw/raw1 /dev/sdb raw /dev/raw/raw2 /dev/sdc

注意：raw绑定是一次性的，重启后失效。需要写入开机自启脚本，否则服务器重启后达梦集群起不来。我在生产环境里是把raw绑定写进了/etc/rc.local，并且确保该文件有执行权限。

节点间用raw -qa确认绑定后的设备一致：

raw -qa

正常情况下输出应该显示/dev/raw/raw1绑定的主次设备号在两个节点上完全一致，这样底层才真正共享同一块物理盘。

4. DSC集群配置文件详细解析与实操流程

4.1 创建DCR配置文件

DCR配置文件是达梦DSC最核心的配置文件，它告诉DMCSS集群有哪些节点、每个节点的资源分配、DCR和ASM磁盘的路径、MAL端口等关键信息。

两个节点都需要创建dmdcr_cfg.ini，路径建议统一放在/dm8/dmdata目录下。配置文件内容如下：

DCR_GRP_NUM = 2 # ASM资源组定义 DCR_GRP_ASM = { GRP_TYPE = 0, GRP_NUM = 1, GRP_NAME = ASM, GRP_IPS = 192.168.162.101, 192.168.162.102, DCR_GRP_ASM_1 = { ASM_EXT_DEV = /dev/raw/raw1, ASM_VOL_PATH = /dev/raw/raw1 } } # 数据库资源组定义 DCR_GRP_DB = { GRP_TYPE = 1, GRP_NUM = 2, GRP_NAME = DSC, DCR_GRP_DB_1 = { DB_NAME = DSC1, DB_INSTNAME = DSC1, DB_IP = 192.168.162.101, DB_PORT = 5236, DB_MAL_PORT = 5266, DB_OGUID = 12345 }, DCR_GRP_DB_2 = { DB_NAME = DSC2, DB_INSTNAME = DSC2, DB_IP = 192.168.162.102, DB_PORT = 5236, DB_MAL_PORT = 5267, DB_OGUID = 12345 } } # DCR卷定义 DCR_CFG = { DCR_V_DISK = /dev/raw/raw1, DCR_FS_TYPE = DMASM, DCR_OGUID = 12345 } # ASM磁盘组定义 DCR_ASM = { ASM_D_VDISK = /dev/raw/raw1, ASM_D_FS_TYPE = DMASM }

这里有几个参数解释一下，方便你理解自己在配什么：

• DCR_GRP_NUM = 2：声明集群里有两类资源组，一类是ASM存储管理服务，一类是数据库实例
• GRP_TYPE：0代表ASM组，1代表数据库组；
• ASM_EXT_DEV：ASM实例用于管理外部存储的裸设备路径；
• DB_OGUID：集群的唯一标识，所有节点的OGUID必须一致，相当于集群的“暗号”；
• DCR_V_DISK：存放DCR信息的磁盘，我们用了第一块卷；
• ASM_D_VDISK：存放ASM元数据的磁盘。

OGUID这个参数经常被忽略，但其实非常重要。它有点类似Oracle集群里的Cluster名称，所有加入集群的节点必须用同一个OGUID，否则DMCSS之间探测不到对方，集群永远只有单节点在线。

4.2 创建DMASM实例配置文件

DMCSS起来之前，还需要先准备好DMASM实例的配置文件dmasvrmal.ini。每个节点各写一份，内容基本一致，但需要注意IP地址互相对应。

节点1的dmasvrmal.ini：

MAL_INST = 1 MAL_INST_NAME = ASM_01 MAL_HOST = 192.168.162.101 MAL_PORT = 7236 MAL_DW_PORT = 7237 [ASM_02] MAL_HOST = 192.168.162.102 MAL_PORT = 7236 MAL_DW_PORT = 7237

节点2的dmasvrmal.ini里，把MAL_INST改为2，MAL_INST_NAME改为ASM_02，MAL_HOST改为本节点的IP，[ASM_01]这一节的IP保持指向节点1。

MAL_PORT和MAL_DW_PORT是两个监听端口，一个用于正常的MAL消息通信，另一个用于数据写转发。这两个端口不要和其他进程的端口冲突，我遇到过有人把MAL端口配成了和数据库端口一样的5236，启动时直接报端口占用。

4.3 初始化DCR和DMASM磁盘组

所有配置文件就绪后，第一步操作是初始化DCR卷。使用达梦自带的dmdcr命令：

cd /dm8/dmdbms/bin ./dmdcr -i -c /dm8/dmdata/dmdcr_cfg.ini -p /dm8/dmdata/dcr_v_disk.txt

-i表示初始化模式，命令执行完成后，会在裸设备上写入DCR信息。-p参数指定的文件记录了初始化过程中的输出信息，供后续排查使用。

初始化成功后，接下来需要初始化ASM磁盘组。使用dmasmtool命令：

cd /dm8/dmdbms/bin ./dmasmtool DCR_INI=/dm8/dmdata/dcr_v_disk.txt

进入DMASM的命令交互界面后，创建磁盘组：

create diskgroup 'DSC_DATA' type normal disk '/dev/raw/raw2'

这里type normal表示普通冗余模式。达梦ASM磁盘组还支持external（外部冗余）和high（高冗余）模式。测试环境用normal就够了，生产环境如果底层存储本身有RAID保护，用external也行。normal模式会占用额外的磁盘空间做镜像，我这里的DSC_DATA卷有150G，normal模式下实际可用容量大约是75G。

初始化完成后退出dmasmtool，两个节点上可以执行以下命令验证ASM磁盘组是否可见：

./dmasmtool DCR_INI=/dm8/dmdata/dcr_v_disk.txt show diskgroup

在正常操作顺序下，这里有一个关键步骤需要特别注意：初始化DCR和ASM磁盘组必须在单节点上执行一次，并且只需要执行一次，两个节点不要分别初始化，否则会互相覆盖DCR信息。第二节点只需要等集群起来后自动加入。

4.4 注册并启动DMCSS服务

初始化完成后，在两个节点上都注册DMCSS系统服务：

cd /dm8/dmdbms/script/root ./dm_service_register.sh -t dmserver -p DMCSS -dmdcr_ini /dm8/dmdata/dmdcr.ini

这里的dmdcr.ini是DMCSS实例自身的配置文件，它和dmdcr_cfg.ini是两个不同的文件。dmdcr.ini内容示例如下：

DMDCR_HOME_PATH = /dm8/dmdata DMDCR_LOG_PATH = /dm8/dmdata/log DMDCR_CFG_PATH = /dm8/dmdata/dmdcr_cfg.ini DMDCR_SEQNO = 1

节点1的DMDCR_SEQNO为1，节点2为2。这个序号对应节点在集群中的编号，不建议随意乱填。

注册完成后启动服务。顺序很重要：先启动节点1的DMCSS，等节点1进入正常工作状态后，再启动节点2的DMCSS：

# 节点1 systemctl start DmServiceDMCSS # 观察日志确认启动成功 tail -f /dm8/dmdata/log/dmcss_DMCSS.log

节点1的DMCSS日志中看到类似DMCSS normal work的内容后，再去节点2执行同样的启动操作。

4.5 注册并启动DMASM、初始化数据库实例

DMCSS起来后，开始注册DMASM服务：

cd /dm8/dmdbms/script/root ./dm_service_register.sh -t dmasm -p ASM_01 -dmdcr_ini /dm8/dmdata/dmdcr.ini

同样，节点2上注册ASM_02。然后启动：

systemctl start DmServiceASM_01 systemctl start DmServiceASM_02

DMASM启动前的准备工作里，有一个在节点上创建数据库实例配置文件的过程。达梦DSC要求先用dminit初始化数据库实例，指定的ASM磁盘组就是刚才创建的DSC_DATA：

cd /dm8/dmdbms/bin ./dminit PATH=+DSC_DATA/ DATA_DESC=FILE DSC=Y

执行dminit只需要在集群的一个节点上执行即可。它会生成数据库的初始参数文件，存放在ASM磁盘组中，其他节点通过共享存储自动访问到这些文件。

数据库初始化成功后，还需要在节点上准备数据库实例运行所需的配置。以节点1为例，需要在/dm8/dmdata/DAMENG目录下准备dmmal.ini和dmarch.ini：

dmmal.ini内容：

MAL_INST = 1 MAL_INST_NAME = DSC1 MAL_HOST = 192.168.162.101 MAL_PORT = 5266 MAL_DW_PORT = 5267 [__DSC2] MAL_HOST = 192.168.162.102 MAL_PORT = 5266 MAL_DW_PORT = 5267

dmarch.ini内容：

ARCH_WAIT_APPLY = 0 [ARCHIVE_LOCAL1] ARCH_TYPE = LOCAL ARCH_DEST = +DSC_DATA/DSC1_ARCH ARCH_FILE_SIZE = 1024 ARCH_SPACE_LIMIT = 10240

注意：DSC环境必须开启归档模式，而且归档目录必须放在共享存储上（ASM磁盘组内），不能放在本地磁盘。原因很直接：节点1产生的事务日志需要同步给节点2做恢复，日志放在本地磁盘的话，节点2根本访问不到。

最后注册并启动数据库实例服务：

cd /dm8/dmdbms/script/root ./dm_service_register.sh -t dmserver -p DSC1 -dmdcr_ini /dm8/dmdata/dmdcr.ini systemctl start DmServiceDSC1

启动顺序同样是先节点1再节点2。节点2的实例启动后，DMCSS会自动协调两个节点完成集群组网，此时用disql登录任一节点的数据库：

su - dmdba disql SYSDBA/SYSDBA@192.168.162.101:5236

登录成功后在SQL提示符下执行：

SELECT NAME, INSTANCE_NAME, STATUS$ FROM V$INSTANCE;

如果看到两个实例都在，并且状态为OPEN，说明DSC双节点集群已经搭建成功并正常运行。

5. 常见故障排查与实操经验

5.1 DMCSS启动失败，日志报“无法连接对端节点”

这个故障在我搭建过程中出现过一次，现象是节点1的DMCSS能启动并正常等待，节点2的DMCSS启动时报错退出，日志提示无法连接对端。

排查步骤：

1. 确认两个节点之间网络互通：ping、telnet 192.168.162.101 7236;
2. 确认防火墙状态：达梦集群的端口范围较大，建议直接关闭iptables/firewalld，或者在防火墙中放行所有内部网段端口;
3. 确认/etc/hosts中主机名映射是否正确，hostname不一致时DMCSS解析对端节点会失败;
4. 检查两个节点的DCR配置是否一致，重点看DCR_OGUID和IP地址。

我的环境最终排查下来是防火墙没有放行7236/7237端口，关闭防火墙后问题立马解决。集群环境下，节点间的通信端口非常多，逐个放行很容易漏，直接按内网互信处理最省事。

5.2 DMASM启动失败，提示ASM磁盘组不可用

DMASM启动失败通常和裸设备绑定有关。观察日志发现无法在/dev/raw/raw1上读取ASM元数据。

排查思路：

1. 用dmasmtool手工尝试读取磁盘组信息，确认裸设备数据是否完整;
2. 确认两个节点看到的/dev/raw/raw1指向的是同一块物理盘。有一个容易踩的坑：Openfiler的Target顺序在不同节点重新发现后可能发生变化，导致sdb和sdc互换;
3. 确认裸设备的权限：ls -l /dev/raw/raw1，属主必须是dmdba，如果权限不对需要修改udev规则或手动chown;

这个故障的核心经验是：裸设备在重启后失效是很常见的问题，生产环境务必配置开机自动绑定，并且绑定命令里用物理盘的稳定标识（比如/dev/disk/by-path/下的路径），而不是/dev/sdb这种容易漂移的设备名。

5.3 双节点数据库实例无法同时打开

还有一种常见情况：节点1和节点2的实例都注册成功，但节点2启动时报“数据库已被其他实例打开”或类似错误。

这个问题的根源通常是OGUID不一致。OGUID是集群的唯一标识，所有节点必须相同。我的做法是在配置完成后，用如下命令检查节点各自读取到的OGUID：

./dmdcr -i -q -c /dm8/dmdata/dmdcr_cfg.ini

如果显示不一致，修改配置文件后需要重建DCR卷，再重新初始化ASM磁盘组。这里要特别提醒一句：重建DCR会让已经创建的数据库文件不可用，所以生产环境改OGUID前务必先备份数据。

5.4 误删ASM磁盘组后的恢复思路

做故障模拟测试时，我不小心把ASM磁盘组删了，数据库文件全部不可见。这里分享一下恢复的基本思路：

1. 如果数据文件本身还在（裸设备没被重新格式化），用dmasmtool重新执行create diskgroup，但卷的配置参数必须与原来完全一致；
2. ASP磁盘组的名称、磁盘路径必须一致，否则达梦无法识别原有数据文件；
3. 对于DCR信息丢失的情况，重新执行dmdcr -i初始化DCR；
4. 数据库实例启动后，通过dmrman工具执行restore database从备份恢复控制文件和日志。

这套恢复流程我完整走了一遍，最终数据恢复成功，耗时大约30分钟。从这次实验中我深刻体会到，DSC环境下的备份策略比单机更重要，因为共享存储一旦误操作，影响的是所有节点。

5.5 故障排查速查表

5.6 关于故障模拟的一点建议

DSC集群搭完之后，很多人就觉得完工了。但我的建议是：一定要留半天时间做故障切换演练，否则真出问题时手忙脚乱。

可以按这个顺序来做：

1. 模拟单节点宕机：shutdown -h now，观察另一个节点是否接管业务，应用连接是否中断；
2. 模拟网络隔离：把其中一个节点的存储网卡down掉，观察集群该如何仲裁，是否会误判双主；
3. 模拟DMCSS进程崩溃：kill -9DMCSS进程，观察集群的监控和恢复行为；
4. 模拟磁盘满：把数据卷写满，观察数据库是否会触发告警或切换归档模式。

这些演练能帮你提前发现很多配置层面的问题。比如我第一轮模拟时就发现，节点宕机后达梦默认需要20多秒才能完成故障切换，虽然和Oracle RAC秒级切换有差距，但对大多数业务场景来说是够用的。了解这个切换时间，做应用超时配置时心里就有数了。

6. 一些必须说的心得和后续扩展

整个DSC双节点集群搭建过程，从准备Openfiler存储到两个实例全部OPEN，我完整走下来大约用了大半天时间。如果算上前期资料查阅和踩坑，差不多一个工作日。对这个过程做个简单复盘，有几点心得想分享给准备动手的同行。

第一，DSC的难点不在软件安装，而在对共享存储的理解。达梦DSC默认假设你使用的存储是稳定可靠的，如果Openfiler的iSCSI链路有问题、网络延迟高，集群的心跳和IO路径都会受到牵连。所以有条件的话，测试环境也尽量用千兆以上网络，iSCSI存储网络务必单独走交换机，不要和业务流量混跑。

第二，配置文件务必统一管理。DSC集群的配置分散在dmdcr_cfg.ini、dmasvrmal.ini、dmmal.ini、dmarch.ini多个文件里，两个节点各一份。我后来在做的过程中建了一个专门的配置清单表格，记录每个节点每个文件的hash值，改完配置后比对两边文件是否一致。这在多节点扩展时尤其重要，不然配置漂移了都找不到原因。

第三，日志是你最好的老师。DSC相关日志包括dmcss_DMCSS.log、dmasm_ASM_01.log、dmserver_DSC1.log，分布在/dm8/dmdata/log目录下。出了任何问题，tail -f这些日志往往比翻文档更快定位问题。我排查故障时有超过一半的问题都是先在日志里发现线索的。

第四，从单节点扩展成双节点是可行的，但流程要谨慎。核心思路是先在单节点上初始化好数据库并做好备份，然后配置DCR和ASM并将数据文件迁移到共享存储，最后再启动第二个节点加入集群。这个流程我后面会专门写一篇详细的迁移方案，这里先提醒一点：迁移前务必做好物理备份，否则中途出问题回滚成本很高。

最后说一个很多人关心的扩展方向：DSC可以平滑扩展到四节点甚至更多。达梦官方文档支持最多8个节点的共享存储集群。扩展流程就是在dmdcr_cfg.ini中添加新的资源组，然后在新增节点上重复安装软件、配置DCR启动的过程。思路和双节点完全一致，只是需要更加重视心跳网络带宽和存储IO性能，节点一多，竞争也会同步放大。

这套环境目前还在我的实验机上稳定运行，平时做达梦相关的性能测试、SQL验证、高可用演练都用它。如果你也准备在企业里推达梦DSC，我建议先用这套Openfiler方案做一个POC，把集群的行为特性摸透，再上生产环境。一套几十万的企业存储固然稳定，但实验阶段没必要烧那个钱，Openfiler足够帮你把集群原理和操作流程跑通。