如果你以前玩过 Oracle RAC看到达梦的 DMDSC 应该会有种熟悉感。DMDSCDM Data Shared Cluster是达梦数据库的多节点共享集群方案DMASM 则是这套集群里的自动存储管理组件作用类似 Oracle ASM 的角色。这两个名称一旦同时出现通常意味着你要在至少两台服务器上加一套共享存储把原本单机跑的数据库升级成多节点同时读写的高可用架构。这篇内容不是官方手册的复述而是把我实际部署 DMASM DMDSC 时踩过的坑、看过的日志、反复调过的参数整理出来给后面接手同样任务的人一份能直接照着做的参考无论是初学 DMDSC 的 DBA还是准备从单机往集群迁移的运维同学都能从中找到可落地的操作路径。1. 先弄清楚 DMASM 和 DMDSC 的关系1.1 DMDSC 是什么解决什么问题DMDSC 的核心特征是多台物理机或虚拟机共同访问一份共享存储里的同一套数据库文件所有节点对外表现为一个整体数据库。对应用来说连接任何一个节点的 IP 和端口都能访问相同的库、相同的数据应用层几乎不需要改动连接方式。这种架构解决两个核心问题。第一是单点故障原来一台服务器上跑数据库机器挂了、网卡坏了、主板烧了整个业务就断了。DMDSC 下这一台机器挂了业务连接可以切换到其他存活节点对外影响时间能够压缩到几十秒甚至更短。第二是资源横向扩展业务增长后单机 CPU、内存顶不住DMDSC 允许往集群里加节点把更多 CPU 和内存纳入同一个数据库的处理能力池。需要注意的是DMDSC 不是传统意义上的主备切换它的每个节点都是活跃实例可以同时提供读写服务。这也意味着它和 Oracle RAC 一样需要处理节点之间的缓存一致性、锁管理、日志应用等复杂机制而这些底层机制恰好都要依赖 DMASM 这个存储层来兜底。1.2 DMASM 在 DMDSC 里的职责DMASM 可以理解为 DMDSC 这支队伍里的仓库管理员。数据库文件、重做日志、控制信息都不直接落在某个节点的本地磁盘上而是放进由 DMASM 统一管理的磁盘组里。它负责空间分配、文件扩展、条带化读写平衡节点访问数据时由 DMASM 协调避免多个实例直接抢同一块磁盘区域。为什么要做这一层抽象因为多节点同时读写同一份文件如果直接让文件落在普通文件系统或裸设备上节点之间需要有非常严谨的互斥机制冲突和锁等待会非常严重。DMASM 把物理磁盘抽象成磁盘组节点实例通过 DMASM 申请和释放空间底层设备竞争被大幅减少性能和稳定性都会好很多。实际部署里DMDSC 的数据库初始化、数据文件创建、归档日志存放都会指向 DMASM 的磁盘组路径比如 DMDATA、DMLOG 这类逻辑路径。操作时经常能看到 dminit 带着 PATHDMDATA 这样的写法路径里的加号就是 DMASM 磁盘组的标记。1.3 这套方案适合谁不值得给谁用DMDSCDMASM 并不是银弹它适合对数据库连续性要求较高、数据库层不允许长时间中断的核心交易系统、实时订单系统和重要 OA 或生产管理库。当单机性能已经逼近瓶颈、短期又无法大规模重构应用做分库分表时DMDSC 也是一个合理选项。但如果业务量不大、能接受几分钟到几十分钟的故障恢复时间传统主备模式会更省事成本和运维复杂度都会低很多。DMDSC 至少需要两台服务器、一套共享存储、额外的内网通信链路还要有熟练的 DBA 来维护集群。集群的运维上限和复杂度都明显高于单机这一点立项前一定要想清楚。2. 部署前的环境规划网络、存储、权限一个都不能少2.1 节点与网络怎么规划DMDSC 最少两个节点准备阶段要定三件事节点命名、IP 规划、端口规划。节点命名建议直接用 DMDSC1、DMDSC2 这类短名称后续很多配置项会用到节点名作为标识名称太复杂容易在配置文件里写错。每台服务器至少准备两块网卡一块用于对外业务访问走业务网段另一块用于集群内部通信单独走一个私有网段。私有网段承载缓存融合、锁消息、心跳检测等流量最好用独立交换机或虚拟网络隔离避免业务流量挤占内部带宽。更讲究一点的环境还会把管理口单独分出来形成业务、私有、管理三个网段这样日常 ssh 维护集群时不会干扰业务和心跳流量。网络规划时还要注意所有节点的 /etc/hosts 必须保持一致把主机名和 IP 的映射写清楚。我实际遇到过一次隐蔽问题两个节点 hosts 里主机名大小写不一致导致 MAL 系统互相识别不了集群核心服务一直起不来。这种问题看似低级排查起来却非常消耗时间所以节点规划和 hosts 检查一定放在第一步。2.2 共享存储规划要点共享存储是 DMDSC 的地基最常见的选择是 FC SAN、iSCSI 或硬件阵列上划分的 LUN。虚拟化环境里也可以把虚拟机磁盘以共享模式挂载但不建议用 NFS 这类网络文件系统直接承载数据库文件锁语义和性能都很难保证。拿到共享磁盘后建议先用 multipath 或 udev 把磁盘映射成稳定的设备名确保两个节点看到的设备路径、设备权限完全一致。DMASM 有个典型要求所有节点对同一块 ASM 磁盘的属主和读写权限一致通常统一为 dmdba:dinstall。如果节点间看到的设备名不一致创建磁盘组时会报路径找不到或权限错误。磁盘数量规划上我建议不要把数据文件和日志文件混放在同一个磁盘组。至少规划两个磁盘组一个 DMDATA 放数据文件一个 DMLOG 放重做日志和归档。这样某组磁盘性能波动或出现故障时不至于把数据库的读写路径全部堵死。2.3 操作系统、目录与安装包准备操作系统没有硬性限制主流 Linux 发行版基本都能跑Red Hat、CentOS 以及一些国产化 Linux 环境我都实际用过部署思路没有差别。安装软件前要做几件事新建 dmdba 用户和 dinstall 用户组安装目录建议放到 /dm8 之类的独立路径不要和系统目录混在一起。检查文件描述符限制建议把 nofile 开到 65536 以上DMDSC 节点一多连接数和线程数增长很快默认 1024 肯定不够。关闭防火墙和 SELinux或者把集群内部端口加入白名单否则节点间 TCP 连不上后续每一步都会卡住。确认所有节点的系统时间同步建议配置 NTP 或 chrony时间相差太大时 DCR 初始化可能直接报错。安装包方面达梦数据库安装时务必选择完整组件尤其是服务器组件里要包含 DMASM、DMDSC 相关执行文件。我见过有同事装完单机版后找不到 dmasmtool实际是安装时漏勾了组件重装一遍才解决。2.4 安装部署参数速查下面是我部署时常用的规划参考读者可以按自己的环境调整项目推荐值说明节点数2 起步生产环境建议至少 2 节点业务 IP 网段如 192.168.1.0/24对外提供服务私有 IP 网段如 10.0.0.0/24DMDSC 内部通信DCR 通信端口8339集群控制通信ASM 通信端口7236DMASM 实例间通信数据库实例端口5236对外数据库服务数据文件挂载点DMDATADMASM 磁盘组日志文件挂载点DMLOGDMASM 磁盘组这些端口在防火墙里要提前放行不只是节点之间的放行还要确认从任意一个节点能 telnet 通其他节点的这些端口。部署前用脚本把端口连通性统一测一遍比等部署时报错再回头查要高效得多。3. DMASM 与 DMDSC 安装部署实操3.1 安装达梦数据库软件并初始化环境第一步是把达梦数据库安装包放到两台节点上用 dmdba 用户执行安装。安装过程中选择服务器组件执行文件会被部署到安装目录包括 dmserver、dmcss、dmasmsvr、dmasmtool、dmdcrctl、dminit 等。需要注意DMDSC 和 DMASM 相关工具不在默认最小安装里安装时务必勾选完整组件否则后面执行 dmcss 或 dmasmtool 会直接报 command not found。安装完成后检查环境变量。通常需要把 DM_HOME 指向安装目录并把 $DM_HOME/bin 加到 PATH 里。这里有个很容易忽略的点不同节点的 DM_HOME 最好保持一致比如都装到 /dm8这样后续很多脚本里写死路径不会因为节点差异而对不上。我习惯在 /etc/profile 或 /home/dmdba/.bash_profile 里统一配置并确认两个节点环境变量完全一致。3.2 DCR 初始化与配置DCRDistributed Cluster Repository是 DMDSC 的集群元数据仓库保存着节点列表、资源状态、磁盘组信息等。DCR 初始化是整个部署流程里最容易出错的环节它依赖每个节点上独立维护的 dmdcr.ini 配置文件。以节点 DMDSC1 为例dmdcr.ini 大致内容如下# 节点 DMDSC1 的 dmdcr.ini DCR_EP_HOST 192.168.1.11 DCR_EP_PORT 8339 DCR_EP_SEQNO 0 DCR_EP_NAME DSC1 DCR_AUTO_START_ASM 1 DCR_AUTO_START_DB 0 DCR_LOG_PATH /dm8/data/dsc1节点 DMDSC2 对应把主机、序号、节点名改成自己的DCR_EP_SEQNO 改成 1。生产环境我一般把 DCR_AUTO_START_ASM 和 DCR_AUTO_START_DB 都设成 0先手动拉起服务等确认集群状态稳定后再改成 1。自动拉起听起来省事但服务第一次启动时如果配置不对CSS 会反复尝试拉起日志刷得非常快反而不容易定位问题。两个节点的 dmdcr.ini 都放好后在任意一个节点执行cd $DM_HOME/bin ./dmdcrctl -i进入交互界面后输入init dcr工具会读取本地 dmdcr.ini并沿 DCR_EP_HOST 去联系其他节点把集群元数据写入共享存储。如果提示初始化成功DCR 这关就过了。如果超时或连接失败优先检查节点间 TCP 是否通、防火墙是否放行、dmdcr.ini 里的 IP 是否能对端反连。不同版本字段可能有细微差异以你实际安装版本的官方手册为准但整体流程是一致的。3.3 启动 CSS 与 DMASM并创建 ASM 磁盘组DCR 初始化完成后启动集群的神经系统 CSSCluster Synchronization Service。CSS 负责节点成员管理、实例故障检测和资源拉起启动命令在每个节点分别执行cd $DM_HOME/bin nohup ./dmcss dcr_ini/dm8/data/dsc1/dmdcr.ini /dm8/log/css.log 21 启动后观察日志确认 CSS 之间完成握手。CSS 正常后再启动每个节点上的 DMASM 实例nohup ./dmasmsvr dcr_ini/dm8/data/dsc1/dmdcr.ini /dm8/log/asm.log 21 DMASM 实例之间通过 MAL 机制通信相关监听配置写在 dmasvrmal.ini 里两个节点要互相把对方实例名称、IP、端口配进去。以 DMDSC1 为例[MAL_INST1] MAL_INST_NAME ASM_DSC1 MAL_HOST 192.168.1.11 MAL_PORT 7236 [MAL_INST2] MAL_INST_NAME ASM_DSC2 MAL_HOST 192.168.1.12 MAL_PORT 7236接下来创建 ASM 磁盘组进入交互工具./dmasmtool dcr_ini/dm8/data/dsc1/dmdcr.ini在交互界面里先用lsdsk查看所有节点都能识别的共享盘确认设备路径和权限无误后执行创建比如create diskgroup DMDATA type external asmdisk /dev/mapper/asm-data1, /dev/mapper/asm-data2; create diskgroup DMLOG type external asmdisk /dev/mapper/asm-log1, /dev/mapper/asm-log2;type 参数选 external 表示不做镜像冗余磁盘组可靠性完全依赖底层存储 RAID如果底层存储没有 RAID且磁盘数量充足可以配置 normal 类型让 DMASM 自己做镜像。测试环境用 external 足够生产建议根据存储情况评估。创建完成后执行lsdg能看到磁盘组状态集中在一个节点创建的磁盘组会通过集群元数据自动同步到所有节点。这里必须强调共享磁盘在创建磁盘组前最好先用 dd 清掉残留分区表或文件系统标识否则 DMASM 可能因为设备上已有签名而拒绝使用。3.4 初始化 DMDSC 数据库并启动集群实例磁盘组就绪后就可以初始化数据库了。这一步用的还是 dminit但路径不再指向本地目录而是指向 DMASM 磁盘组./dminit PATHDMDATA DB_NAMEDMDSC DCR_INI/dm8/data/dsc1/dmdcr.ini初始化过程会在 DMDATA 磁盘组里创建数据库文件和控制文件。完成后dminit 会提示生成了各节点的 dm.ini 模板需要分别复制到每个节点的实例目录里并根据节点修改 INSTANCE_NAME、DCR_EP_NAME 这类参数。两个节点的实例名要能区分比如 DSC1、DSC2。随后启动数据库实例每个节点执行nohup ./dmserver /dm8/data/dsc1/DMDSC/dm.ini dcr_ini/dm8/data/dsc1/dmdcr.ini /dm8/log/db.log 21 启动顺序建议先看 CSS 日志确认两个节点都在线再看 DMASM 日志确认磁盘组挂载正常最后启动数据库。等两个节点的 dmserver 都起来后用 disql 连接任意节点验证select INSTANCE_NAME, STATUS from v$instance; select * from v$dsc_cluster_status;如果两个节点状态都正常集群基本就活了。第一次启动时我最常遇到的问题是某个节点的 dmserver 起不来日志报无法连接 ASM 实例或磁盘组不存在这种绝大多数是 DMASM 没在该节点正常启动或者 dmasvrmal.ini 里的节点配置写错了。3.5 启动顺序与日常操作原则整套环境重启时必须固定顺序先 CSS再 DMASM最后数据库实例关闭时倒过来。如果设置了 DCR_AUTO_START_ASM 为 1CSS 会自动拉起 DMASM但数据库实例我建议还是手工控制方便在出现故障时单独维护。我习惯把所有启动脚本写成一个带 sleep 检查的 shell 脚本每启动一步就查对应日志和端口确认存活后再继续下一步。启动脚本和配置文件的备份一定要做最好再写一个说明文档记录每台节点的 IP、实例名、配置文件路径、日志路径。人肉盯日志很容易遗漏脚本和文档比记忆可靠得多。4. 常见问题与排查技巧实录4.1 日志去哪看怎么快速定位DMDSC 的日志分散在多个地方最常用的有这几个CSS 日志dmcss_*.log记录节点上下线、故障检测、资源拉起。DMASM 日志dmasmsvr_*.log记录 DMASM 实例启动、磁盘组挂载、读写错误。数据库日志dm_DMDSC*.log记录数据库实例运行状态。排查顺序我基本固定先看 CSS 有没有把节点踢掉再看 ASM 有没有超时或挂载异常最后看数据库实例报什么错。日志默认带时间戳和线程号配合 grep 关键字能快速拉到第一个异常时间点从那里开始往前翻一般就能找到根因。4.2 DCR 初始化失败的高频原因第一个是节点间时间不一致。DCR 写入元数据时对时间戳有校验两台机器时间差距过大时写完后校验就可能失败。解决办法是提前配好 NTP 并确认同步成功再操作不要等到报错再回头配时间。第二个是防火墙和白名单放行不完整。DCR_EP 端口、ASM 端口、数据库端口都要放行不仅要放行节点之间还要确认从任意一个节点都能 telnet 通其他节点的这些端口。我一次部署里只放行了业务端口漏掉了 8339结果 CSS 互相联系不上日志里全是 Connection refused看起来像网络中断实际就是防火墙问题。部署前先把端口连通性统一测一遍是最省时间的一步。4.3 ASM 磁盘组创建失败的常见坑磁盘组创建失败遇到最多的是三类问题。一是设备权限不一致。某个节点上共享磁盘属主是 root另一个节点是 dmdbaDMASM 在对端识别设备时直接拒绝。这个问题用 udev 规则统一权限就能解决不要靠每次手动 chown。二是磁盘已经被分区或有文件系统残留。旧环境残留的分区表会让 DMASM 判断设备不可用先清盘再创建磁盘组。三是磁盘路径在两台节点不完全一样。比如节点一看到的是 /dev/sdb节点二看到的是 /dev/sdc由于映射顺序不同导致设备名漂移。用 multipath 或 udev 固定别名不要直接用 sdx 这种不稳定名称。4.4 节点通信与心跳异常处理运行过程中最常见的故障是某个节点突然被 CSS 判定离线随后被踢出集群或自动重启。排查这类问题先看私有网络有没有丢包ping -c 1000 10.0.0.12同时检查心跳网卡的速率协商是否正常、是否出现网卡降速。DMDSC 的心跳和缓存融合对网络抖动非常敏感一条链路不稳定就可能触发节点驱逐。日常监控里建议把私有网卡的丢包率、延迟、带宽使用率纳入告警范围。出现频繁驱逐时除了网络还要检查超时参数。CSS 的检测间隔、数据库实例的 BROADCAST_TIMEOUT 都需要和实际网络状况匹配。内网延迟 0.1ms 的环境用默认参数没问题如果心跳要走三层设备或存在虚拟化网络开销适当把超时调大避免误杀节点。4.5 日常巡检建议集群部署完成不是终点。我每周会做几件事看 CSS 日志里有没有 warning用 dmasmtool 查看磁盘组剩余空间确认两个节点的数据库实例都是 open 状态检查归档日志是否正常写入核对手动备份是否还在按计划执行。另外给一个建议DMDSC 的备份策略不要只依赖单机逻辑备份最好配合 DMASM 磁盘组层面的快照或第三方备份软件。因为集群里数据文件跨多个设备分布普通文件级备份很容易漏掉某个磁盘组恢复时才发现不完整就很被动。备份的恢复演练也要定期做只看备份成功日志但从不演练恢复的坑我相信不止我一个人踩过。5. 部署后的几点个人体会这套环境我前后部署过多次最大的体会是DMDSC 的安装难度本身不算高真正的难点在于环境准备和故障恢复。你只要把网络、共享存储、权限和时间这些地基打牢后面的初始化、建库、启动流程基本是一路顺的反过来任何一项环境细节不合格集群都会用各种奇怪的报错来提醒你。如果你正在做第一次部署我的建议很直接严格按顺序准备环境每启动一个组件就立刻确认日志和状态不要一口气全部拉起来再排错。顺手把每台节点的启动命令、配置文件路径、日志路径整理成一张对照表放桌面后续出问题的时候你会庆幸自己当时做了这件事。集群稳定运行之后也不要放松监控网络抖动和磁盘空间增长永远是 DMDSC 的两大长期风险点。