达梦读写分离集群部署实战：从架构到故障切换全记录-平芜编程栈

一、开篇：为什么需要一份完整的读写分离集群部署记录

数据库读写分离这个话题，在国产数据库圈子里这几年越来越热。达梦作为国产数据库的代表之一，其读写分离集群方案在信创改造、系统迁移、高性能业务支撑等场景下几乎成了标配。我最初接触达梦读写分离集群时，最大的感受是：官方文档写得很全，但过于分散，新手照着文档一步步搭，往往会在一些关键配置上卡壳。这篇博文就是把我在多个项目里部署达梦读写分离集群的完整过程、踩坑经验、排查方法做一个系统梳理，给准备上手或者正在被读写分离集群折磨的同行一个参考。

这套方案适合谁看？如果你已经在用达梦单机版，业务量上来后单库扛不住读压力；或者你正在做国产化改造，需要一套高可用、读写分离的架构来承载核心业务；又或者你只是想了解达梦集群的部署逻辑、数据同步机制和故障切换流程，这篇内容都能给你对应的价值。我自己是从单机到主备、再从主备到读写分离一步步走过来的，所以很清楚每个阶段会遇到什么问题。

需要说明的是，达梦读写分离集群的底层机制建立在“主库实时归档 + 备库恢复”的数据同步基础之上，集群内部通过守护进程监控主备状态，配合确认监控器实现故障自动切换。读写分离本质上是在主备架构之上增加一套“读流量分流”的逻辑：主库承担写操作，备库承担读操作，应用通过服务名连接集群时，达梦的连接管理机制会自动把读写请求路由到正确的节点。理解这个核心逻辑后，再看部署步骤就不会觉得繁琐了。

二、整体架构与核心思路拆解

2.1 读写分离集群的逻辑架构

达梦读写分离集群的逻辑架构并不神秘，它由多个角色组成：主库（Primary）、备库（Standby）、守护进程（DMWatcher）、确认监控器（监视器，通常称为DMMonitor）、以及应用层连接的服务名配置。

主库负责一切写操作，同时会产生实时归档日志并通过网络发送给备库。备库接收归档日志后执行恢复，使自身数据与主库保持同步。这里要特别注意，达梦的备库在读写分离模式下是可以对外提供只读服务的，而不是像某些传统主备架构那样备库只是冷备、不承担任何业务流量。守护进程的作用是监控主备库的运行状态，并在主库发生故障时配合确认监控器完成主备切换。确认监控器是集群的“决策大脑”，它收集守护进程上报的信息，综合判断是否触发切换、如何切换。

从网络角度看，读写分离集群通常需要至少两个网络平面：一是业务网络，应用通过它连接数据库；二是心跳网络，守护进程和监控器之间通过它交换状态信息。在正式环境里，这两类网络建议用物理隔离或者至少用独立VLAN，避免业务流量冲击心跳链路导致误判。

2.2 为什么选择读写分离而非单纯的主备高可用

单主主备架构解决的是“可用性”问题——主库挂了备库顶上，但备库在平时不对外提供服务，硬件资源利用率低；读写分离在保证可用性的同时，还解决了“性能”问题——把读请求分担到备库，主库从繁重的查询中解放出来，专注处理写事务。

以我实际接触过的某生产业务为例：这套系统每天的读操作占比高达85%以上，夜间跑批时读压力还会翻倍。原来的单库方案在业务高峰期CPU经常跑到70%以上，慢查询增多，应用侧超时频发。迁到达梦读写分离集群后，主库分担写事务和少量实时性要求高的查询，备库扛住了绝大部分报表查询和统计分析请求，主库CPU降到30%以下，整体响应时间明显改善。

当然，读写分离不是银弹，它要求业务系统能接受“读到稍旧数据”的延迟。达梦实时归档的同步延迟通常在秒级甚至毫秒级，但极端情况下如果网络抖动，备库读到的数据可能有短暂滞后。对于强一致性要求的场景——比如刚提交订单后立刻要求查询到最新状态——这类查询必须强制路由到主库，或者在应用层做特殊处理。这个权衡我建议在架构设计阶段就跟业务方沟通清楚，否则上线后容易扯皮。

2.3 配置规划与资源评估

部署之前，先把硬件和实例规划做好，能省掉后面一大半的麻烦。我的建议是主备库硬件规格尽量一致，因为切换后备库要承担原来主库的全部压力，如果备库配置缩水，切换后很容易出现性能瓶颈。

以下是一份我常用的规划模板：

节点	实例名	端口号	操作系统	数据库版本	内存建议	磁盘建议
主库	DMSERVER	5236	兼容主流国产操作系统	达梦8	32GB以上	SSD 500GB以上
备库	DMSERVER	5236	同上	同一版本	32GB以上	SSD 500GB以上
确认监控器	—	默认	任意节点或独立机	—	2GB以上	20GB

端口方面需要确认：主库和备库都是5236，守护进程监听端口一般规划为与实例端口错开，比如8268。监控器是纯客户端角色，不监听固定端口，它主动连接守护进程上报信息的端口。生产环境里建议把确认监控器部署在独立的第三方节点上，避免主备同时故障时监控器也跟着“陪葬”——这一点很多初次部署的人会忽略。

三、部署准备工作与安装前置条件

3.1 版本选择和兼容性确认

达梦读写分离集群对版本有一定要求。实际部署时建议直接使用达梦8的最新小版本，因为读写分离功能在早期版本中存在一些已知问题，后续版本做了修复。具体版本号我不在这里写死，因为不同时间段官方发布的最新小版本不同，我的建议是：部署前先确认当前手上安装包的版本，再对照官方手册确认该版本支持读写分离集群模式，不要拿老旧的安装包直接上。

操作系统兼容性方面，目前主流的国产化操作系统，以及常见的Linux发行版都在达梦的支持列表里。部署之前我习惯先看一下操作系统的glibc版本和内核版本，如果系统太老或者内核参数过于保守，后续启动守护进程时容易遇到资源限制类的报错。

3.2 主机基础配置与内核参数调优

达梦数据库对操作系统的内核参数有一定要求。比较关键的有：信号量、共享内存、文件句柄数和线程数限制。如果这些参数不调到位，数据库运行过程中会出现一些很难排查的间歇性故障。

我一般会在/etc/sysctl.conf里重点调整以下几项：

kernel.sem：信号量参数，达梦官方建议至少设置为250 32000 100 128。
fs.aio-max-nr：异步IO请求上限，建议设置到 1048576 或更高，达梦在某些批量场景下依赖异步IO。
fs.file-max：系统级文件句柄上限，建议设置到 6553560。
net.core.somaxconn：建议设为 1024 以上，避免高并发连接时listen队列溢出。

另外还要修改/etc/security/limits.conf，把用户对打开文件数的限制调大。我习惯对安装用户（比如dmdba）做如下配置：

dmdba soft nofile 65536 dmdba hard nofile 65536 dmdba soft nproc 65536 dmdba hard nproc 65536

调完之后务必重启系统或者至少执行sysctl -p并重新登录会话，否则当前会话仍然沿用旧限制。这个细节我在早期踩过坑：参数明明改了，但数据库还是报“too many open files”，排查半天发现是没重开终端会话。

3.3 安装达梦数据库软件

达梦的安装过程比较简单，图形化安装和命令行安装都支持。但集群部署场景下我强烈建议使用命令行静默安装，既可以在终端环境里直接执行，也方便后续批量复制到备库。

静默安装需要准备一个响应文件，关键配置项包括安装路径、是否创建数据库实例等。我第一次部署时用的是图形化安装，安装完后还要手动创建实例，步骤多且容易在可视化界面里点错选项。后来改用命令行方式后舒服很多，一条命令搞定，配置可控性也更强。

安装完成后，记得确认环境变量配置。达梦安装目录下的环境变量脚本需要被正确导入，主要是设置DM_HOME、PATH等变量。我在实际操作中会把这些写入/home/dmdba/.bash_profile，防止每次登录后都要手动导出。

四、数据库实例初始化与参数配置

4.1 初始化主库实例

达梦安装完成后并不会自动创建实例，需要手动执行初始化工具 dminit。初始化时有两个参数非常关键：一个是page_size（页大小），另一个是charset（字符集）。这两个参数一旦确定，后续无法修改，必须在一开始就规划好。

以我所参与的项目为例，页大小使用的是 32（单位KB），字符集使用 UTF-8。选择页大小32的原因是这套系统里存在大量的大字段和批量写操作，较大的页可以减少IO次数。字符集选UTF-8是为了兼容多语言编码，避免业务侧出现乱码问题。

初始化命令大致如下：

/dameng/bin/dminit PATH=/dameng/data page_size=32 charset=1 case_sensitive=0

其中case_sensitive=0表示大小写不敏感，这一点要根据业务需求确认。我见过有的客户习惯大小写敏感的表名，如果初始化时设为不敏感，后续写SQL时对象名大小写混用就会报错。这个参数同样后期不能修改，务必在初始化前跟开发团队确认清楚。

4.2 配置主库的关键参数

实例初始化完成后，需要设置一批跟归档、守护、读写分离相关的参数。这些参数分布在 dm.ini 配置文件中，部分参数需要重启实例才生效，部分参数可以在线修改。我个人习惯先把需要重启的参数一次性配好，再重启，避免来回折腾。

核心参数如下：

ARCH_INI：必须设为1，开启归档配置。
MAL_INI：必须设为1，开启MAL系统（达梦内部通信机制）。
RLOG_SEND_APPLY_CONFIRM：设为1，要求备库收到日志并应用完成后才向主库确认，提升数据一致性级别。
TIMER_INI：建议设为1，某些集群内部检查依赖定时器。
DW_ARCH_INI：设为1，使实例支持守护进程的归档模式配置。
ALTER_MODE_STATUS：设为1，允许通过外部命令切换数据库模式。
ENABLE_OFFLINE_REP：设为1，支持离线修复备库。

这里需要特别解释RLOG_SEND_APPLY_CONFIRM。这个参数控制主库发送redo日志后，是否需要等待备库“应用完成”才返回事务成功。设为1时，同步性最强，但每次事务提交的网络往返会增加，性能会受一些影响。如果业务对性能极度敏感且能承受极小概率的丢数据，可以设成0，但生产环境我不建议冒险，除非有充分的容灾降级方案。

修改 dm.ini 后，还要单独检查dmarch.ini的配置。这是归档配置文件，主库需要配置实时归档，归档目标指向备库：

ARCH_WAIT_APPLY = 1 [ARCHIVE_LOCAL1] ARCH_TYPE = LOCAL ARCH_DEST = /dameng/arch ARCH_FILE_SIZE = 2048 ARCH_SPACE_LIMIT = 102400 [ARCHIVE_REALTIME1] ARCH_TYPE = REALTIME ARCH_DEST = DMSERVER

ARCH_DEST = DMSERVER中的 DMSERVER 指的是备库的实例名，而不是IP地址，这一点很容易混淆。实例名是达梦集群内部通信识别节点的关键标识，必须与备库的 dm.ini 中INSTANCE_NAME保持完全一致，大小写也要对上。

4.3 初始化备库并建立同步关系

备库的初始化方式与主库略有不同。主库可以使用 dminit 直接初始化，但备库推荐使用备份还原的方式从主库搭建，这样能保证主备库的数据、表结构、甚至配置都处于高度一致的状态。

具体做法是：

在主库上执行联机备份（或一致性备份），生成备份文件。
将备份文件拷贝到备库主机。
使用 dmrman 工具在备库执行还原操作。
备库还原完成后，以 mount 模式启动备库实例。

在 dmrman 里执行还原的核心语句形如：

RESTORE DATABASE FROM BACKUPSET '/备份路径'; RECOVER DATABASE FROM BACKUPSET '/备份路径'; RECOVER DATABASE UPDATE DB_MAGIC;

其中UPDATE DB_MAGIC是达梦很特别的一步，它用来更新备库的库魔数，使备库能够接受主库的归档日志流。如果漏掉这一步，启动守护后主库发送的日志会被备库拒收，等于同步完全建立不起来。我见过不少新手在这上面卡住，日志里反复报magic不匹配，其实就是少了这最后一哆嗦。

备库还原完成后，同样需要配置 dmarch.ini、dm.ini 中的相关参数，设置与主库相同的实例名，然后以 mount 模式启动。注意备库在正式加入集群前不建议直接以 open 模式对外提供服务，因为此时它还没有纳入守护体系，数据随时可能被写入导致与主库不一致。

五、守护进程和监控器配置与启动

5.1 配置守护进程与确认监控器

达梦的读写分离集群依赖守护进程来感知主备状态。每台数据库服务器上都要配置一个守护进程，而确认监控器负责最终决策。这里有一个很重要的概念：达梦集群有两种监控器，一种是普通监控器，只观察不决策；另一种是确认监控器，可以在主库故障时自动发起切换。读写分离集群中，确认监控器必须存在，而且建议部署在独立的主机上。

守护进程的配置文件是 dmwatcher.ini，主要在实例名、端口和守护组名称上做对齐。确认监控器的配置则写在 dmmonitor.ini 里，需要指定监控的守护进程端口、心跳间隔、切换阈值等参数。

心跳间隔和切换阈值是一组需要联动考虑的参数。假设心跳间隔设为3秒，如果监控器连续超过一定次数收不到主库守护进程的心跳，就会判定主库故障并触发切换。这个阈值不能设得太小，否则网络短暂抖动就会导致误切换；也不能设得太大，否则故障后应用长时间不可用。我习惯把心跳间隔设为3秒，判定次数设为9次，也就是大约27秒的容忍窗口，既能容忍短暂的网络波动，也不会让故障恢复太慢。

5.2 启动顺序和常见错误

启动顺序在达梦集群里特别讲究。我的启动顺序是：

以 mount 方式启动备库实例。
以 open 方式启动主库实例。
启动主库和备库各自的守护进程。
启动确认监控器。

备库先以mount方式启动，是为了让它进入“待命”状态，等待主库的归档数据送过来；主库最后以open状态启动，配合守护进程把归档日志推给备库。确认监控器最后启动，启动后它会自动接管整个集群的状态监控。

如果启动过程中出现“守护进程启动失败”或者“监控器连接超时”，首先检查防火墙和端口连通性。达梦的守护进程监听端口与数据库实例端口不同，需要单独放行。其次检查主备库的实例名是否一致、MAL配置是否正确。实际项目中做过的排查记录显示，这类问题有九成以上出在配置项的名称对不上，比如备库的ARCH_DEST写成了IP而不是实例名。

5.3 手工切换与故障演练

集群搭建完成后，强烈建议做一次手工切换测试——别等到真故障了再检验方案。手工切换的流程是：在确认监控器中执行切换命令，将主库切换为备库，备库提升为主库。切换完成后，检查新主库能否正常接收写操作，新备库是否持续同步数据。

我部署过的一套系统中，第一次做故障切换演练时就发现了一个问题：某个应用连接池里的旧连接仍然指向老主库IP，虽然应用层配置的是服务名，但连接池在切换后没有及时刷新，导致部分请求持续报错。后来在应用侧增加了重连和探活机制，再切换时就平稳多了。

这个经验提醒大家，读写分离集群部署完成不等于高可用落地，应用侧的连接治理同样重要。

六、读写分离功能的验证与优化

6.1 验证读写请求是否正确分流

集群部署完成后，需要验证读写请求是否真正实现了分流。达梦数据库中有一些系统视图可以查看实例角色和连接状态，比如v$instance、v$sessions等。查询新备库的v$instance时，可以看到MODE字段显示为READ_WRITE或STANDBY相关值，而STATUS字段显示为MOUNT或OPEN。

更直观的验证方式是：在应用代码里分别执行写操作和读操作，然后在主库和备库上查看各自的会话记录。如果写操作都落在主库会话、读操作都落在备库会话，说明路由配置正常。

我还会用一个更“土”但更有效的方式验证数据同步：在主库创建一张临时表并插入几条记录，立即在备库查询。正常情况下，这些记录会在秒级内出现在备库中。如果长时间查询不到，说明归档同步出现了问题，需要回到归档配置和网络连通性上排查。

6.2 延迟监控与性能调优

读写分离集群上线后，最容易出问题的环节就是主备延迟。达梦提供了一些监控手段，比如查询v$arch_send_info查看归档发送状态，或者查询v$rlog查看日志应用进度。实际运维中，我会把主备延迟作为一个关键指标接入监控系统，延迟超过阈值（比如5秒）就触发告警。

延迟偏大时，优先检查网络带宽和备库的恢复性能。备库恢复是串行操作，如果备库硬件性能比主库差，或者磁盘IO能力不足，恢复速度可能跟不上主库的写入速度，延迟会持续累积。优化手段包括：提升备库硬件规格、调整归档相关的IO参数、合理规划大事务的批跑时间窗口。

运维层面还有个容易被忽略的点：不要在业务高峰期间对备库做大查询。虽然读写分离备库承担读流量，但一个失控的大查询（比如笛卡尔积、全表扫描）会把备库的IO和CPU全部打满，直接影响日志恢复速度，进而放大主备延迟。我的做法是在备库侧设置资源限制或开启查询超时，保护备库的同步能力。

6.3 常见问题与故障排查实录

在读写分离集群上，运维中常见的问题可以整理成下面的速查表：

现象	可能原因	排查方法
备库一直无法转为Open状态	归档配置错误、主备magic不一致	查看守护进程日志，检查dmrman还原时是否执行UPDATE DB_MAGIC
应用读写请求全部落在主库	连接池缓存了旧连接，服务名配置错误，读写分离路由没有生效	检查应用连接串，刷新连接池，在数据库中查看会话分布
主备延迟持续增长	网络带宽不足，备库IO性能差，大事务批量写入	检查网络流量，优化备库硬件，错峰处理大事务
守护进程频繁上报状态异常	心跳网络不稳定，心跳间隔/判定阈值不当	检查心跳链路质量，调整dmwatcher监控参数
主库故障后无法自动切换	确认监控器未启动或配置错误，备库未处于有效状态	检查确认监控器运行状态，确认备库模式、状态是否正常
切换到新主库后写入报错	应用连接未刷新，旧主库角色识别异常	重启应用或清理连接池，检查达梦客户端版本兼容性

再强调一个细节：达梦读写分离集群对时间同步要求较高，主备库、监控器之间的系统时间偏差过大，会导致守护进程对状态判断产生误解。部署前必须配置好NTP时间同步，并且在日常巡检中检查时间偏移量。

6.4 故障切换后的恢复流程

当主库发生故障，确认监控器自动将备库提升为新主库后，原主库如果恢复，不要立刻把它加回集群。正确做法是：先检查原主库的数据与当前主库的差异，然后以新的备库身份重新建立同步关系。实际操作中，我一般是在当前主库再次执行备份，用备份还原的方式重置原主库数据，再重新加入集群。

这个流程很多人容易走错：原主库故障恢复后直接启动，试图重新加入集群，结果导致主备数据冲突。达梦的设计逻辑是以当前主库作为数据权威来源，任何节点重新加入集群前，都必须保证自己的数据与当前主库一致。

七、上线前检查清单与个人经验总结

上线前我会再过一遍以下检查项，每项都确认无误才允许业务流量切入：

主备库参数配置完全对齐，特别是实例名、页大小、字符集。
归档配置正确，备库能够持续接收并应用主库日志。
守护进程与确认监控器配置正确，能够正常启动。
防火墙放行数据库实例端口、守护进程端口，以及MAL通信所需端口。
应用连接串使用服务名而非单个节点地址。
连接池配置了合理的探查与重连机制。
NTP时间同步正常，主备与监控器之间时间偏差在合理范围内。
完成至少一次手工切换演练并验证应用恢复可用。
延迟监控和告警已经配置完成。

最后说一点我个人的实际体会。达梦读写分离集群的部署本身并不复杂，复杂的是它把“高可用”“数据同步”“读写路由”三件事揉在了一起，任何一环做得不到位，整体表现都会打折扣。初学阶段建议先在测试环境完整走一遍，尤其是故障切换演练，不要拿生产环境当试验田。

还有一个小技巧想分享给同行：在排查达梦集群问题时，不要只盯着数据库日志，一定要把操作系统日志、网络抓包、应用日志三方面结合起来看。有些问题表面上是数据库报错，根子却出在网络丢包或者防火墙策略上。多维度交叉验证，排查效率会高很多。

这套方案从落地到现在，已经稳定扛住了多次真实的业务高峰和故障考验。如果你们团队也正在规划达梦读写分离集群，希望这份记录能帮你们少走一些弯路。

达梦读写分离集群部署实战：从架构到故障切换全记录