达梦数据库 集群搭建总结

本文是一篇总结性文章，基于此前完成的四篇技术博客——实时主备、异步主备、读写分离和DSC集群——从概念层面梳理这四个任务背后的技术逻辑，回答“高可用是什么、为什么、怎么做、何时切换”，以及集群内部的信息流与控制流长什么样。

一、四个任务的对比

如果把数据库高可用架构的演进画成一条线，这四个任务正好落在四个关键节点上：

实时主备 → 异步主备 → 读写分离 → DSC

每一步都在解决前一步的局限，同时引入新的复杂度。

阶段	集群类型	核心目标	对应生产场景
第一阶段	实时主备	容灾：主库挂了备库立刻顶上去	核心交易系统，不能丢数据，不能长时间停
第二阶段	异步主备	容灾 + 性能：备库同步有延迟，但对主库影响小	日志类、分析类系统，可以容忍少量数据延迟
第三阶段	读写分离	容灾 + 性能扩展：备库不光做备份，还帮忙承担读流量	读多写少的业务（如报表系统、用户查询）
第四阶段	DSC集群	容灾 + 性能扩展 + 多活：所有节点平等，任意节点可读可写	核心交易系统 + 需要横向扩展写入能力

这个演进路径的本质是：从“一份数据多个副本”走向“一份数据多个实例同时访问” 。前三个阶段本质上都是“主备”架构的变体——数据有主副本和备副本，通过日志同步保持一致性。而DSC跳出了这个框架，多个实例共享同一份数据，不再有“主”和“备”的概念。

二、不同集群高可用的对比

什么是高可用？

高可用（High Availability，HA）的核心定义是：系统出现故障时，服务能不中断或仅短暂中断地继续运行。

在不同集群中，“高可用”的体现形式不同：

• 主备集群：主库故障时，备库接管成为新主库，服务中断时间取决于切换速度（手动秒级到分钟级）
• 读写分离集群：在主备高可用的基础上，备库还承担读流量，主库故障时同样由备库接管
• DSC集群：单节点故障时，其他节点自动接管，业务几乎无感知

为什么要做高可用？

生产环境中，数据库宕机的代价极高。高可用的目的就是用冗余换安全——部署多个节点，任何一个出问题，其他节点顶上。

但不同场景对“高可用”的诉求不同，这也是为什么会有四种不同的集群方案：

• 核心系统：要求RPO=0（数据零丢失），选实时主备
• 日志/分析系统：可容忍少量数据延迟，选异步主备以换取更高性能
• 读多写少的业务：需要扩展读能力，选读写分离
• 需要横向扩展写入能力的核心系统：选DSC

高可用是怎么实现的？

四个任务用四种不同的方式实现了高可用：

实时主备：通过实时归档实现。主库事务提交时，Redo日志立即发送到备库，备库实时重演。主库要等备库确认收到日志后才真正提交事务——这就是“实时”的代价。

异步主备：通过定时器触发实现。主库将Redo日志写入本地归档后，定时器按设定间隔（最小1分钟）批量发送到备库。主库不等待备库确认，性能更高，但存在数据丢失风险。

读写分离：在实时主备基础上，增加客户端智能路由。通过配置 dm_svc.conf 中的 RWSEPARATE_PERCENT 参数，控制读请求在主备之间的分发比例。备库从“被动备份”变为“主动参与服务”。

DSC：通过共享存储 + 多实例并发访问实现。所有节点共享同一份数据文件，通过DMCSS监控节点状态、DMASM管理共享存储、VOTE/DCR磁盘实现心跳检测和仲裁。任意节点故障，其他节点自动接管。

什么情况会触发切换？

触发条件	主备集群	DSC集群
主库/节点宕机	备库接管（手动或自动）	其他节点自动接管
网络隔离/心跳超时	监视器判定故障，触发切换	DMCSS通过VOTE磁盘检测到心跳超时，触发切换
进程崩溃	同节点宕机处理	同节点宕机处理
管理员手动切换	通过监视器执行switchover命令	通过DMCSSM执行切换命令

主备集群的切换依赖 dmwatcher 守护进程和 dmmonitor 监视器。守护进程监控本节点状态，监视器收集所有节点信息并做出切换决策。

DSC集群的切换依赖DMCSS。DMCSS通过VOTE磁盘的Disk Heartbeat机制检测节点状态——每个DMCSS向VOTE磁盘写入心跳信息，同时读取其他节点的心跳。如果某个节点的心跳在规定时间内没有变化，判定该节点故障，触发切换。

三、信息流与控制流：集群内部怎么运作

理解集群不能只看外部行为，还要深入内部：有哪些组件、进程，它们之间的TCP/IP通道长什么样，信息流和控制流分别怎么走。部署完成之后，这些都不是理论，用 ps 和 ss 命令就能直接看到

ps -ef 看到的是“有谁在跑”，ss -tunlp 看到的是“谁能连谁、谁在连谁”

主备集群（实时/异步/读写分离）

组件与进程：

组件	进程名	作用
数据库实例	dmserver	提供SQL服务，主库可读写，备库只读（读写分离时备库开放读）
守护进程	dmwatcher	监控本节点数据库状态，与监视器通信
监视器	dmmonitor	收集集群状态，执行切换命令

通信通道：

通道	端口示例	用途
数据库服务端口	5236（主）/ 5237（备）	客户端连接
MAL端口	6236 / 6237	集群内部日志传输
守护端口	7236 / 7237	守护进程间通信
实例监听守护端口	8236 / 8237	监视器连接

信息流：Redo日志从主库流向备库（通过MAL通道），备库重演日志保持数据同步。

控制流：dmwatcher 监控本节点 → dmmonitor 汇总状态 → 管理员或自动策略触发切换 → dmwatcher 执行角色变更。

DSC集群

DSC的组件和通信比主备复杂得多：

组件与进程：

组件	进程名	每个节点数量	作用
数据库实例	dmserver	1个	提供SQL服务，所有节点平等可读写
集群控制服务	dmcss	1个	监控节点状态，处理故障切换
自动存储管理	dmasmsvr	1个	管理共享磁盘组
集群监视器	dmcssm	全局1个	查看集群状态，执行管理命令

两节点DSC集群共有6个核心进程（每节点3个）。

通信通道（以实际部署为例） ：

通道	节点0端口	节点1端口	用途
数据库服务端口	5238	5239	客户端连接
CSS端口	11286	11287	DMCSS集群间通信
ASM端口	11276	11277	DMASM服务通信
ASM MAL端口	11266	11267	ASM节点间数据交换
DB MAL端口	8344	8346	数据库实例间通信

信息流：数据直接读写共享存储（通过DMASM），不依赖日志传输。多个节点同时访问同一份数据时，通过改造的Buffer缓冲区、事务系统、封锁系统来处理全局并发访问控制。

控制流：DMCSS通过VOTE磁盘的Disk Heartbeat实现心跳检测和故障判定。控制节点通过选举产生（序号小的节点当选），故障时自动选举新控制节点。

相关博客：

• 实时主备集群搭建：
  https://eco.dameng.com/community/post/20260713161533VRCZ61CCOYIEW75RDR
• 异步主备集群搭建：
  https://eco.dameng.com/community/post/2026071411270899VRZN8MIS1DIYICMW
• 读写分离集群搭建：
  https://eco.dameng.com/community/post/20260714134314P6WZ682XV2VIIQREHX
• DSC集群搭建：
  https://eco.dameng.com/community/post/20260715115005V0I0KAHG05VFTVQCB5