达梦数据库DM集群全解析：数据守护、DMDSC与MPP选型实战

1. 单机数据库扛不住的那些瞬间为什么需要DM集群去年我在某地市的数据中心做达梦数据库运维巡检客户机房里有十来套实例其中一套单机版的达梦数据库数据量已经涨到600多GB业务高峰期CPU动不动就冲到90%磁盘IO也经常打满。那次巡检和客户的DBA聊到高可用方案他说了一句大实话我们也知道单机风险大但是集群到底怎么搭、该搭哪一种一直没人给我们讲透。这句话其实代表了相当一批达梦数据库用户的现状。达梦作为国内主流的商用关系型数据库在政务、金融、能源等行业里部署量不小但很多项目早期为了快速上线先跑单机等业务稳定、数据量上来之后才开始认真考虑怎么把单机升级成DM集群。可一旦开始调研就会发现达梦的集群方案不是一个而是有好几个数据守护、DMDSC、MPP还有配套的同步工具。名字听起来都带集群架构却完全不同选错了后面改起来非常痛苦。这篇文章就把达梦数据库的集群家族从头到尾梳理一遍讲清楚每种集群架构的原理、适用场景、部署要点和常见坑。不管你是刚接触达梦的运维新人还是正在做方案选型的技术负责人看完至少能明白三种集群分别在解决什么问题我的业务该选哪一个选完之后怎么上手。1.1 单点故障是最痛的事故来源单机数据库的第一个瓶颈还真不是性能是可用性。一台服务器无论硬件多高端都有出故障的概率磁盘坏道、内存报错、电源老化、机房断电、操作系统补丁打挂任何一个环节出问题数据库直接不可用。更麻烦的是单机环境下故障恢复的时间完全取决于硬件维修和系统重建的速度运气好一两个小时运气不好一整夜都起不来。我在项目里见过一个记忆犹新的案例。某客户的核心业务系统跑在单机达梦上机房夜间维护切了一次电存储设备的一个控制器卡住了数据库文件系统无法正常挂载。从晚上十一点开始处理到第二天早上六点业务才恢复。中间每一步都不复杂但每一步都在等硬件厂商协调、等存储厂商响应、等机房配合最后业务整整中断了七个小时。这种事故只要发生一次对业务部门是直接损失对运维团队则是信任崩塌。除了硬件故障人为操作失误也是单机环境的高危因素。误删数据文件、误执行了不带条件的更新、版本升级失败回滚不干净这些在单机上都没有补救手段。有了集群至少还有一份冗余可以顶上去给抢救留出时间窗口。1.2 单机性能存在天花板第二个瓶颈是性能。单机的CPU、内存、磁盘IO是固定的业务量增长到一定程度数据库处理能力就到顶了。你可以加CPU、加内存、换更快的磁盘但单机扩展总有一个边界CPU插槽和内存插槽数量有限磁盘IOPS受控制器能力制约数据库的锁等待和日志写入都集中在单机串行处理。对于OLTP业务单机达梦跑到一定并发量之后响应时间会急剧恶化。对于OLAP业务几个大表关联的慢查询一跑CPU和IO瞬间被吃光其他业务全部被拖累。这时候单纯调优SQL只能缓解解决不了容量上限问题必须从架构层面引入多台机器。1.3 集群的本质是分工集群的本质是把一台机器干所有事变成多台机器分工干活解决两个问题一个是可用性一台机器挂了另一台能顶上业务不中断或者少中断另一个是扩展性一台机器扛不住多台机器分担压力。达梦的集群方案之所以分好几种是因为可用性和扩展性这两个目标可以用完全不同的实现路径达成而且不同路径对硬件、网络、应用的要求差异很大。这就引出了下一章的核心内容达梦集群家族里到底有哪几种成员它们各自的定位是什么。2. DM集群家族全景三种主流架构定位完全不同很多刚接触达梦的人一听到集群两个字默认就理解成主备加自动切换。实际上达梦数据库的集群体系比这个丰富得多。目前主流的DM集群架构分为三类先上总表后面逐一展开。集群类型架构形态核心目标类似参考数据守护Data Watch主备库日志同步高可用、容灾类似Oracle Data GuardDMDSC多实例共享同一份存储高可用加横向扩展类似Oracle RACDM MPP多节点无共享并行大规模数据分析类似Greenplum架构2.1 数据守护经典主备高可用数据守护是达梦部署量最大、资料最全的一种集群形态。核心思路是一套主库加一套或多套备库主库产生的redo日志通过网络持续传送到备库备库不断应用日志保持与主库的数据一致。主库故障时由监视器判断故障并触发备库切换为主库业务自动或手动连接到新主库继续运行。这套架构解决的核心痛点是高可用不解决性能扩展问题。备库在正常情况下不承担业务写流量虽然可以承担部分只读查询但在最严格的实时同步模式下备库的主要使命就是故障接管。数据守护是入门达梦集群的第一站也是后面理解DMDSC和MPP的基础。2.2 DMDSC共享存储上的多实例集群DMDSC全称达梦数据共享集群DM Data Share Cluster。它的形态是多台服务器上的多个DM实例同时访问一份共享存储上的同一套数据库文件。每个实例都有自己的内存和redo日志但对数据文件的读写通过共享存储完成实例之间通过内部高速网络协调数据块的访问。这种架构与Oracle RAC同思路好处有两个第一任何一个实例挂了其他实例继续对外服务业务几乎感知不到第二多个实例可以分担连接数和计算压力实现一定程度的横向扩展。代价是它要求共享存储在硬件层面就具备高可用能力同时内部网络延迟必须极低。2.3 DM MPP无共享的大规模并行架构DM MPP走的是另一条路线无共享架构。数据按特定策略分布到多个节点上每个节点有自己独立的存储和计算资源。执行查询时多个节点并行处理各自负责的数据分区最后由协调节点汇总结果返回。这种架构主要面向OLAP场景数据量大、查询复杂、单机算不过来。它和DMDSC最大的区别在于MPP节点之间不共享数据文件扩展性比DMDSC更强但单个节点故障时它负责的那部分数据会暂时不可用需要依靠备份或备库恢复。2.4 三种架构不是互斥的实际项目中这三种架构可以组合使用。常见组合方式有两种一是在DMDSC外面再套一套数据守护DMDSC在主中心提供高可用读写服务远端备库做容灾二是MPP的每个节点各自配一套数据守护备库防止单节点故障导致分区数据不可用。不过组合方案的运维复杂度提升非常明显涉及多个监视器、多套日志同步链路、多个切换角色。中小团队我不建议一步到位上组合架构先把单一架构跑熟跑稳再根据实际需要叠加。3. 数据守护集群工作机制与部署中的关键点数据守护是绝大多数达梦集群项目的起点值得把它讲透。3.1 redo日志同步机制数据守护的核心是redo日志的传输和应用。主库每产生一批redo日志会通过MAL系统达梦的高可用通信机制实时发送到备库备库收到后写入本地redo并应用从而在逻辑上与主库保持一致。这里必须理解一个关键取舍同步还是异步决定了数据保护级别也决定了主库性能受影响程度。实时同步模式下主库提交事务时必须收到备库确认才向应用返回成功数据零丢失但每个事务多了网络往返主库写入性能有明显开销。异步模式下主库提交不用等备库确认性能影响最小但主库故障时可能丢失最后一部分已提交的数据。我一般给客户的建议是同机房或同城短距离的业务系统用同步模式跨城市容灾用异步模式。跨地域的网络延迟会让同步模式的主库性能掉得很难看强行追求零丢失反而会影响所有业务。3.2 主备切换自动与手动的边界数据守护的切换分两种触发方式。自动故障切换由确认监视器检测主库心跳超时后触发把备库提升为主库整个过程不需要人工干预。手动切换则是由DBA主动执行命令把主库降为备库、备库提升为主库用于计划内维护比如操作系统升级、硬件替换。自动切换的前提是必须部署确认监视器它相当于整个集群的裁判而裁判本身不能单点一般独立部署在第三台机器上。这里有个容易混淆的点普通监视器只能观察状态不能决策只有确认监视器才能发起自动切换。如果只配了普通监视器主库故障时只能靠人工判断和干预。主备切换之后原主库恢复上线时会自动以新备库的身份重新加入集群重新同步数据。但这个过程需要时间数据量越大重同步时间越长规划维护窗口时一定要把这个时间算进去。3.3 部署数据守护最容易忽略的四件事这些年部署数据守护我踩过的和见过的坑不少挑四个最有代表性的第一主备两端的数据库版本和初始化参数必须完全一致尤其是兼容性参数、页大小、字符集。我遇到过一次主备页大小不一致导致备库应用日志直接报错、集群只能重建的案例起因只是当初装库时两台机器用了不同的安装向导选项。第二网络延迟和带宽要提前实测。同步模式下主备网络每增加1毫秒延迟主库事务的响应时间就可能增加2到4毫秒。带宽不足时大批量写入会把日志传输通道堵死备库日志应用持续落后风险敞口越拉越大。第三确认监视器与主备库之间的心跳网络不要复用业务网络有条件的话用独立网段和独立交换机。否则业务高峰期流量一打满监视器误判主库故障触发一次计划外的自动切换可比故障本身麻烦多了。第四整个集群的时钟必须同步。主库、备库、监视器三者的时间基准如果不一致心跳超时的判断就失去了意义。部署时用统一的时间同步服务把三个节点都纳管进来。我还可以给一个dmmal.ini的简化配置示例让第一次接触的人有个直观印象# dmmal.ini 配置示例主备两节点数据守护 MAL_CHECK_INTERVAL 5 MAL_CONN_FAIL_INTERVAL 5 [MAL_INST1] MAL_INST_NAME DMSERVER1 MAL_HOST 192.168.1.10 MAL_PORT 6001 MAL_DW_PORT 6002 [MAL_INST2] MAL_INST_NAME DMSERVER2 MAL_HOST 192.168.1.11 MAL_PORT 6001 MAL_DW_PORT 6002这个文件的重点是MAL_INST_NAME必须和实例名严格对应MAL_PORT和MAL_DW_PORT在两端要一致改错任何一个字段集群都起不来。4. DMDSC核心原理多个实例如何共享一份数据DMDSC是达梦集群里架构最接近Oracle RAC的方案理解它有三个关键点。4.1 共享存储与DMASMDMDSC要求所有实例访问同一份共享存储通常用光纤SAN或高性能分布式块存储。裸设备的权限管理、空间分配是件麻烦事所以达梦提供了DMASM类似Oracle ASM的自动存储管理组件来统一管理共享磁盘。DMASM把共享存储划分成多个磁盘组数据库文件分布在磁盘组上由DMASM统一管理空间和冗余策略。管理员不用关心文件具体落在哪块设备上DMASM还能配置镜像冗余一块磁盘故障不影响数据可用。要注意DMASM是DMDSC集群的组成部分和数据库实例一起运行它的配置状态直接决定集群能否正常工作。4.2 全局缓存协调机制DMDSC最难理解的部分是多实例共享同一份数据文件时的并发控制。两个实例各自有buffer pool缓存着同一份数据文件的不同数据块怎么保证彼此看到的是一致的数据答案是全局缓存协调机制。简单说每个数据块在任意时刻都有归属实例归属实例读它时走本地缓存其他实例要读同一块时通过内部网络向归属实例发起请求而不是直接去共享磁盘读。这样既保证了缓存一致性又避免了频繁访问共享磁盘的IO开销。这个机制和Oracle RAC的Cache Fusion是同一思路。好处是实例间数据块传输走内部高速网络比访问共享磁盘快得多代价是它对内部网络的要求极其苛刻网络抖动会直接体现为集群性能波动。4.3 DMDSC适合什么业务DMDSC主要适用于两类场景一类是核心OLTP系统的高可用一个实例宕机后其他实例继续对外服务业务无感知比数据守护的切换时间更短另一类是中等规模的横向扩展多个实例分担CPU和内存压力在线增加实例可以提升整体处理能力。但DMDSC不是无限扩展的方案。实例数量增加后内部通信和锁协调开销也在增长性能提升会边际递减。规划时我通常建议把DMDSC定位成高可用加轻扩展的组合真正的大规模计算扩展还是交给MPP。5. DM MPP横向扩展与分布式执行5.1 数据分布是MPP性能的命根子DM MPP把一张大表的数据按分布策略打散到多个节点常用策略有三种哈希分布按指定列的哈希值均匀分散适合等值连接随机分布数据随机打散适合均匀性要求不高的场景复制表每个节点保留全量数据适合数据量小的高频维度表避免连接时跨节点搬数据。分布列选错MPP的查询性能会灾难性下降。我见过一个项目业务表按主键哈希分布但业务查询几乎全是按日期范围过滤结果每次查询都要全节点扫描性能比单机还差。正确做法是先分析业务SQL的过滤条件和连接关系再决定分布列。这个分析在表设计阶段就要做上线以后改分布策略代价巨大。5.2 并行执行与数据本地化MPP执行查询时协调节点把SQL拆分成多个子计划分发到各节点并行执行。每个节点只处理自己本地的数据最后汇总结果返回。这里最关键的是数据本地化如果查询涉及的多张表都按关联键做了相同策略的分布连接操作可以在本地完成完全不需要跨节点搬数据。跨节点搬数据是MPP性能的头号杀手。设计表结构时要尽量让高频查询做到本地计算。必要时可以设计冗余的复制表来换取查询性能磁盘空间换速度在分析场景里通常是划算的。5.3 MPP的可用性短板与应对MPP节点本身没有故障接管能力单节点故障时它负责的那部分分区暂时不可用。为了提升可用性可以在每个MPP节点后面再搭一套数据守护备库节点故障后由备库临时顶上这个分区的数据服务。但这种组合部署和运维成本很高实际项目中并不常见。大部分DM MPP客户的选择是接受单节点故障时部分分区不可用依靠备份快速恢复把精力花在节点硬件可靠性和备份策略上。所以MPP更适合对可用性要求相对灵活、但对计算扩展能力要求极高的分析场景。6. 选型经验与踩坑记录从项目实战出发最后一章把我们做项目时的选型思路和踩过的坑整理出来。6.1 一张选型决策清单给客户做方案时我习惯用一张决策清单来引导讨论业务形态首要目标推荐架构中小OLTP系统可用性要求高主库故障快速接管数据守护同步模式大型OLTP核心交易系统无感知故障接管加负载分担DMDSC两地三中心容灾跨地域数据保护数据守护异步模式大规模数据分析、数据仓库计算能力横向扩展DM MPP混合负载复杂场景兼顾高可用与扩展组合架构谨慎评估选型时必须同时问清楚几个前置问题应用能不能容忍切换时的连接中断备库是否需要承担只读查询机房内部网络条件是否够好运维团队的排障能力处于什么水平这些问题比架构本身更影响最终效果。6.2 四个让我印象深刻的教训第一集群上线只是开始定期演练才是关键。某客户部署了数据守护自动切换半年从没测过故障切换真出故障时备库因为归档日志空间不足起不来自动切换失败最后还是手工恢复的。从那以后我每个季度都会要求客户做一次切换演练哪怕只在实际业务低峰期做手动切换。第二监控必须覆盖集群组件不能只盯实例存活。很多人只监控数据库进程活着没活着却不监控确认监视器状态、MAL通信状态、日志传输延迟。实际上日志传输延迟才是最需要盯的指标它反映备库与主库的同步距离延迟越大主库故障时的数据丢失风险越高。第三集群环境下的备份策略和单机完全不同。DMDSC环境下做备份要指定某一个实例执行避免多个实例同时备份产生冲突数据守护环境下备份可以放在备库执行以减轻主库压力但要注意备份出来的文件必须能跟上redo应用状态。我见过有团队直接在DMDSC两个实例上同时跑备份任务导致备份文件互相覆盖最后恢复时才发现数据文件不完整。第四网络基础设施不能想当然。DMDSC内部通信要求高性能网卡、合理的MTU配置和正确的流控策略。排查过一次DMDSC整体性能严重下滑的问题最后发现是交换机端口协商成了半双工实例间数据块传输大量重传整个集群都被拖慢。这种问题在单机环境下永远不会暴露只有集群才会遇到。6.3 运维习惯上的几点建议最后分享几个我自己坚持的习惯都是细节但很管用每次主备切换或故障演练之后清理旧的归档日志并重新记录基线状态避免环境日积月累出现空间耗尽问题集群环境里所有节点的数据库参数必须一致用统一参数模板管理禁止单独手工改某个节点定期检查共享存储的IO延迟和网络丢包率DMDSC的性能上限很大程度上由存储和网络决定把切换流程、监视器地址、节点角色、应急联系人写进文档并且确保团队每个人都能照着文档执行不依赖某一个人我在实际项目中体会最深的一件事是集群选型不是选最先进的而是选最匹配业务现状和团队能力的。数据守护、DMDSC、MPP各有各的适用边界先把一套跑熟跑稳再考虑叠加和扩展远比一开始就追求全家桶要靠谱。达梦数据库的集群体系虽然名字多但只要把高可用、扩展性、容灾这三个需求拆开看选型逻辑一下就清晰了。