1. 项目拆解：达梦8 DSC在虚拟化环境中的定位和难点1.1 达梦8 DSC到底是什么达梦8的DSC全称是Data Shared Cluster，也就是共享存储集群方案。它的逻辑跟很多人熟悉的Oracle RAC类似：两个或多个实例节点，通过共享存储访问同一份数据文件，对外提供高可用数据库服务。每个节点都有自己的日志、回滚段和缓冲区，但数据文件、归档日志、控制信息都放在共享存储上，节点间通过内部专用网络同步状态。在国产化替代和信创类项目里，达梦8 DSC出现的频率不算低，尤其是那些原本跑在小型机加集中式存储上的业务，迁移到基于国产服务器和操作系统的环境后，往往需要用集群形态来保障可用性。DSC的部署难度比单机达梦8高一大截，难点在于它既要处理数据库本身的问题，还要处理存储层、网络层、操作系统层面的协同，任何一个环节不干净，集群都会出现莫名其妙的节点漂移或脑裂风险。1.2 VMware环境的两个关键约束很多人觉得数据库集群应该放在物理机上，虚拟化环境里搞DSC是不是给自己找麻烦。我的看法是，开发测试环境、验收演示环境甚至部分准生产环境，用 VMware 搭DSC完全可行，而且性价比很高。一套物理机加存储阵列的成本，在VMware里用两台虚拟机加共享虚拟盘就能模拟，适合做功能验证、高可用演练和调优练习。但虚拟化环境有两个天然约束必须先想清楚。第一是共享存储的实现方式。DSC要求多个节点能同时读写同一块磁盘。VMware里常规的虚拟磁盘默认是单机独占的，两个虚拟机挂同一块vmdk文件，不加特殊配置会出现锁冲突，表现为其中一台虚拟机无法识别磁盘，或者启动时直接报"虚拟机磁盘已被占用"。解决办法通常是给虚拟机配置SCSI总线共享，并设置磁盘锁策略为"非持久化共享"。这一块细节后面单独讲。第二是时钟一致性。集群节点之间对时间漂移非常敏感，VMware虚拟机的时钟如果靠默认同步，很容易出现两个节点时间差超过阈值，导致DSC节点被隔离。生产经验是统一启用NTP或PTP同步，虚拟机额外启用时钟周期的反向同步，不要只靠宿主机时钟。1.3 整体架构选型：两节点还是三节点达梦8 DSC可以做成两节点，也可以做成三节点甚至更多，但在虚拟化环境里我默认推荐两节点。原因很实际：虚拟机数量少，资源开销可控，共享盘规划简单，故障演练时最容易模拟。三节点在真实机房故障冗余上有意义，但在VMware测试环境里，往往徒增心跳网络和CSS同步的复杂度。需要提前规划三套网络：业务网络，用于应用访问数据库。集群内部通信网络，用于DSC节点间的消息同步。管理网络，用于SSH登录、文件分发和日常维护。如果资源紧张，管理网络可以复用业务网络，但节点间通信网络绝不能和业务网络混在一起。DSC节点的故障检测依赖网络心跳，业务流量一大，如果心跳被挤兑，集群很容易误判节点宕机。我在项目里遇到过一次应用跑批量任务时集群自动踢节点，排查到最后就是心跳网卡跟业务网卡共用导致的。网络IP地址规划的示例可以这样：节点主机名业务IP集群通信IP管理IP节点1dsc01192.168.10.1110.10.10.11192.168.20.11节点2dsc02192.168.10.1210.10.10.12192.168.20.12后面所有配置都以这个表为基础，实际操作时替换成自己的网段。2. 部署前准备：虚拟机配置与凝思磐石Linux6.0系统初始化2.1 虚拟机硬件规划与共享磁盘创建这台项目的虚拟机是跑在VMware vSphere上的，虚拟化版本相对较新，虚拟机的配置建议如下：每个节点分配4核CPU、16GB内存，系统盘100GB，共享数据盘按后续数据量规划。如果Data卷比较大，尽量把系统盘和共享数据盘放到不同的数据存储上，避免系统IO和数据库IO互相干扰。共享磁盘的创建是整个准备过程里最容易出问题的一步。在vSphere环境中，推荐用RDM（裸设备映射）方式把存储LUN直通给两台虚拟机。RDM的好处是磁盘访问层面更接近物理机，能避免VMFS文件系统锁带来的各种限制。创建RDM后，两台虚拟机分别添加这个映射磁盘，SCSI控制器要选择可以做总线共享的类型，一般用VMware Paravirtual或者LSI Logic SAS。添加共享盘时，在虚拟机配置里找到SCSI控制器，打开"SCSI总线共享"选项，设置成"虚拟"模式。这步不做，共享盘挂上去后两台虚拟机的锁冲突会直接让第二台节点无法正常识别磁盘，数据库层面根本到不了启动DSC那一步。对于使用VMware Workstation做实验的团队，操作不太一样。Workstation默认不支持图形界面的总线共享设置，需要在虚拟机目录里的.vmx文件中手动追加参数：disk.locking = "false" scsi1:0.deviceType = "disk" scsi1.sharedBus = "virtual"这些参数的作用是把SCSI1总线标记为共享总线，并关闭磁盘文件锁，让多台虚拟机可以把同一个vmdk当作共享盘使用。Workstation场景下我用sharedBus参数踩过坑，必须把共享盘放到专门的SCSI控制器上，不要跟系统盘共用同一个控制器，否则启动时会因为设备拓扑冲突导致蓝屏或内核panic。2.2 凝思磐石Linux6.0的分区与安装要点凝思磐石Linux6.0整体的安装界面和主流Linux发行版接近，有图形化安装器和字符界面的安装选项。考虑到生产环境一般通过远程控制台或者自动化安装方式部署，建议安装时选择最小化安装，后续需要的组件再按清单补。共享数据库节点不需要装图形桌面，界面服务越多，被攻击面和故障点越多。分区方案上，我习惯给系统留独立/boot分区，/分区用LVM管理，swap单独分一块。数据库软件安装目录建议放到独立的挂载点上，比如/dm_data，这样以后系统盘损坏或系统重装，数据库的数据文件不受影响。挂载规划参考：挂载点分区大小用途/boot1GB系统引导/剩余空间系统根分区swap16GB交换分区/dm_data按规划数据库软件和本地数据需要注意，共享数据盘先不要在操作系统里格式化。DSC的共享盘是由DMASM管理的，格式化分区表反而容易在后续配置时产生歧义。我在最初搭建时犯过这个错，先把共享盘做了分区格式化，导致dmasmcmd识别磁盘时看到的是带分区的裸盘，处理起来多花了不少时间。2.3 网络、内核参数与依赖组件检查系统安装完成后，第一件事是改主机名和网卡配置。主机名要跟后面DMCSS配置里的节点名严格对应，改错一个字母，集群都起不来。同时把三张网卡的IP、网关、路由表按规划配置好，建议用nmtui或者直接修改网卡配置文件，配置完务必重启网络服务验证一下连通性。达梦8对操作系统有一些基础要求，部署前需要确认以下内容：关闭防火墙。如果业务需要防火墙，至少要把达梦相关端口放通，包括数据库监听端口5236、DMCSS通信端口7200、DMASM端口7224，以及DMDSC节点间通信端口。测试环境直接关闭防火墙最省事。关闭SELinux，或者设置为permissive模式。检查libaio、numactl、libncurses等依赖库是否安装齐全。调整文件句柄数限制，建议把soft和hard的nofile都设置到65536以上。调整内核参数中的共享内存、信号量限制，确保能支持数据库实例的SGA和后台进程数。这些调整里，文件句柄和信号量参数最容易潜藏隐患。数据库运行过程中需要打开大量文件句柄，比如数据文件、日志、控制文件，以及并发会话的文件描述符。默认的1024限制在单机环境下跑几天就会报"too many open files"，集群环境下多个实例叠加，问题暴露更快。内核参数示例可以参考如下配置，写入/etc/sysctl.conf后执行sysctl -p生效：fs.aio-max-nr = 1048576 fs.file-max = 6815744 kernel.sem = 250 32000 100 128 kernel.shmmni = 4096 net.ipv4.ip_forward = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 vm.swappiness = 10这些参数里特别说明一下rp_filter。DSC节点之间的通信如果走的是多网卡多路由，反向路径过滤默认开启时，可能出现节点间通信丢包的情况。我遇到过一次节点反复重新加入集群的奇怪现象，最后定位到rp_filter上，将其关闭后通信恢复正常。2.4 数据库安装用户与目录准备达梦8不允许直接用root运行数据库服务，必须用专用用户，一般创建dmdba用户。创建用户的命令很简单，但要注意把用户归属于安装目录属主，并且uid和gid在集群两台节点上保持一致。虚拟化环境下很多人分别手工创建用户，结果两个节点uid不同，数据库软件虽然能装上去，跨节点访问共享存储时会出现权限错乱。groupadd dinstall useradd -g dinstall -m -d /home/dmdba -s /bin/bash dmdba mkdir -p /dm_data chown -R dmdba:dinstall /dm_data同时把安装目录和数据库目录的读写权限确认好。共享数据盘目录在操作系统层面不需要文件系统，但达梦软件安装目录必须在每台虚拟机本地磁盘上独立存在。很多新手把达梦软件目录也放到共享盘上，这是个严重误区。软件目录放在共享存储上，两个节点同时写软件目录的进程文件和配置文件，很容易出现损坏。3. 达梦8安装与DSC集群配置实战3.1 数据库软件安装与实例初始化达梦8的安装介质在凝思磐石Linux6.0上安装没有特殊障碍，把DMInstall.bin文件拷贝到系统后，可以先给执行权限，再以dmdba用户运行图形化安装器，也可以使用命令行静默安装。chmod +x DMInstall.bin su - dmdba ./DMInstall.bin -i安装过程中选择典型安装或自定义安装，关键点是设置好安装路径，默认是/home/dmdba/dmdbms。安装完成后需要执行root脚本：/home/dmdba/dmdbms/script/root/root_installer.sh这个脚本负责配置数据库服务的系统权限和环境变量，漏掉这一步，后面启动服务时常报权限或路径问题。实例初始化使用dminit工具。注意单机环境的初始化和DSC环境的初始化不一样，DSC环境下的实例不能直接dminit出完整库，要先把DMCSS、DMASM和DMDSC的共享环境搭起来，再用DSC专用的初始化方式去创建。如果按单机流程先dminit，后面配置DSC时会发现控制文件、数据文件位置与共享存储规划不一致，还得回炉重造。3.2 DSC配置文件的编写思路达梦8 DSC集群的配置核心在三个角色：DMCSS负责集群状态同步和节点故障判定，DMASM负责共享存储管理，DMDSC是真正的数据库实例。三个角色各有一套配置和日志。第一个要写的是dmdcr_cfg.ini，它描述DSC集群的拓扑结构。内容大致包括CSS组、ASM组、DSC实例组，以及每个组包含哪些节点。两节点DSC的配置里，节点编号必须从0开始连续，节点名要跟操作系统主机名完全一致。第二个关键文件是dmdcr.ini，这个文件描述本节点在集群里的角色和监听信息。每台节点上的dmdcr.ini略有不同，主要是DCR_SEQNO不同，节点0写0，节点1写1。我在初始搭建时由于复制了节点0的配置文件忘记改序号，导致两个节点都以节点0身份启动，CSS无法建立正常的主备关系，状态日志里反复出现节点冲突提示。第三个是DMASM的配置文件dmasvrmgr.ini，需要指定ASM实例名、端口号以及共享磁盘发现路径。路径这里要注意，如果前面用RDM映射共享盘，操作系统看到的可能是/dev/sdb这种设备名，建议通过udev绑定磁盘的UUID，生成稳定的软链接，避免重启后设备名变化导致ASM启动时找不到磁盘。DMCSS的启动端口默认是7200，DMASM默认端口是7224，DSC实例间的端口可以在安装后通过参数调整。这些端口在节点通信时必须互通，可以用telnet或nc快速验证。3.3 共享磁盘初始化与ASM磁盘组创建在启动DMASM之前，需要先初始化DMASM的磁盘空间，这一步通过dmasmtool工具完成，重点就是用工具注册共享盘并创建磁盘组。初始化命令大致为：cd /home/dmdba/dmdbms/bin ./dmasmtool DCR_INI=/dm_data/dsc/dmdcr.ini工具会读取dmdcr.ini中配置的ASM磁盘路径，然后完成初始化动作。这里容易踩的坑是，工具的初始化过程会尝试把共享磁盘格式化成DMASM自己能识别的格式。如果共享盘在操作系统层面已经写入了文件系统或分区，初始化时可能会直接报错。所以前面强调，共享盘不需要在操作系统里分区格式化，让dmasmtool自行处理即可。磁盘组创建后，用dmasmcmd命令维护，查看磁盘组状态：./dmasmcmd ASM> lsdsk ASM> lsdp正常状态下，两个节点都能列出同一个磁盘组和磁盘成员。如果某一台节点查看时缺磁盘，大概率是共享盘的总线共享配置没有生效，或者SCSI控制器类型不被该操作系统支持。3.4 DMDSC实例创建与集群启动验证集群组件启动有严格顺序，我在线上执行时的顺序是：先启动节点1的DMCSS，再启动节点2的DMCSS；CSS启动后各自启动DMASM；最后启动DMDSC实例。顺序颠倒会导致后续组件无法注册到集群状态服务里。启动命令可以直接调达梦提供的脚本，也可以手动执行二进制文件。以手动方式为例，在每台节点上分别执行：cd /home/dmdba/dmdbms/bin ./dmcss DCR_INI=/dm_data/dsc/dmdcr.ini ./dmasmsvr DCR_INI=/dm_data/dsc/dmdcr.ini ./dmserver /dm_data/dsc/dmdsc.ini DCR_INI=/dm_data/dsc/dmdcr.ini检查集群状态使用dmcssm工具：./dmcssm -p /dm_data/dsc/dmdcr.ini -s 7200看到两个CSS节点在线，两个ASM节点在线，两个DSC实例都处于Open状态，集群就算正常建立。此时在业务网络里用数据库客户端连接实例的5236端口，能正常登录并执行SQL，就说明整套环境已经跑通。4. 集群功能验证和故障演练4.1 归档日志配置DSC集群建议开启归档模式。共享存储集群和单机最大的区别在于，归档日志不仅可以放在本地，也可以配置到共享存储上，便于任意节点读取和恢复。配置归档需要先修改数据库参数，再重启集群实例生效。归档配置中，我习惯把本地归档和共享归档同时开启，本地归档用于快速恢复，共享归档用于节点级容灾。归档空间规划要按业务量预留，虚拟机环境共享盘空间有限，使用率超过90%后，数据库会暂停写入，这一点要特别注意。4.2 节点故障切换测试集群搭建完，必须做一次真实连线的故障切换测试，不能只看状态是open就结束。测试方法很直接：正常启动集群后，在节点1的SSH环境里执行shutdown或者模拟断电，然后观察节点2是否在超时时间内把集群状态更新为单节点运行，同时业务连接是否发生中断。故障切换效果取决于CSS的failover阈值和心跳网络质量。我搭建时默认参数下，节点异常后在几十秒内能完成切换。如果期间应用重连不及时，数据库会话会出现瞬断，这是集群方案本身的特点，不是配置错误。真正需要排查的是节点没有在预期时间内被隔离，此时要重点检查心跳网络是否拥塞，以及DMCSS的超时参数是否设置过短。演练结束后，重新启动节点1的组件，观察它能否自动重新加入集群，数据状态能否自动追平。这个步骤比故障切换本身更容易暴露配置问题，比如节点参数不一致、日志归档路径写错等。4.3 性能与数据一致性核对集群正常后，最后做一轮基本功能验证。我会在业务网段跑一段并发读写混合SQL，确认两个节点都能承担读写压力，并且数据变更在节点间立即可见。DSC的架构下，两个节点访问共享数据文件，会话通过内部通信维护缓存一致性。一致性验证操作不复杂：在节点1创建一张测试表写入一批数据，在节点2查询并更新同一批数据，再回到节点1查询，确认变更结果一致。如果出现锁等待，说明表锁和事务处理机制正常；如果直接报错或读到中间状态，说明缓存融合有问题，需要从DMDSC的日志中排查具体的锁管理模块报错。5. 高频问题排查与实操结论5.1 VMware共享盘锁冲突标题里提到的VMware环境，最容易卡的还是共享盘锁冲突。问题现象是第二节点启动集群组件时，DMASM无法识别共享盘，或者操作系统层面看不到块设备。排查步骤固定：先检查虚拟机的SCSI控制器是否启用了总线共享；再检查磁盘是否独立、持久化；然后用vmkfstools或存储端信息确认两个虚拟机映射的是不是同一个LUN。Workstation环境下，还要检查.vmx文件里的参数是否真的加载生效。在这些检查里，最容易被忽略的是磁盘必须设置为"独立-持久化"，快照功能与共享磁盘锁存在冲突。5.2 CSS节点被反复踢出集群集群运行一段时间后，某一节点周期性被其它节点判定为故障，状态一会儿在线一会儿离线。这类问题多半跟心跳网络有关，其次跟时钟偏差有关。排查时先ping测试集群通信网络的延迟和丢包率，再用chronyc跟踪时钟偏差。VMware虚拟机默认时钟漂移较大，建议在系统层面配置NTP，同时修改虚拟机配置启用时钟反同步。见过有人只同步了宿主机时钟，虚拟机内部时间仍然跳变，这个问题在DSC里会导致CSS的epoch计数不一致，节点被判脑裂风险触发隔离。5.3 安装与初始化中的细节坑最后集中说一下我在整个搭建过程中反复遇到的几个细节问题。一个是路径权限。达梦的安装目录和DSC配置目录必须属于dmdba用户，两节点的目录结构和属主保持一致，否则跨节点访问时会出现权限报错，这类报错在日志里往往不会直接说权限，而是一堆底层IO错误。一个是端口占用。DMCSS和DMASM端口被占据，系统并不总是报端口冲突，可能表现为启动后进程无故退出。启动前用netstat检查端口占用，能用ss命令快速排查。另一个是配置文件格式。dmdcr.ini里配置项用等号连接，值不需要加引号，但行尾不要留空格或隐藏字符。复制配置文件时最好用scp原样传输，而不是在Windows里编辑再上传，Windows下容易带进CRLF，导致达梦解析配置时出现异常。5.4 我的几点实操心得按照这套流程走完，一个双节点达梦8 DSC集群可以在半天内搭建完成。大部分人耗时间的地方不在命令，而在排查那些跨层面的隐性坑。我强烈建议团队在走正式项目前，先拿VMware环境练一遍手，把共享盘锁、心跳超时、集成权限这些问题都触发一遍，生产环境出问题时才不会慌。我个人在实际操作中的体会是，DSC集群排障的第一原则是"先看CSS状态，再看网络，最后才怀疑数据库配置"。CSS是集群的神经系统，它认为谁健康，谁才是真的健康。只要CSS判断逻辑正常，内核参数和数据库配置问题都能从日志里找到明确线索。反之，CSS状态处在ambiguous状态时，去调数据库参数只会把事情弄复杂。最后再分享一个补充技巧：DSC集群的所有组件日志要养成定期归档习惯，尤其是DMCSS的日志文件，故障排查时往往是第一手证据。可以在系统里加一条crontab，每天把每个节点的CSS、ASM日志压缩打包，保留至少一个月。虚拟化环境重建成本低，但日志丢失后，你连失败原因都找不回来。
1. 项目拆解：达梦8 DSC在虚拟化环境中的定位和难点1.1 达梦8 DSC到底是什么达梦8的DSC全称是Data Shared Cluster，也就是共享存储集群方案。它的逻辑跟很多人熟悉的Oracle RAC类似：两个或多个实例节点，通过共享存储访问同一份数据文件，对外提供高可用数据库服务。每个节点都有自己的日志、回滚段和缓冲区，但数据文件、归档日志、控制信息都放在共享存储上，节点间通过内部专用网络同步状态。在国产化替代和信创类项目里，达梦8 DSC出现的频率不算低，尤其是那些原本跑在小型机加集中式存储上的业务，迁移到基于国产服务器和操作系统的环境后，往往需要用集群形态来保障可用性。DSC的部署难度比单机达梦8高一大截，难点在于它既要处理数据库本身的问题，还要处理存储层、网络层、操作系统层面的协同，任何一个环节不干净，集群都会出现莫名其妙的节点漂移或脑裂风险。1.2 VMware环境的两个关键约束很多人觉得数据库集群应该放在物理机上，虚拟化环境里搞DSC是不是给自己找麻烦。我的看法是，开发测试环境、验收演示环境甚至部分准生产环境，用 VMware 搭DSC完全可行，而且性价比很高。一套物理机加存储阵列的成本，在VMware里用两台虚拟机加共享虚拟盘就能模拟，适合做功能验证、高可用演练和调优练习。但虚拟化环境有两个天然约束必须先想清楚。第一是共享存储的实现方式。DSC要求多个节点能同时读写同一块磁盘。VMware里常规的虚拟磁盘默认是单机独占的，两个虚拟机挂同一块vmdk文件，不加特殊配置会出现锁冲突，表现为其中一台虚拟机无法识别磁盘，或者启动时直接报"虚拟机磁盘已被占用"。解决办法通常是给虚拟机配置SCSI总线共享，并设置磁盘锁策略为"非持久化共享"。这一块细节后面单独讲。第二是时钟一致性。集群节点之间对时间漂移非常敏感，VMware虚拟机的时钟如果靠默认同步，很容易出现两个节点时间差超过阈值，导致DSC节点被隔离。生产经验是统一启用NTP或PTP同步，虚拟机额外启用时钟周期的反向同步，不要只靠宿主机时钟。1.3 整体架构选型：两节点还是三节点达梦8 DSC可以做成两节点，也可以做成三节点甚至更多，但在虚拟化环境里我默认推荐两节点。原因很实际：虚拟机数量少，资源开销可控，共享盘规划简单，故障演练时最容易模拟。三节点在真实机房故障冗余上有意义，但在VMware测试环境里，往往徒增心跳网络和CSS同步的复杂度。需要提前规划三套网络：业务网络，用于应用访问数据库。集群内部通信网络，用于DSC节点间的消息同步。管理网络，用于SSH登录、文件分发和日常维护。如果资源紧张，管理网络可以复用业务网络，但节点间通信网络绝不能和业务网络混在一起。DSC节点的故障检测依赖网络心跳，业务流量一大，如果心跳被挤兑，集群很容易误判节点宕机。我在项目里遇到过一次应用跑批量任务时集群自动踢节点，排查到最后就是心跳网卡跟业务网卡共用导致的。网络IP地址规划的示例可以这样：节点主机名业务IP集群通信IP管理IP节点1dsc01192.168.10.1110.10.10.11192.168.20.11节点2dsc02192.168.10.1210.10.10.12192.168.20.12后面所有配置都以这个表为基础，实际操作时替换成自己的网段。2. 部署前准备：虚拟机配置与凝思磐石Linux6.0系统初始化2.1 虚拟机硬件规划与共享磁盘创建这台项目的虚拟机是跑在VMware vSphere上的，虚拟化版本相对较新，虚拟机的配置建议如下：每个节点分配4核CPU、16GB内存，系统盘100GB，共享数据盘按后续数据量规划。如果Data卷比较大，尽量把系统盘和共享数据盘放到不同的数据存储上，避免系统IO和数据库IO互相干扰。共享磁盘的创建是整个准备过程里最容易出问题的一步。在vSphere环境中，推荐用RDM（裸设备映射）方式把存储LUN直通给两台虚拟机。RDM的好处是磁盘访问层面更接近物理机，能避免VMFS文件系统锁带来的各种限制。创建RDM后，两台虚拟机分别添加这个映射磁盘，SCSI控制器要选择可以做总线共享的类型，一般用VMware Paravirtual或者LSI Logic SAS。添加共享盘时，在虚拟机配置里找到SCSI控制器，打开"SCSI总线共享"选项，设置成"虚拟"模式。这步不做，共享盘挂上去后两台虚拟机的锁冲突会直接让第二台节点无法正常识别磁盘，数据库层面根本到不了启动DSC那一步。对于使用VMware Workstation做实验的团队，操作不太一样。Workstation默认不支持图形界面的总线共享设置，需要在虚拟机目录里的.vmx文件中手动追加参数：disk.locking = "false" scsi1:0.deviceType = "disk" scsi1.sharedBus = "virtual"这些参数的作用是把SCSI1总线标记为共享总线，并关闭磁盘文件锁，让多台虚拟机可以把同一个vmdk当作共享盘使用。Workstation场景下我用sharedBus参数踩过坑，必须把共享盘放到专门的SCSI控制器上，不要跟系统盘共用同一个控制器，否则启动时会因为设备拓扑冲突导致蓝屏或内核panic。2.2 凝思磐石Linux6.0的分区与安装要点凝思磐石Linux6.0整体的安装界面和主流Linux发行版接近，有图形化安装器和字符界面的安装选项。考虑到生产环境一般通过远程控制台或者自动化安装方式部署，建议安装时选择最小化安装，后续需要的组件再按清单补。共享数据库节点不需要装图形桌面，界面服务越多，被攻击面和故障点越多。分区方案上，我习惯给系统留独立/boot分区，/分区用LVM管理，swap单独分一块。数据库软件安装目录建议放到独立的挂载点上，比如/dm_data，这样以后系统盘损坏或系统重装，数据库的数据文件不受影响。挂载规划参考：挂载点分区大小用途/boot1GB系统引导/剩余空间系统根分区swap16GB交换分区/dm_data按规划数据库软件和本地数据需要注意，共享数据盘先不要在操作系统里格式化。DSC的共享盘是由DMASM管理的，格式化分区表反而容易在后续配置时产生歧义。我在最初搭建时犯过这个错，先把共享盘做了分区格式化，导致dmasmcmd识别磁盘时看到的是带分区的裸盘，处理起来多花了不少时间。2.3 网络、内核参数与依赖组件检查系统安装完成后，第一件事是改主机名和网卡配置。主机名要跟后面DMCSS配置里的节点名严格对应，改错一个字母，集群都起不来。同时把三张网卡的IP、网关、路由表按规划配置好，建议用nmtui或者直接修改网卡配置文件，配置完务必重启网络服务验证一下连通性。达梦8对操作系统有一些基础要求，部署前需要确认以下内容：关闭防火墙。如果业务需要防火墙，至少要把达梦相关端口放通，包括数据库监听端口5236、DMCSS通信端口7200、DMASM端口7224，以及DMDSC节点间通信端口。测试环境直接关闭防火墙最省事。关闭SELinux，或者设置为permissive模式。检查libaio、numactl、libncurses等依赖库是否安装齐全。调整文件句柄数限制，建议把soft和hard的nofile都设置到65536以上。调整内核参数中的共享内存、信号量限制，确保能支持数据库实例的SGA和后台进程数。这些调整里，文件句柄和信号量参数最容易潜藏隐患。数据库运行过程中需要打开大量文件句柄，比如数据文件、日志、控制文件，以及并发会话的文件描述符。默认的1024限制在单机环境下跑几天就会报"too many open files"，集群环境下多个实例叠加，问题暴露更快。内核参数示例可以参考如下配置，写入/etc/sysctl.conf后执行sysctl -p生效：fs.aio-max-nr = 1048576 fs.file-max = 6815744 kernel.sem = 250 32000 100 128 kernel.shmmni = 4096 net.ipv4.ip_forward = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 vm.swappiness = 10这些参数里特别说明一下rp_filter。DSC节点之间的通信如果走的是多网卡多路由，反向路径过滤默认开启时，可能出现节点间通信丢包的情况。我遇到过一次节点反复重新加入集群的奇怪现象，最后定位到rp_filter上，将其关闭后通信恢复正常。2.4 数据库安装用户与目录准备达梦8不允许直接用root运行数据库服务，必须用专用用户，一般创建dmdba用户。创建用户的命令很简单，但要注意把用户归属于安装目录属主，并且uid和gid在集群两台节点上保持一致。虚拟化环境下很多人分别手工创建用户，结果两个节点uid不同，数据库软件虽然能装上去，跨节点访问共享存储时会出现权限错乱。groupadd dinstall useradd -g dinstall -m -d /home/dmdba -s /bin/bash dmdba mkdir -p /dm_data chown -R dmdba:dinstall /dm_data同时把安装目录和数据库目录的读写权限确认好。共享数据盘目录在操作系统层面不需要文件系统，但达梦软件安装目录必须在每台虚拟机本地磁盘上独立存在。很多新手把达梦软件目录也放到共享盘上，这是个严重误区。软件目录放在共享存储上，两个节点同时写软件目录的进程文件和配置文件，很容易出现损坏。3. 达梦8安装与DSC集群配置实战3.1 数据库软件安装与实例初始化达梦8的安装介质在凝思磐石Linux6.0上安装没有特殊障碍，把DMInstall.bin文件拷贝到系统后，可以先给执行权限，再以dmdba用户运行图形化安装器，也可以使用命令行静默安装。chmod +x DMInstall.bin su - dmdba ./DMInstall.bin -i安装过程中选择典型安装或自定义安装，关键点是设置好安装路径，默认是/home/dmdba/dmdbms。安装完成后需要执行root脚本：/home/dmdba/dmdbms/script/root/root_installer.sh这个脚本负责配置数据库服务的系统权限和环境变量，漏掉这一步，后面启动服务时常报权限或路径问题。实例初始化使用dminit工具。注意单机环境的初始化和DSC环境的初始化不一样，DSC环境下的实例不能直接dminit出完整库，要先把DMCSS、DMASM和DMDSC的共享环境搭起来，再用DSC专用的初始化方式去创建。如果按单机流程先dminit，后面配置DSC时会发现控制文件、数据文件位置与共享存储规划不一致，还得回炉重造。3.2 DSC配置文件的编写思路达梦8 DSC集群的配置核心在三个角色：DMCSS负责集群状态同步和节点故障判定，DMASM负责共享存储管理，DMDSC是真正的数据库实例。三个角色各有一套配置和日志。第一个要写的是dmdcr_cfg.ini，它描述DSC集群的拓扑结构。内容大致包括CSS组、ASM组、DSC实例组，以及每个组包含哪些节点。两节点DSC的配置里，节点编号必须从0开始连续，节点名要跟操作系统主机名完全一致。第二个关键文件是dmdcr.ini，这个文件描述本节点在集群里的角色和监听信息。每台节点上的dmdcr.ini略有不同，主要是DCR_SEQNO不同，节点0写0，节点1写1。我在初始搭建时由于复制了节点0的配置文件忘记改序号，导致两个节点都以节点0身份启动，CSS无法建立正常的主备关系，状态日志里反复出现节点冲突提示。第三个是DMASM的配置文件dmasvrmgr.ini，需要指定ASM实例名、端口号以及共享磁盘发现路径。路径这里要注意，如果前面用RDM映射共享盘，操作系统看到的可能是/dev/sdb这种设备名，建议通过udev绑定磁盘的UUID，生成稳定的软链接，避免重启后设备名变化导致ASM启动时找不到磁盘。DMCSS的启动端口默认是7200，DMASM默认端口是7224，DSC实例间的端口可以在安装后通过参数调整。这些端口在节点通信时必须互通，可以用telnet或nc快速验证。3.3 共享磁盘初始化与ASM磁盘组创建在启动DMASM之前，需要先初始化DMASM的磁盘空间，这一步通过dmasmtool工具完成，重点就是用工具注册共享盘并创建磁盘组。初始化命令大致为：cd /home/dmdba/dmdbms/bin ./dmasmtool DCR_INI=/dm_data/dsc/dmdcr.ini工具会读取dmdcr.ini中配置的ASM磁盘路径，然后完成初始化动作。这里容易踩的坑是，工具的初始化过程会尝试把共享磁盘格式化成DMASM自己能识别的格式。如果共享盘在操作系统层面已经写入了文件系统或分区，初始化时可能会直接报错。所以前面强调，共享盘不需要在操作系统里分区格式化，让dmasmtool自行处理即可。磁盘组创建后，用dmasmcmd命令维护，查看磁盘组状态：./dmasmcmd ASM> lsdsk ASM> lsdp正常状态下，两个节点都能列出同一个磁盘组和磁盘成员。如果某一台节点查看时缺磁盘，大概率是共享盘的总线共享配置没有生效，或者SCSI控制器类型不被该操作系统支持。3.4 DMDSC实例创建与集群启动验证集群组件启动有严格顺序，我在线上执行时的顺序是：先启动节点1的DMCSS，再启动节点2的DMCSS；CSS启动后各自启动DMASM；最后启动DMDSC实例。顺序颠倒会导致后续组件无法注册到集群状态服务里。启动命令可以直接调达梦提供的脚本，也可以手动执行二进制文件。以手动方式为例，在每台节点上分别执行：cd /home/dmdba/dmdbms/bin ./dmcss DCR_INI=/dm_data/dsc/dmdcr.ini ./dmasmsvr DCR_INI=/dm_data/dsc/dmdcr.ini ./dmserver /dm_data/dsc/dmdsc.ini DCR_INI=/dm_data/dsc/dmdcr.ini检查集群状态使用dmcssm工具：./dmcssm -p /dm_data/dsc/dmdcr.ini -s 7200看到两个CSS节点在线，两个ASM节点在线，两个DSC实例都处于Open状态，集群就算正常建立。此时在业务网络里用数据库客户端连接实例的5236端口，能正常登录并执行SQL，就说明整套环境已经跑通。4. 集群功能验证和故障演练4.1 归档日志配置DSC集群建议开启归档模式。共享存储集群和单机最大的区别在于，归档日志不仅可以放在本地，也可以配置到共享存储上，便于任意节点读取和恢复。配置归档需要先修改数据库参数，再重启集群实例生效。归档配置中，我习惯把本地归档和共享归档同时开启，本地归档用于快速恢复，共享归档用于节点级容灾。归档空间规划要按业务量预留，虚拟机环境共享盘空间有限，使用率超过90%后，数据库会暂停写入，这一点要特别注意。4.2 节点故障切换测试集群搭建完，必须做一次真实连线的故障切换测试，不能只看状态是open就结束。测试方法很直接：正常启动集群后，在节点1的SSH环境里执行shutdown或者模拟断电，然后观察节点2是否在超时时间内把集群状态更新为单节点运行，同时业务连接是否发生中断。故障切换效果取决于CSS的failover阈值和心跳网络质量。我搭建时默认参数下，节点异常后在几十秒内能完成切换。如果期间应用重连不及时，数据库会话会出现瞬断，这是集群方案本身的特点，不是配置错误。真正需要排查的是节点没有在预期时间内被隔离，此时要重点检查心跳网络是否拥塞，以及DMCSS的超时参数是否设置过短。演练结束后，重新启动节点1的组件，观察它能否自动重新加入集群，数据状态能否自动追平。这个步骤比故障切换本身更容易暴露配置问题，比如节点参数不一致、日志归档路径写错等。4.3 性能与数据一致性核对集群正常后，最后做一轮基本功能验证。我会在业务网段跑一段并发读写混合SQL，确认两个节点都能承担读写压力，并且数据变更在节点间立即可见。DSC的架构下，两个节点访问共享数据文件，会话通过内部通信维护缓存一致性。一致性验证操作不复杂：在节点1创建一张测试表写入一批数据，在节点2查询并更新同一批数据，再回到节点1查询，确认变更结果一致。如果出现锁等待，说明表锁和事务处理机制正常；如果直接报错或读到中间状态，说明缓存融合有问题，需要从DMDSC的日志中排查具体的锁管理模块报错。5. 高频问题排查与实操结论5.1 VMware共享盘锁冲突标题里提到的VMware环境，最容易卡的还是共享盘锁冲突。问题现象是第二节点启动集群组件时，DMASM无法识别共享盘，或者操作系统层面看不到块设备。排查步骤固定：先检查虚拟机的SCSI控制器是否启用了总线共享；再检查磁盘是否独立、持久化；然后用vmkfstools或存储端信息确认两个虚拟机映射的是不是同一个LUN。Workstation环境下，还要检查.vmx文件里的参数是否真的加载生效。在这些检查里，最容易被忽略的是磁盘必须设置为"独立-持久化"，快照功能与共享磁盘锁存在冲突。5.2 CSS节点被反复踢出集群集群运行一段时间后，某一节点周期性被其它节点判定为故障，状态一会儿在线一会儿离线。这类问题多半跟心跳网络有关，其次跟时钟偏差有关。排查时先ping测试集群通信网络的延迟和丢包率，再用chronyc跟踪时钟偏差。VMware虚拟机默认时钟漂移较大，建议在系统层面配置NTP，同时修改虚拟机配置启用时钟反同步。见过有人只同步了宿主机时钟，虚拟机内部时间仍然跳变，这个问题在DSC里会导致CSS的epoch计数不一致，节点被判脑裂风险触发隔离。5.3 安装与初始化中的细节坑最后集中说一下我在整个搭建过程中反复遇到的几个细节问题。一个是路径权限。达梦的安装目录和DSC配置目录必须属于dmdba用户，两节点的目录结构和属主保持一致，否则跨节点访问时会出现权限报错，这类报错在日志里往往不会直接说权限，而是一堆底层IO错误。一个是端口占用。DMCSS和DMASM端口被占据，系统并不总是报端口冲突，可能表现为启动后进程无故退出。启动前用netstat检查端口占用，能用ss命令快速排查。另一个是配置文件格式。dmdcr.ini里配置项用等号连接，值不需要加引号，但行尾不要留空格或隐藏字符。复制配置文件时最好用scp原样传输，而不是在Windows里编辑再上传，Windows下容易带进CRLF，导致达梦解析配置时出现异常。5.4 我的几点实操心得按照这套流程走完，一个双节点达梦8 DSC集群可以在半天内搭建完成。大部分人耗时间的地方不在命令，而在排查那些跨层面的隐性坑。我强烈建议团队在走正式项目前，先拿VMware环境练一遍手，把共享盘锁、心跳超时、集成权限这些问题都触发一遍，生产环境出问题时才不会慌。我个人在实际操作中的体会是，DSC集群排障的第一原则是"先看CSS状态，再看网络，最后才怀疑数据库配置"。CSS是集群的神经系统，它认为谁健康，谁才是真的健康。只要CSS判断逻辑正常，内核参数和数据库配置问题都能从日志里找到明确线索。反之，CSS状态处在ambiguous状态时，去调数据库参数只会把事情弄复杂。最后再分享一个补充技巧：DSC集群的所有组件日志要养成定期归档习惯，尤其是DMCSS的日志文件，故障排查时往往是第一手证据。可以在系统里加一条crontab，每天把每个节点的CSS、ASM日志压缩打包，保留至少一个月。虚拟化环境重建成本低，但日志丢失后，你连失败原因都找不回来。