ki-pi前阵子接到一个现场需求：某业务系统要从单节点达梦数据库迁到分布式架构，业务又卡得很死——不能因为数据库实例挂了就让整个应用断掉。翻译过来就是两件事：要扩成达梦数据库MPP集群，还得给这套MPP配上主备容灾。
我在网上翻了一圈，发现讲达梦数据库MPP集群搭建的文章本来就不多，能把MPP和主备结合起来的更少。大多数资料要么只讲DataWatch主备，要么只说MPP怎么组网，等你真把两者叠一起动手做，才会发现一堆细节没人帮你点破。这篇文章就围绕我实际搭建的这套DM8两节点“带主备的MPP集群”，从架构选型、环境规划、主备同步、MPP组网到故障切换验证，把完整过程写出来，也把几个典型的坑放在最后。后面要上手的朋友，不用再走一遍我趟过的弯路。
1. 先想清楚：为什么MPP之外还要叠一层主备
1.1 不带主备的MPP，一个节点挂掉就是半个集群不可用
MPP（Massively Parallel Processing）的核心思路是“数据分片、各管一段”：每个EP节点只持有全量数据的一部分，查询时多个EP并行计算，最后汇总结果。它解决的是单库容量和算力不够的问题，但不天然解决高可用。
达梦数据库MPP里，如果某个EP节点上的实例彻底挂了，那这个EP负责的那部分数据，其他EP节点根本访问不到。业务查询一过来，要么报错，要么卡住。你可能会想：那我把每个EP的数据都多放一份在其他机器上不就行了？道理没错，但MPP本身不管数据副本这件事，需要在架构层面给每个EP单独配一套高可用机制。
我做的方案，是让每个EP都由一套达梦DataWatch主备来承载：EP当前的计算角色由主库承担，备库实时同步；哪一天主库所在的机器坏了，备库自动接管成为新主库，继续为MPP提供该EP的数据和服务。
1.2 两种落地形态，别一上来就选错
带主备的MPP，实际项目中常见的有两种形态。
第一种叫“EP级主备”：每个EP本身是一套独立的主备集群，MPP的组网实际上只把每个主备组的Primary实例纳入进来。这种模式实现相对简单，成本比第二种低很多，是大多数场景的首选。本文采用的就是这种方案。
第二种叫“整集群级主备”：整套MPP集群在主站点跑一套，在灾备站点再完整跑一套MPP，两套MPP之间做数据库级同步。这种方案对资源要求极高，要额外准备一整套MPP的机器，而且主备两个大集群的同步链路调优非常麻烦。除非是核心交易系统、同城或异地灾备要求极高，否则没必要一上来就上这种重型架构。
| 形态 | 基本单位 | 成本 | 故障切换粒度 | 适用场景 |
|---|---|---|---|---|
| EP级主备 | 每个EP一套DataWatch | 较低，2个EP约4台机器 | 单EP故障秒级切换 | 一般生产系统、数据仓库分析 |
| 整集群级主备 | 整套MPP互为备份 | 翻倍，2个EP约8台机器 | 整个集群级切换 | 核心业务、同城灾备、监管要求极高 |
1.3 本次采用的拓扑与角色命名
我这次搭建两节点MPP，每个EP配一套主备。角色命名从一开始就严格区分，这一点后面帮了大忙：
- DW_GRP_EP1：负责EP1的主备守护组，Primary实例名EP1P，Standby实例名EP1S；
- DW_GRP_EP2：负责EP2的主备守护组，Primary实例名EP2P，Standby实例名EP2S；
- MPP组网中，EP1的入口是DW_GRP_EP1当前Primary，EP2的入口是DW_GRP_EP2当前Primary。
这种命名的好处是：每个实例的角色、属于哪个EP、主备身份，从实例名就能一眼看出来。后面做故障排查、启停服务时，不需要再去翻配置确认谁是谁。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境规划决定后面顺不顺：端口、目录、初始化参数
2.1 软硬件与网络准备
以达梦DM8 for 银河麒麟 V10，x86_64架构为例。硬件方面，两个EP各需要两台机器跑主备，再加一台机器跑监视器。监视器这套主备架构的“裁判”，也可以不单独占用一台机器，但我建议单独放，避免主备节点真故障时，监视器也跟着一起失联。
四台数据库节点规划：
| 主机名 | 用途 | IP | 守护组 | 初始角色 |
|---|---|