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 | 守护组 | 初始角色 |
|---|---|---|---|---|
| dm-ep1-p | EP1主库 | 192.168.10.11 | DW_GRP_EP1 | Primary |
| dm-ep1-s | EP1备库 | 192.168.10.12 | DW_GRP_EP1 | Standby |
| dm-ep2-p | EP2主库 | 192.168.10.21 | DW_GRP_EP2 | Primary |
| dm-ep2-s | EP2备库 | 192.168.10.22 | DW_GRP_EP2 | Standby |
| dm-monitor | 监视器 | 192.168.10.30 | - | Monitor |
防火墙、SELinux这些老生常谈就不多说了，关不关看安全策略，但数据库节点之间要放通端口，最省心的是先关掉做完验证再补白名单。时间同步必须做，尤其是MPP跨多节点场景，时间不一致会导致日志排查非常痛苦。
2.2 初始化参数必须全集群统一
这是整个搭建过程中最容易被忽略、也最致命的一步。达梦数据库在执行dminit初始化实例时，页大小（PAGE_SIZE）、簇大小（EXTENT_SIZE）、字符集（CHARSET）、大小写敏感（CASE_SENSITIVE）这些参数，在MPP集群里要求所有节点完全一致。主备之间更是如此——备库是通过主库备份恢复出来的，如果两边基础参数不一致，有些错要到恢复阶段才爆出来，排查起来极其隐蔽。
达梦的库名（DB_NAME）和实例名（INSTANCE_NAME）是两个不同概念。库名更像逻辑库标识，实例名是操作系统进程级标识。同一个主备组内的主库和备库，库名必须一致，实例名可以不同；我的习惯是所有EP的库名都统一叫DMDB，实例名按“EP序号+角色”区分。
初始化命令示例：
bash复制su - dmdba
cd /dm8/bin
./dminit PATH=/dm/data DB_NAME=DMDB INSTANCE_NAME=EP1P \
PAGE_SIZE=32 EXTENT_SIZE=16 CHARSET=1 CASE_SENSITIVE=Y
这里强调一下，PAGE_SIZE=32指的是数据页大小，不是内存。行式存储的OLAP分析场景用大页通常表现更好，但这个选择必须在所有EP统一。字符集用1还是0，取决于业务里是否要存生僻字，一旦定下来后面基本没法改。
2.3 端口规划
达梦集群搭建会涉及好几类端口，很多初学的朋友容易搞混：
| 端口用途 | 说明 | EP1主库示例 |
|---|---|---|
| 实例监听端口 | 应用连数据库的端口，dm.ini里的PORT_NUM | 5236 |
| MAL端口 | 主备、MPP节点间内部通信端口 | 52101 |
| 守护端口 | 守护进程间、守护与监视器通信端口 | 43201 |
| MPP互联端口 | MPP各EP之间交换数据/消息的专用端口 | 53101 |
不同节点如果不在同一台物理机上，端口可以不同也可以相同。但我还是建议每个EP用一套不同的端口段，比如EP1的MAL端口是52101，EP2是52201，MPP端口EP1是53101，EP2是53201。端口能分开，排错时抓包看连接，一眼就知道是哪条链路。
3. 先把每一路主备跑通，再做MPP组网
3.1 开启归档并初始化主库
主备同步依赖联机归档日志，所以第一步是让主库处于归档模式。建好主库后，修改数据目录下的dm.ini：
ini复制MAL_INI = 1
ARCH_INI = 1
这两个开关非常重要。MAL_INI=1表示启用达梦的MAL内部通信系统，DataWatch主备、MPP组网都依赖它。ARCH_INI=1代表实例使用外部归档配置，归档参数不在dm.ini里，而是单独放在dmarch.ini文件里。
在主库数据目录下新建dmarch.ini，写入本地归档和实时归档配置：
ini复制[ARCHIVE_LOCAL1]
ARCH_TYPE = LOCAL
ARCH_DEST = /dm8/arch/DMDB
ARCH_FILE_SIZE = 2048
ARCH_SPACE_LIMIT = 20480
ARCH_FLUSH_TIMING = 1
[ARCHIVE_REALTIME1]
ARCH_TYPE = REALTIME
ARCH_DEST = EP1S
很多人不知道，REALTIME归档里的ARCH_DEST填的不是IP地址，而是备库的MAL实例名。MAL系统内部做逻辑寻址，dmmal.ini里定义了名字和真实地址的映射关系。这种设计一开始可能不太习惯，但理解了就不容易配错。
3.2 用备份恢复方式生成备库
备库不是直接在另一台机器上再dminit一遍就完事的，那样两边数据文件不一致，没法做主备同步。推荐做法是：先在主库做全量备份，再把备份文件拿到备库机器上执行RESTORE和RECOVER。
先把主库启动，进入正常OPEN状态，然后执行联机全量备份：
bash复制./dmrman CTLSTMT="BACKUP DATABASE '/dm/data/DMDB/dm.ini' FULL BACKUPSET '/dm8/backup/EP1_INIT.bak'"
把备份文件拷到备库机器后，备库这边先dminit出一个和主库同库名、但实例名不同的空实例。接下来用dmrman恢复：
bash复制./dmrman CTLSTMT="RESTORE DATABASE '/dm/data/DMDB/dm.ini' FROM BACKUPSET '/dm8/backup/EP1_INIT.bak'"
./dmrman CTLSTMT="RECOVER DATABASE '/dm/data/DMDB/dm.ini' FROM BACKUPSET '/dm8/backup/EP1_INIT.bak'"
./dmrman CTLSTMT="RECOVER DATABASE '/dm/data/DMDB/dm.ini' UPDATE DB_MAGIC"
最后一句UPDATE DB_MAGIC非常关键。达梦通过DB_MAGIC来区分同一个数据库的不同副本，备库如果不更新DB_MAGIC，后面注册到守护进程组时会被认为不是同一个数据副本，轻则报警，重则同步链路建立不起来。
3.3 dmmal.ini里定义主备双方身份
主备两边的数据目录下都要放dmmal.ini。它定义了主备组里有哪些实例，每个实例的MAL服务跑在哪个地址、哪个端口：
ini复制MAL_CHECK_INTERVAL = 5
MAL_CONN_FAIL_INTERVAL = 5
[MAL_INST1]
MAL_INST_NAME = EP1P
MAL_INST_HOST = 192.168.10.11
MAL_INST_PORT = 52101
MAL_DW_PORT = 43201
[MAL_INST2]
MAL_INST_NAME = EP1S
MAL_INST_HOST = 192.168.10.12
MAL_INST_PORT = 52102
MAL_DW_PORT = 43202
我遇到过有人把MAL_INST_PORT和MAL_DW_PORT写成一样。理论上部分版本能跑，但职责上MAL_INST_PORT用于数据库实例间日志传输，MAL_DW_PORT用于守护进程之间的通信，生产环境我建议分开，各自独立端口，避免某类消息刷屏时互相挤占。
EP2那一路主备把这个过程重复一遍，注意实例名、IP、端口相应替换成EP2的规划值。
3.4 设置主备模式并启动守护进程
主库、备库都启动后，分别在两端用disql登录执行OGUID设置。OGUID是守护组的全局唯一ID，可以理解为给这一套主备打了一个相同的标签，同组必须一致，不同组不要相同。EP1组我用453331，EP2组用453332。
在主库上执行：
sql复制SP_SET_OGUID(453331);
ALTER DATABASE PRIMARY;
在备库上执行：
sql复制SP_SET_OGUID(453331);
ALTER DATABASE STANDBY;
接下来配置dmwatcher.ini。守护进程负责监控主备状态、执行自动切换。放在数据目录下的dmwatcher.ini内容大致如下：
ini复制[GRP1]
DW_MODE = AUTO
DW_ERROR_TIME = 10
INST_ERROR_TIME = 20
INST_RECOVER_TIME = 60
INST_OGUID = 453331
INST_INI = /dm/data/DMDB/dm.ini
INST_AUTO_RESTART = 1
INST_STARTUP_CMD = /dm8/bin/dmserver
RLOG_SEND_THRESHOLD = 0
RLOG_APPLY_THRESHOLD = 0
启动顺序不建议乱。先启动主库实例和备库实例，再启动两端的dmwatcher，最后启动监视器。监视器通过dmmonitor.ini找到有哪些守护组要管理，执行如下命令查看状态：
bash复制./dmmonitor /dm/data/dmmonitor.ini
show global info
看到主库LOG_MODE为PRIMARY、备库为STANDBY，归档类型实时，说明这路主备已经健康。两个EP的主备都这样跑起来之后，才算拿到“两组能自动切换的高可用数据库”。
4. 把两路主备“组装”成MPP：核心在dmmpp.ini
4.1 MPP组网到底连的是谁
脑子里一定要扭转一个观念：MPP组网连的并不是固定的某台物理机，而是每个主备组当前的Primary实例。EP1在物理机上跑的是EP1P还是EP1S，取决于当前谁是Primary；MPP要访问EP1这组数据，就访问当前Primary。
因此，dmmpp.ini里描述的每个EP节点，必须在主库和备库两个实例上都存在。如果只在主库目录放了dmmpp.ini、备库没放，一旦主备切换，新Primary启动后不会把自己注册成MPP的EP节点，整个MPP集群瞬间就分裂了。
4.2 dmmpp.ini的配置样例
dmmpp.ini放在每个实例的数据目录下，而不是放在安装目录的bin下。内容要列出整个MPP集群所有EP的信息。以EP1这组主备为例，两边的dmmpp.ini文件内容完全一致：
ini复制[MPP_SEQ_NO0]
MPP_INST_NAME = EP1P
MPP_INST_HOST = 192.168.10.11
MPP_INST_PORT = 53101
[MPP_SEQ_NO1]
MPP_INST_NAME = EP2P
MPP_INST_HOST = 192.168.10.21
MPP_INST_PORT = 53101
注意，dmmpp.ini里当前两个EP的入口都写的是最初规划的Primary主机地址。主备切换后，新Primary跑在原先的Standby机器上，地址就变了。生产环境要彻底解决这个问题，通常会给每个EP的主备配置一套虚拟IP（VIP），MPP互联地址全部用VIP，这样无论Primary在哪个物理机，VIP都能自动漂移到新Primary上。
4.3 重启所有实例让MPP配置生效
dmmpp.ini属于启动时读取的配置，修改后必须重启数据库实例才会生效。重启每个实例时，观察日志中是否有MPP节点注册信息。全部启动后，在任意一个EP的主库上执行disql查询：
sql复制SELECT INSTANCE_NAME, STATUS$ FROM V$INSTANCE;
正常情况下，能看到当前连接的这个实例已经能感知到MPP环境。为了进一步验证，可以创建一张数据分布表来确认数据确实被切分到了不同EP：
sql复制CREATE TABLE DIST_TEST(ID INT, CITY VARCHAR(20)) DISTRIBUTED BY HASH(ID);
INSERT INTO DIST_TEST
SELECT LEVEL, 'CITY' || LEVEL
FROM DUAL
CONNECT BY LEVEL <= 100000;
SELECT COUNT(*) FROM DIST_TEST;
能正常查到10万行，说明MPP协同查询没问题。再用EXPLAIN看执行计划，会看到计划中出现MPP相关的数据交换操作，证明两个EP都参与了计算。
4.4 别忘了备库也要同步“集群身份”
我前面强调过，dmmpp.ini必须同时复制到主备两边的数据目录。这里再补一句：不只是dmmpp.ini，dm.ini里和MPP相关的参数，也要保证主备两边一致。备库虽然平时不参与MPP的数据计算，但它随时有可能通过主备切换变成新Primary，所以它的配置必须和主库保持同一套标准。
主备两边的库文件是通过备份恢复保持一致的，但配置文件和库文件不一样，不会自动同步。我在实际运维时养成了习惯：每次改动主库的dmmpp.ini、dmarch.ini这类节点级配置，都会同步改备库，并在变更记录里用一张表列出“已同步节点”，防止漏掉。
5. 主备切换对MPP的真实冲击：我做了破坏性测试
5.1 手动Switchover的标准操作路径
配置完成后，我没有直接交差，而是在测试环境做了两次切换演练。第一次是手动Switchover，目的是验证正常的角色切换不丢数据、MPP不崩。
在监视器上执行：
bash复制show global info
确认两个EP的主备状态全是正常的，再执行切换命令，把DW_GRP_EP1这组的Primary从EP1P切到EP1S。切换完成后，再次show global info，观察新Primary状态变为OPEN，原主库变成Standby并自动重新加入守护组。
整个过程大概几十秒。在这个窗口内，业务对EP1的访问应该停止，否则会出现连接中断。应用侧如果配了VIP，VIP漂移后连接能自动恢复；如果配的是物理IP，就必须等原主库重新拉起并同步完成才能恢复。
5.2 物理故障模拟：直接干掉Primary进程
第二次测试我做了更狠的验证：在EP1P上直接kill掉dmserver进程，模拟物理机上数据库进程崩溃。因为我配置了INST_AUTO_RESTART=1，守护进程先尝试拉起本地实例；如果拉起失败或超过判定时间，守护组就会自动把EP1S切换为新Primary。
实测下来，备库接管成功，数据完整。关键点在于：切换后，测试表DIST_TEST全量10万行依然能正常查询，没有出现“部分EP数据不可见”的情况。这正是EP级主备叠加MPP的价值所在——单个EP的计算节点故障，不会丢这个EP的数据分片。
5.3 生产环境必须解决的两个透明化问题
测试暴露出的最大问题不是数据，而是地址。MPP各EP之间建立连接时，用的就是dmmpp.ini里写的HOST和PORT。如果你写死的是物理IP，一旦某组主备切换了Primary，新Primary和旧Primary不在同一台机器，dmmpp.ini里的地址就指向了一个已经降级为Standby的旧实例。MPP节点互相找的时候，要么连不上，要么连上的是一个不再承担EP职责的实例。
解决办法有几个方向：
- 每个EP主备组配VIP，dmmpp.ini中HOST填VIP；
- 应用侧连接也只配VIP，不配物理IP；
- 监视器侧配置虚拟IP漂移脚本，切换时自动把VIP从旧主移到新主。
另外，如果EP节点宕机后的备库追日志速度跟不上，切换后新Primary上承载的MPP查询会明显变慢。达梦的DataWatch数据同步默认是实时归档，但备库要开启并行恢复和适当的日志应用参数，才能减小切换后的恢复窗口。
6. 搭建与运维中，这些坑我替你们踩过了
6.1 dminit参数不一致，MPP建立时十分隐蔽
我见过一个环境，EP1建库用了PAGE_SIZE=32，EP2建库时安装人员图省事走了默认的16，结果两个EP单独跑都没问题，一旦组成MPP，数据交换时总在特定行数后报错。这种问题不会在配置阶段立刻暴露，通常要跑到大数据量查询才炸出来，排错效率非常低。
这次的教训是：建库前先出一张“初始化参数确认表”，所有EP的主备实例统一填同一组参数，至少包括PAGE_SIZE、EXTENT_SIZE、CHARSET、CASE_SENSITIVE这一组，由一个人确认，而不是每个人各建各的。
6.2 备库少了dmmpp.ini，一切白搭
第一次搭建时，我先把两套主备跑成了，再在EP1P和EP2P上配了dmmpp