通过命令行搭建读写分离集群

达梦数据库的读写分离集群采用一主多备架构，通过主库处理写操作和关键读请求，备库承担读负载来实现性能提升和高可用性，这种架构设计能有效分担主库压力，接下来我将介绍怎么通过命令行来进行搭建读写分离集群

一、准备阶段与初始化

首先需要提前准备3台虚拟机，并提前进行环境规划，我的规划如下

机器1（主节点）
心跳IP：192.168.252.10
实例名：DM_1
实例端口：6236
MAL 端口：6336
MAL 守护进程端口：6436
守护进程端口：6536
OGUID（守护系统唯一 OGUID 值）：45332

机器2（从节点1）
心跳IP：192.168.252.11
实例名：DM_2
实例端口：6236
MAL 端口：6336
MAL 守护进程端口：6436
守护进程端口：6536
OGUID（守护系统唯一 OGUID 值）：45332

机器3（从节点2）
心跳IP：192.168.252.12
实例名：DM_3
实例端口：6236
MAL 端口：6336
MAL 守护进程端口：6436
守护进程端口：6536
OGUID（守护系统唯一 OGUID 值）：45332

监视器使用：192.168.252.11（从节点1）

然后我们要在3台虚拟机上面安装达梦数据库并初始化实例（注意实例名不要相同），下图以主节点为例：

如果是新装的达梦数据库需要在主节点注册服务并启动

二、配置参数

修改dm.ini文件（此处3个节点配置内容一致），每个文件修改4个参数

（dm.ini用于定义数据库实例的全局参数）

创建dmarch.ini文件，注意个节点实时归档的实例名写另外两个节点的实例名（初始实例化时实例名需不一样），其他位置配置一致

（dmarch.ini文件用于控制主备库间的日志同步）

创建dmmal.ini（此处3个节点配置内容一致）

（dmmal.ini用于管理节点间通信）

创建 dmwatcher.ini（此处3个节点配置内容一致）

（dmwatcher.imi用于控制守护进程行为）

三、实现主从节点的数据一致性初始化

我们先在主节点停止服务并在主从节点启动AP服务

接下来备份我们的主节点

然后备份文件拷贝到从节点（同样操作需要对两节点都执行）

接下来恢复从节点（两个从节点都需要恢复）

四、实现数据库进程的标准化、自动化管理

为了实现数据库进程的标准化、自动化管理，我们需要注册服务，从而实现自动化管理与调度

首先是主节点：

从节点1：

从节点2：

然后我们需要启动对应服务并修改一些参数

首先是主节点：

然后是从节点（两个节点操作类似）：

最后我们启动守护进程（3个节点均要执行）

五、配置监视器

本次配置将监视器配置在从节点1上，其实也可以单独为监视器配置节点

dmwatcher.ini 和 dmmonitor.ini 都是达梦数据库集群管理和监控中使用的配置文件，但它们各自的作用和功能有所不同，前者是控制本地守护进程的行为，后者是配置全局监控器的行为且可以一次监控多个实例，下面我们开始配置监视器

首先是配置dmmonitor.ini，此处配置的是确认监视器，确认监视器是一种高可靠性的监控方式，它在发送监视请求后会等待被监视对象的确认响应，确保监控操作被成功接收和处理，适用于对可靠性要求高的关键业务场景，但由于需要等待确认，其性能开销相对较大

接下来是dmmonitor_manual.ini，此处配置的是非确认监视器，非确认监视器采用无等待机制，发送监控请求后不要求确认响应，具有更快的响应速度和较低的性能开销，但无法保证监控请求一定被接收，适合对性能敏感且允许偶尔监控丢失的非关键业务场景

这时，我们可以选择注册服务，即可后台启动确认监视器了

或者我们也可以直接启动非确认监视器

六、配置读写分离并测试

这一步我们要配置的文件是dm_svc.conf文件，这个文件是使用达梦数据库时非常重要的配置文件，它包含了达梦各接口和客户端工具所需要配置的一些参数。通过它可以实现达梦各种集群的读写分离和均衡负载，且必须和接口/客户端工具位于同一台机器上才能生效。读写分离本质是应用端配置，所以这个读写分离配置需要和调用方在同一个机器上。

Linux环境下，此文件放在/etc目录下，但在某些情况下，所使用的用户没有读取和修改/etc 目录下文件的权限，这时就需要将dm_svc.conf文件放到有权限的目录下，并修改 url 连接串的内容。配置如下

最后我们将dm_svc.conf文件复制过去并进行测试

我们简单在主节点上创建表插入数据

然后在备节点上进行查询

可以看到，两台备机都可以查询到数据，至此我们的配置就完成了

总结

主备集群和读写分离是两种不同侧重点的架构方案，它们的主要区别在于设计目标和实现方式

主备集群的核心目标是保障数据库的高可用性，通常采用一主多备架构，通过同步或异步复制确保数据一致性，当主库故障时备库能够自动接管服务，适用于对业务连续性要求严格的金融、政务等场景

读写分离则主要解决读多写少场景下的性能瓶颈，通过将读请求分散到多个只读备库来减轻主库压力，虽然能显著提升系统吞吐量，但由于数据同步延迟可能导致查询结果短暂不一致，适用于对实时性要求不高的电商、报表等业务

两者并非互斥关系，实际部署中可以结合使用，即在高可用集群的基础上开放备库的只读功能，既保证故障自动切换又能实现查询负载均衡，但需注意同步延迟对业务逻辑的影响