企业官网建设流程全解析

达梦eco平台：

快速上手 | 达梦技术文档https://eco.dameng.com/document/dm/zh-cn/start/围绕 DSC01-1、DSC01-2 的架构理解、iSCSI 共享盘、启动顺序、监视器和快照恢复展开

摘要：本文以两节点 DMDSC 实验环境为主线，系统梳理共享存储集群的架构、资源规划、iSCSI 存储连接、集群服务启动和故障排查方法，并总结 VMware 快照回滚后 DSC 断联、监视器无法连接、节点重加入和业务锁等待等常见问题。

关键词：DMDSC；共享存储；DMCSS；DMCSSM；iSCSI；VMware；银河麒麟

一、为什么实验环境中的 DSC 比单机数据库更难搭建

在单机数据库中，数据库进程、数据文件、日志文件和操作系统通常位于同一台服务器，排障时只需要围绕“服务是否启动、端口是否监听、文件权限是否正确”展开。DMDSC 则是多实例共享同一数据库，任何一个节点的异常都可能与共享存储、集群心跳、实例间通信或启动顺序有关。因此，搭建 DSC 的真正难点不在于把安装程序执行完，而在于让多个节点对同一组共享资源形成一致认知。

实验环境通常采用 Windows 10 物理机、VMware 虚拟机和银河麒麟服务器操作系统组合。为了降低硬件成本，共享存储往往通过 iSCSI 虚拟磁盘模拟。这样的环境可以覆盖真实部署中的大部分关键环节，但也会引入虚拟网络、快照回滚、虚拟磁盘编号变化、Windows 主机休眠等额外变量。如果不先建立清晰的分层排障思路，很容易出现“监视器看不到节点”“一个节点能启动、另一个节点无法加入”“重启后共享盘消失”等问题。

说明：本文以 DSC01-1、DSC01-2 两个节点为例，侧重介绍搭建逻辑和排障方法。不同 DM8 版本的配置文件字段、工具路径可能存在差异，实际操作应以对应版本的《DMDSC 集群》手册为准。

二、先理解 DMDSC：多实例、单数据库与共享存储

DMDSC 的核心特征可以概括为“多个数据库实例，同时访问同一套数据库文件”。从业务连接角度看，应用可以连接任一正常实例；从存储角度看，数据文件和控制信息不是每个节点各保存一份，而是放在所有节点均可访问的共享块设备上。每个实例需要在集群控制机制下协调对数据页、锁资源和内部状态的访问，避免多个实例同时修改同一资源时产生不一致。

这类架构和数据守护的思路不同。数据守护一般是主库和备库各自拥有独立数据文件，通过日志传输和重演保持副本一致；DSC 则是多个实例直接访问同一数据库。因此，DSC 解决的是实例层面的高可用和并发访问问题，共享存储本身仍然是重要故障域。如果生产系统对存储故障也有严格容灾要求，需要在存储层采用高可用能力，或者进一步组合数据守护、异地容灾等方案。

理解这些层次后，排障顺序就应从底向上进行：先看物理机和虚拟机是否正常，再看网络和共享磁盘，再看 DMCSS，最后看 DMASM 和数据库实例。不要在共享盘尚未连接时反复修改数据库参数，也不要在 DMCSS 未形成稳定集群时直接启动所有实例。

三、实验拓扑与资源规划

一个可重复使用的两节点练习环境至少需要规划节点名称、管理 IP、实例通信 IP、数据库服务端口、DMCSS 端口、共享盘用途和软件目录。实验中可以使用 DSC01-1、DSC01-2 作为主机名，Windows 物理机和麒麟虚拟机均设置静态 IP。静态地址的价值不仅是方便记忆，更重要的是防止 DHCP 租约变化导致配置文件中的地址失效。

共享存储可通过一台独立存储节点提供 iSCSI Target，也可以在专门的实验主机上创建多个虚拟块设备。常见做法是准备四块虚拟盘，分别承担投票、控制、日志或数据等用途，具体划分应按照当前版本手册和实验指导书执行。两台 DSC 节点必须看到相同的 LUN，且对同一 LUN 的容量、标识和访问权限保持一致。

• 操作系统层：统一主机名、时区、时间同步、用户 UID/GID、目录属主和资源限制。

• 网络层：确认节点之间互通、iSCSI 目标地址可达、数据库端口和集群端口未被占用。

• 存储层：确认两节点发现的是同一组 LUN，避免误把本地盘当作共享盘。

• 软件层：两节点使用相同版本、补丁和安装路径，配置文件只在节点标识等必要字段上不同。

• 运维层：记录启动、停止、监视和重连命令，为快照回滚后的恢复准备脚本。

hostnamectl
ip addr
cat /etc/hosts
date
timedatectl
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
ss -lntp

四、操作系统与安装用户准备

数据库软件建议使用专用用户安装，例如 dmdba。两个节点的安装用户、用户组和目录权限应保持一致。共享设备虽然不是普通文件系统目录，但相关配置目录、日志目录、归档目录仍然受 Linux 权限控制。若某个节点由 root 创建了文件，另一个节点以 dmdba 启动程序，就可能出现配置可读但日志不可写、服务启动后立即退出等现象。

# 示例：创建目录并统一属主，路径按实际环境调整
mkdir -p /dm/dmdbms /dm/data /dm/log
chown -R dmdba:dinstall /dm
chmod -R 755 /dm

# 查看资源限制
su - dmdba -c "ulimit -a"

# 临时验证文件描述符限制
su - dmdba -c "ulimit -n 65536; ulimit -n"

在实验环境中经常只修改当前终端的 ulimit，重启后设置又恢复。更稳妥的做法是通过 limits.conf 或 systemd 服务限制进行持久化配置，并在重新登录后验证。数据库和集群程序需要打开大量文件、日志和网络连接，文件描述符过低会产生一些表面上与数据库无关的异常。

时间同步同样重要。节点时间差过大时，日志排查会变得困难，证书、任务调度或监控判断也可能受影响。即使实验环境无法访问互联网，也应至少保证两台虚拟机与宿主机时间接近，或者配置一台内部 NTP 源。

五、iSCSI 共享盘的发现、登录与持久化

iSCSI 环境的关键不是“登录成功一次”，而是保证重启后仍能自动登录，并且节点获取的设备始终对应同一个后端 LUN。排障时先查看会话，再查看块设备，最后核对序列号或 WWID。只凭 /dev/sdb、/dev/sdc 这样的设备名判断磁盘非常危险，因为 Linux 在重启或重新发现磁盘后可能改变盘符顺序。

# 发现目标
iscsiadm -m discovery -t sendtargets -p <存储IP>

# 登录目标
iscsiadm -m node -T <TARGET_IQN> -p <存储IP> --login

# 设置开机自动登录
iscsiadm -m node -T <TARGET_IQN> -p <存储IP> \
--op update -n node.startup -v automatic

# 查看会话和设备
iscsiadm -m session
lsblk -S
ls -l /dev/disk/by-id/

两节点执行 lsblk 时看到的盘符可以不同，但同一 LUN 的容量、序列号和 by-id 标识必须一致。若其中一个节点缺少磁盘，应先检查 iSCSI 会话、网络路由和目标端 ACL，不要直接在缺盘节点重新初始化共享设备。共享盘上的控制信息只应初始化一次，重复初始化可能破坏已经搭建成功的集群。

回滚提示：VMware 快照通常只保存虚拟机本地磁盘状态，不一定完整保存外部 iSCSI Target 的状态。回滚快照后，应先验证 iSCSI 会话和共享盘标识，再启动 DMCSS 与数据库。

六、集群软件配置与推荐启动顺序

完成软件安装和共享盘准备后，需要根据手册创建集群控制、存储和数据库实例相关配置。配置阶段最重要的原则是：两个节点共享的配置必须一致，节点私有配置必须明确区分。常见错误包括复制配置文件后忘记修改节点编号、实例名或本机地址，或者两个节点的配置文件中同一参数采用不同路径。

在排障和日常运维中，建议固定启动顺序。先确认共享存储在线，再启动 DMCSS；待集群控制状态稳定后启动 DMASM 或对应存储服务；最后启动数据库实例。监视器可以单独部署，也可以在实验节点上运行，但生产环境通常建议与被监控节点适当隔离。

1. 确认两节点操作系统、网络和 iSCSI 会话正常。

2. 启动各节点 DMCSS，观察日志中节点注册、心跳和投票状态。

3. 启动存储管理相关服务，确认磁盘组或共享资源正常打开。

4. 按计划启动数据库实例，确认实例成功加入集群。

5. 使用 DMCSSM 查看所有节点、服务和实例状态，再进行客户端连接测试。

# 以下仅展示排查思路，具体启动参数以实际配置为准
ps -ef | grep -E "dmcss|dmcssm|dmasmsvr|dmserver" | grep -v grep
tail -n 200 <DMCSS日志文件>
tail -n 200 <数据库实例日志文件>
ss -lntp | grep -E "<CSS端口>|<数据库端口>"

不要仅凭“进程存在”判断服务正常。数据库进程可能启动后卡在等待共享资源、实例恢复或集群加入阶段；DMCSS 也可能进程存在但无法与其他节点形成一致视图。必须同时结合日志、监听端口和监视器状态判断。

七、如何验证一个 DSC 环境真正可用

集群能够在监视器中显示 ONLINE 只是第一层验证。完整验证至少应覆盖连接、读写、节点故障和恢复四个方面。首先分别连接两个实例，查询实例信息并创建测试表；其次在一个节点写入数据，在另一个节点查询；然后停止其中一个实例，确认另一个实例仍能提供服务；最后恢复故障节点，观察其是否按照预期重新加入。

-- 在任一实例执行示例测试
CREATE TABLE DSC_TEST(
ID INT PRIMARY KEY,
NODE_NAME VARCHAR(50),
CREATE_TIME TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO DSC_TEST(ID, NODE_NAME) VALUES(1, 'DSC01-1');
COMMIT;
SELECT * FROM DSC_TEST;

如果应用使用连接池或负载均衡地址，还应模拟连接切换。仅在管理工具中手工连接两个 IP，不能完全代表业务在节点故障时能够自动重连。实验环境可以先验证数据库层，再逐步加入代理、VIP 或连接串中的多地址配置。

故障演练要保留时间点和日志。记录停止了哪个服务、监视器多久识别故障、剩余节点能否继续写入、恢复节点多久重新加入。这样才能把“看起来能切换”转化为可复现的实验结论。

八、常见故障一：监视器无法连接或看不到节点

监视器无法连接时，应先区分“监视器连不上 DMCSS”和“监视器能连接但集群成员不完整”。前者通常与监视器配置、地址、端口、口令或防火墙有关；后者更多与节点 DMCSS 未启动、节点间通信异常、共享投票信息不一致有关。

• 使用 ping 和 Test-NetConnection/端口探测确认监视器到 DMCSS 的网络可达。

• 检查 DMCSS 实际监听地址与配置文件是否一致，避免只监听 127.0.0.1。

• 核对监视器连接口令和配置文件编码，复制粘贴时注意不可见字符。

• 查看 DMCSS 日志是否出现节点编号冲突、心跳超时、投票盘不可访问等信息。

• 确认防火墙规则不是仅允许数据库端口而遗漏集群管理端口。

在实验中，最常见的误判是看到数据库端口可访问，就认为整个集群网络正常。数据库服务端口、DMCSS 通信端口、监视器端口和 iSCSI 端口属于不同链路，必须分别验证。

九、常见故障二：快照恢复后 DSC 断联

VMware 快照是培训环境重复练习的重要工具，但共享存储集群不能像单机虚拟机一样随意回滚。虚拟机本地状态回到过去，而共享 iSCSI 盘可能仍保持当前状态，节点会出现“本地配置是旧的、共享控制信息是新的”这种时间线不一致。即使两边都回滚，iSCSI 会话也可能因网络接口重新初始化而失效。

1. 快照恢复后先不要启动数据库实例。

2. 检查虚拟机 IP、主机名和 /etc/hosts 是否保持原配置。

3. 检查 iscsiadm 会话，必要时重新发现和登录，但不要重新初始化 LUN。

4. 核对共享盘 by-id 标识与实验记录。

5. 清理异常残留进程，按 DMCSS、存储服务、数据库实例顺序启动。

6. 在监视器确认节点状态后，再开放给下一位练习人员。

为了提高恢复效率，可以为每台节点制作“环境健康检查脚本”，一次输出 IP、主机名、时间、iSCSI 会话、共享盘、关键进程和端口。这样在培训开始前几分钟就能判断环境是否满足练习条件。

十、常见故障三：节点同时更新、锁等待与内部等待

在多个实例同时操作同一数据时，业务层锁等待仍然遵循数据库事务和锁机制。一个会话未提交地更新某行，另一个会话修改同一行，正常表现通常是后者阻塞，直到前者提交、回滚、被终止或达到锁等待超时。这类等待属于业务事务冲突，不应直接等同于集群内部异常。

类似 resid_slot_wait 的内部等待更多与 DSC 节点之间的资源协调有关。内部资源协调超过保护阈值时，集群可能采取保护性动作，目的是避免多个节点对资源状态形成不同认知。排查时要先确认是否存在网络抖动、节点负载过高、共享存储延迟或内部资源槽等待，再判断是否只是普通 SQL 锁冲突。

沟通口径：客户沟通时应先给出结论：普通的两会话更新冲突一般表现为锁等待，不会直接触发集群保护性 halt；只有涉及集群内部资源协调长期异常时，才需要沿 DMCSS、节点通信和存储延迟方向深入排查。

十一、把一次成功部署固化为可重复的培训环境

实验环境的价值不只是“搭成功一次”，而是能够让多人重复练习。完成部署后应形成四类交付物：环境信息表、标准操作手册、故障恢复手册和快照管理规则。环境信息表记录节点名、IP、端口、软件路径、共享盘标识和快照名称；操作手册从远程工具登录开始，避免默认学员知道前置步骤；故障恢复手册记录重启、iSCSI 重连、监视器检查等命令；快照规则明确何时创建、何时回滚和回滚后如何验收。

不要把所有组件都提前安装好。若培训或考试要求从软件安装开始，应保留干净快照，让学员完成安装、目录授权、服务部署和工程配置。已经搭好的 DSC 基础环境则尽量保持稳定，不随意修改 IP、端口、实例名和共享盘，后续练习只在 DRS 节点和同步工程上进行。

每次练习结束后，先停止业务和数据库服务，再按照规则回滚快照。恢复后执行健康检查并保留结果。通过这种方式，环境管理员能够把大量临时排障工作前置为标准检查，显著降低培训过程中的不可控因素。

十二、生产部署需要额外关注的事项

实验环境可以使用单网卡、虚拟 iSCSI 和单台存储目标，但生产环境应根据业务等级设计网络冗余、存储冗余、链路隔离、备份和容灾。数据库高可用不等于数据不会丢失，也不等于共享存储不会故障。需要分别评估实例故障、主机故障、交换机故障、存储控制器故障、机房故障和误操作。

• 节点间通信、客户端访问和存储网络尽量隔离，关键链路配置冗余。

• 共享存储应具备符合业务要求的可靠性，并定期验证备份可恢复性。

• 对 DMCSS、数据库和操作系统日志建立集中监控和容量告警。

• 变更前备份配置文件，重大升级按节点顺序和回退方案执行。

• 应用侧验证连接池重连、事务回滚和故障期间的业务行为。

总结来说，DSC 搭建的关键不是记住一串命令，而是掌握“操作系统—网络—共享存储—集群控制—数据库实例—应用连接”的分层结构。只要按层验证并保持配置一致，大多数看似复杂的故障都能被拆成可定位、可复现的问题。

参考资料

[1] 达梦技术文档：《共享存储集群》https://eco.dameng.com/document/dm/zh-cn/start/dm-asm-cluster.html

[2] 达梦技术文档：《DMDSC 概述》https://eco.dameng.com/document/dm/zh-cn/pm/dsc-overview.html

[3] 达梦技术文档：《DMDSC 节点重加入》https://eco.dameng.com/document/dm/zh-cn/pm/dsc-node.html

[4] 达梦技术文档：《数据守护集群》https://eco.dameng.com/document/dm/zh-cn/start/dm-cluster.html