DM8 读写分离集群学习总结：从部署规划到扩容排查

迷枫7122026-05-23 11:07

本文基于已有的 1 主 1 备 1 监视器实验环境整理，前面给出整体认识和部署规划，中间梳理部署重点与关键配置，后面补充节点扩容思路和典型问题排查方法。

来源标注说明：正文来源优先标注本地资料《DM8数据守护与读写分离集群V4.0》的具体章节；本地资料未覆盖或需要拓展阅读时，再在文末列出官方文档。

一、整体认识：读写分离和数据守护的关系

DM 数据守护的基础链路是：主库产生 Redo 日志，Redo 通过 MAL 系统传输到备库，备库接收后重演 Redo，以此保持主备数据同步。读写分离集群是在数据守护基础上进一步利用备库资源：主库承担写操作，备库承担部分只读操作，客户端接口根据服务名和读写分离参数完成自动分流。

来源： 《DM8数据守护与读写分离集群V4.0》2.6 读写分离集群。

读写分离的核心流程可以拆成五步：

  1. 应用通过服务名连接集群。
  2. 客户端接口先连接主库。
  3. 主库根据归档配置返回可用备库信息。
  4. 客户端接口建立备库影子连接。
  5. 只读事务尝试在备库执行，写事务转回主库执行。

来源： 《DM8数据守护与读写分离集群V4.0》2.6.2 实现原理。

从技术支持视角看，读写分离集群至少有三条主线：

主线 关注内容 典型配置
主备同步 主库日志能否发到备库，备库能否及时重演 dmarch.ini、dmmal.ini
守护管理 主备状态如何监控，故障后如何恢复或切换 dmwatcher.ini、dmmonitor.ini
客户端分流 应用如何通过服务名访问，读请求如何分配 dm_svc.conf、连接串、驱动参数

来源： 《DM8数据守护与读写分离集群V4.0》2.6.2 实现原理、4.1 监视器类型、5.8 服务名配置。

二、部署规划：先把角色和端口规划清楚

环境是 1 主 1 备 1 监视器，节点信息如下：

项目 主库 备库
主机名 dmdw01 dmdw02
业务 IP 192.168.166.131 192.168.166.132
心跳 IP 192.168.166.131 192.168.166.132
实例名 DW1_01 DW1_02
数据库端口 15236 15236
MAL 端口 5336 5336
守护进程通信端口 5436 5436
实例监听守护端口 5536 5536
守护组 GDW1 GDW1
OGUID 45331 45331
安装路径 /dmdbms /dmdbms
实例路径 /dmdata/ /dmdata/
归档路径 /dmarch /dmarch

监视器节点：

项目 值
监视器 IP 192.168.166.133
监视器类型 普通监视器
MON_DW_CONFIRM 0
对应切换模式 手动切换

这个实验环境中，业务 IP 和心跳 IP 使用同一网段，便于学习验证。生产环境需要重点评估心跳网络和 MAL 通信质量，官方明确强调心跳网络对 MAL 通讯系统影响很大，网络丢包或延迟较高会影响集群响应。

来源： 《DM8数据守护与读写分离集群V4.0》7.3.1 环境说明。

端口规划不能只看数据库监听端口，几个端口的作用不同：

端口 用途 影响
PORT_NUM 数据库实例对外服务端口 DIsql、JDBC、服务名连接能否访问实例
MAL_PORT MAL 通信端口 主备之间日志传输、内部消息通信
MAL_DW_PORT 守护进程监听端口 守护进程之间、监视器与守护进程通信
MAL_INST_DW_PORT 实例监听守护进程端口 实例和本地守护进程通信

来源： 《DM8数据守护与读写分离集群V4.0》5.7 端口配置关系说明、5.2 dmmal.ini。

三、部署中的几个关键点

以下几点会直接影响集群后续行为

1. 备库必须来自主库备份恢复

备库不能重新初始化后直接改成 STANDBY 加入集群。读写分离集群依赖物理日志链和数据库基础状态，备库需要从主库备份恢复得到，并执行 UPDATE DB_MAGIC，再作为同源实例加入守护系统。

bash 复制代码 
dmrman CTLSTMT="RESTORE DATABASE '/dmdata/DAMENG/dm.ini' FROM BACKUPSET '/dmdata/DAMENG/bak/BACKUP_FILE'"
dmrman CTLSTMT="RECOVER DATABASE '/dmdata/DAMENG/dm.ini' FROM BACKUPSET '/dmdata/DAMENG/bak/BACKUP_FILE'"
dmrman CTLSTMT="RECOVER DATABASE '/dmdata/DAMENG/dm.ini' UPDATE DB_MAGIC"

来源： 《DM8数据守护与读写分离集群V4.0》7.3.2 数据准备。

2. 配置阶段建议以 MOUNT 启动

主备模式、OGUID、守护配置未完成前，实例不宜直接 OPEN。以 MOUNT 启动可以避免配置阶段产生额外业务写入，也便于后续设置主备角色。

bash 复制代码 
dm_service_installer.sh -t dmserver -p DW -dm_ini /dmdata/DAMENG/dm.ini -m mount

来源： 《DM8数据守护与读写分离集群V4.0》7.3.3.5 启动主库、7.3.4.5 启动备库。

3. ARCH_DEST 写实例名，并考虑切换后的反向归档

dmarch.ini 的远程归档目标写的是实例名，不是 IP。主库当前向备库同步，备库也要保留切换后向原主库同步的反向配置。

ini 复制代码 
[ARCHIVE_REALTIME]
ARCH_TYPE = REALTIME
ARCH_DEST = DW1_02
ini 复制代码 
[ARCHIVE_REALTIME]
ARCH_TYPE = REALTIME
ARCH_DEST = DW1_01

如果只配置当前主库到备库的方向，计划切换后新主库可能无法继续把日志发回原主库。

来源： 《DM8数据守护与读写分离集群V4.0》5.3 dmarch.ini、7.3.3.3 配置 dmarch.ini。

4. dmmal.ini 主备保持一致

dmmal.ini 可以看作集群通信通讯录。它既影响日志传输，也影响守护进程和监视器通信。

字段 影响
MAL_INST_NAME 实例身份识别，需要和 INSTANCE_NAME 对应
MAL_HOST MAL 内部通信地址
MAL_INST_HOST 实例对外服务地址
MAL_INST_PORT 实例对外服务端口
MAL_DW_PORT 守护进程监听端口，监视器通过它连接守护进程
MAL_INST_DW_PORT 实例监听守护进程端口

监视器配置中的 MON_DW_IP 需要对应 MAL_HOST:MAL_DW_PORT。如果监视器无法识别节点，应优先核对这组映射。

来源： 《DM8数据守护与读写分离集群V4.0》5.2 dmmal.ini、5.5 dmmonitor.ini。

5. DW_MODE 和 MON_DW_CONFIRM 要成组理解

这两个参数容易被一起提到，但它们不是同一层含义。

DW_MODE 写在 dmwatcher.ini 里，描述的是守护进程组的故障处理模式：遇到主库故障时，是等待人工判断，还是允许自动故障处理流程继续推进。MON_DW_CONFIRM 写在 dmmonitor.ini 里，描述的是监视器类型：它只是普通监视器，还是具备状态确认和自动接管能力的确认监视器。

参数 所在文件 解决的问题 典型取值
DW_MODE dmwatcher.ini 守护进程组按手动切换还是自动切换方式运行 MANUAL、AUTO
MON_DW_CONFIRM dmmonitor.ini 当前监视器是普通监视器还是确认监视器 0 普通监视器，1 确认监视器

两者组合后，才决定故障场景下应该期待什么行为：

组合 含义 适合场景 注意点
DW_MODE=MANUAL + MON_DW_CONFIRM=0 手动切换 + 普通监视器 学习环境、人工值守、计划切换 监视器能看状态，也能发起 switchover 等命令，但主库故障后不会自动接管
DW_MODE=AUTO + MON_DW_CONFIRM=1 自动切换 + 确认监视器 需要自动故障接管的生产环境 确认监视器参与状态确认和自动接管，应部署在独立节点，生产上更建议多实例确认监视器
DW_MODE=AUTO + MON_DW_CONFIRM=0 守护进程是自动模式，但监视器不是确认模式 不建议作为自动切换方案 自动切换依赖确认监视器，只有普通监视器时不能按自动故障接管来预期
DW_MODE=MANUAL + MON_DW_CONFIRM=1 有确认监视器，但守护进程仍按手动模式运行 特殊维护或过渡配置 不能因为监视器是确认模式，就认为系统会自动切换；切换策略仍要看 DW_MODE

排查时可以按这个顺序看：

  1. 先看 dmwatcher.ini 的 DW_MODE，确认集群设计是手动还是自动。
  2. 再看 dmmonitor.ini 的 MON_DW_CONFIRM，确认当前监视器是不是确认监视器。
  3. 如果期望自动接管，还要确认确认监视器已启动，并且 MON_DW_IP 能连到各节点的 MAL_HOST:MAL_DW_PORT。
  4. 如果只是学习环境或手动切换环境，MON_DW_CONFIRM=0 并不是错误，但故障处理需要人工操作。

来源： 《DM8数据守护与读写分离集群V4.0》4.1 监视器类型、5.4 dmwatcher.ini、5.5 dmmonitor.ini。

6. OGUID 是守护系统身份

本实验使用：

ini 复制代码 
INST_OGUID = 45331
MON_INST_OGUID = 45331

OGUID 用来标识同一个守护系统。数据库实例、守护进程、监视器的 OGUID 不一致时，节点可能无法归入同一组，监视器也难以正确判断主备关系。

来源： 《DM8数据守护与读写分离集群V4.0》7.3.3.6 设置 OGUID、7.3.4.6 设置 OGUID。

四、关键配置理解

这一部分不按手册逐项抄参数，而是关注"参数会影响什么现象"。

1. dm.ini

配置项 影响
MAL_INI=1 是否启用 MAL 通信，影响主备日志传输和集群消息通信
ARCH_INI=1 是否启用归档配置，影响主库能否向备库同步
ALTER_MODE_STATUS=0 限制手工修改实例模式、状态、OGUID，降低误操作风险
RLOG_SEND_APPLY_MON=64 记录最近日志发送和重演统计，便于分析同步状态
DW_INACTIVE_INTERVAL=60 影响实例和守护进程之间消息超时判断

来源： 《DM8数据守护与读写分离集群V4.0》5.1 dm.ini。

2. dmarch.ini

配置项 影响
ARCH_TYPE=REALTIME 实时归档，主库先发送 Redo 到备库，再写本地联机日志
ARCH_TYPE=TIMELY 即时归档，主库写本地联机日志后再发送到备库
ARCH_DEST 远程归档目标实例名，影响日志发往哪个备库
ARCH_WAIT_APPLY=1 事务一致模式，主库提交等待备库重演完成
ARCH_WAIT_APPLY=0 高性能模式，主库提交更快，备库可能短暂旧读

来源： 《DM8数据守护与读写分离集群V4.0》5.3 dmarch.ini、2.6.1 归档流程、2.6.4 性能调整。

3. dmmal.ini

配置项 影响
MAL_INST_NAME 实例身份识别，需与 INSTANCE_NAME 对应
MAL_HOST 主备内部通信地址
MAL_INST_HOST 客户端或接口获取到的实例服务地址
MAL_INST_PORT 实例服务端口，需与 PORT_NUM 对应
MAL_DW_PORT 守护进程通信端口，监视器也通过它连接

来源： 《DM8数据守护与读写分离集群V4.0》5.2 dmmal.ini。

4. dmwatcher.ini

配置项 影响
DW_MODE 决定故障手动切换还是自动切换
DW_ERROR_TIME 远程守护进程故障判断时间
INST_ERROR_TIME 本地实例故障判断时间
INST_RECOVER_TIME 故障节点恢复后尝试 Recovery 的间隔
INST_AUTO_RESTART 实例异常时是否由守护进程自动拉起

来源： 《DM8数据守护与读写分离集群V4.0》5.4 dmwatcher.ini。

5. dmmonitor.ini

配置项 影响
MON_DW_CONFIRM 决定普通监视器或确认监视器
MON_INST_OGUID 监视器加入哪个守护系统
MON_DW_IP 监视器连接哪些守护进程，地址对应 MAL_HOST:MAL_DW_PORT

来源： 《DM8数据守护与读写分离集群V4.0》4.1 监视器类型、5.5 dmmonitor.ini。

6. dm_svc.conf

配置项 影响
服务名 应用是否通过集群服务名访问，而不是直连单个 IP
LOGIN_MODE 优先连接 Primary、Standby 或 Normal 的策略
RW_SEPARATE 是否启用读写分离
RW_PERCENT 分发到主库的读事务比例
SWITCH_TIMES 故障连接时遍历节点的尝试次数
SWITCH_INTERVAL 每次切换尝试的时间间隔

来源： 《DM8数据守护与读写分离集群V4.0》5.8 服务名配置、2.6.4 性能调整。

五、模式总结：实时归档、即时归档、事务一致、高性能

这一节最容易混淆，因为 REALTIME、TIMELY、ARCH_WAIT_APPLY=1、ARCH_WAIT_APPLY=0 经常一起出现。可以先把它们拆成两个维度：

  • 归档类型回答的是：主库什么时候把 Redo 发给备库。
  • 响应策略回答的是：备库收到 Redo 后，主库要不要等备库重演完成再响应事务提交。

也就是说，ARCH_TYPE 管"日志发送时机"，ARCH_WAIT_APPLY 或归档目标上的 WAIT_APPLY 管"是否等待重演"。这两个维度可以组合，不能简单理解成"实时归档就是事务一致"或"即时归档就是高性能"。

1. 归档类型

归档类型主要看 dmarch.ini 中的 ARCH_TYPE。

归档类型 配置 日志发送时机 对读写分离的影响
实时归档 ARCH_TYPE=REALTIME 主库先把 RLOG_PKG 发送到备库，再写本地联机 Redo 日志 更关注故障恢复和避免接管后的分裂风险；实时读写分离默认高性能模式
即时归档 ARCH_TYPE=TIMELY 主库先写本地联机 Redo 日志，再发送 RLOG_PKG 到备库 读写分离集群常见方式；即时归档默认事务一致模式
异步归档 ARCH_TYPE=ASYNC 按异步机制同步日志 更偏向容灾或报表场景，不作为本文读写分离主线

实时归档和即时归档的关键差别是"先发日志还是先写本地日志"。实时归档先发给备库，因此会涉及 KEEP_RLOG_PKG 这类机制；即时归档是在主库本地日志已写入后再发送，所以即时备库不需要 KEEP_RLOG_PKG，收到 RLOG_PKG 后可以直接进入 Apply 任务系统。

这里要注意：归档类型本身不等于查询一致性。查询一致性还要继续看响应策略，也就是 ARCH_WAIT_APPLY 或 WAIT_APPLY。

来源： 《DM8数据守护与读写分离集群V4.0》2.2.9 KEEP_RLOG_PKG 介绍、2.2.11.4 实时归档、2.2.11.5 即时归档、2.6.1 归档流程。

2. 响应策略

响应策略主要看 dmarch.ini 中的 ARCH_WAIT_APPLY，或具体归档目标上的 WAIT_APPLY。如果归档目标单独配置了 WAIT_APPLY，通常以归档目标上的配置为准；否则使用全局 ARCH_WAIT_APPLY。

响应策略 配置 主库何时响应提交 结果
事务一致模式 ARCH_WAIT_APPLY=1 或 WAIT_APPLY=1 等备库完成 Redo 重演后再响应 备库查询一致性更强，但事务提交时间会变长
高性能模式 ARCH_WAIT_APPLY=0 或 WAIT_APPLY=0 备库收到 Redo 后即可响应，随后再重演 主库提交更快，但备库可能短时间读到旧数据

业务侧可以这样判断：

  • 提交后马上要求备库读到最新结果，应关注事务一致模式。
  • 更关注吞吐量，且允许短暂同步延迟，可以关注高性能模式。

响应策略影响的是"提交确认"和"备库查询新鲜度"，不是日志发送顺序。即使同样是即时归档，也可以通过 ARCH_WAIT_APPLY 在事务一致和高性能之间取舍；同样，实时读写分离也支持这两种策略，只是默认值和限制不同。

来源： 《DM8数据守护与读写分离集群V4.0》2.2.11.5 即时归档、2.6.3 事务一致性、2.6.4 性能调整、5.3 dmarch.ini。

3. 两个维度组合后怎么看

把归档类型和响应策略放到一起看，关系会更清楚：

组合 日志发送时机 提交响应特点 适合关注
TIMELY + ARCH_WAIT_APPLY=1 先写主库本地日志，再发备库 等备库重演后响应提交 查询一致性，读写分离常见默认理解
TIMELY + ARCH_WAIT_APPLY=0 先写主库本地日志，再发备库 备库收到日志后即可响应，不等重演 降低提交等待，允许短暂旧读
REALTIME + ARCH_WAIT_APPLY=0 先发备库，再写主库本地日志 默认高性能方式，不等备库重演 可用性和故障恢复，实时读写分离默认方式
REALTIME + ARCH_WAIT_APPLY=1 先发备库，再写主库本地日志 等备库重演后响应提交 需要自动切换模式支持；不能只看参数值

所以判断一个读写分离集群的模式，建议按三步看：

  1. 先看 ARCH_TYPE，确认是 TIMELY 还是 REALTIME，判断日志发送时机。
  2. 再看 ARCH_WAIT_APPLY 或 WAIT_APPLY，判断主库提交是否等待备库重演。
  3. 如果是 REALTIME + ARCH_WAIT_APPLY=1，还要看 DW_MODE 和确认监视器，因为实时读写分离的事务一致模式只在自动切换模式下生效。

来源： 《DM8数据守护与读写分离集群V4.0》2.2.11.4 实时归档、2.2.11.5 即时归档、2.6.5 实时归档的读写分离、5.3 dmarch.ini。

3. 实时读写分离的限制

实时归档也可以用于读写分离，并且同样通过 ARCH_WAIT_APPLY 区分事务一致模式和高性能模式。需要注意的是，实时读写分离的事务一致模式仅在数据守护配置为自动切换模式时生效。因此判断实时读写分离是否处于事务一致模式，不能只看 ARCH_WAIT_APPLY=1，还要结合 DW_MODE、MON_DW_CONFIRM 和监视器部署。

来源： 《DM8数据守护与读写分离集群V4.0》2.6.5 实时归档的读写分离。

六、读写分离的实现逻辑

读写分离的入口是服务名和接口层配置。以实验环境为例：

ini 复制代码 
DW1=(192.168.166.131:15236, 192.168.166.132:15236)

[DW1]
SWITCH_TIMES=(300)
SWITCH_INTERVAL=(200)
RW_SEPARATE=(1)
RW_PERCENT=(25)

应用通过服务名连接：

text 复制代码 
jdbc:dm://DW1

执行逻辑可以概括为：

  1. 接口读取 dm_svc.conf。
  2. 客户端按服务名建立连接。
  3. 接口先连接主库，并获取可用备库信息。
  4. 接口建立备库影子连接。
  5. SQL 先尝试发往备库。
  6. 只读 SQL 在备库执行成功后返回。
  7. 写 SQL 在备库执行失败后转到主库。
  8. 同一事务内一旦转到主库，后续 SQL 继续走主库，直到提交或回滚。

因此，开启读写分离不代表所有 SELECT 都会到备库。事务状态、语句类型、RW_PERCENT、备库状态都会影响最终路由。

来源： 《DM8数据守护与读写分离集群V4.0》2.6.2 实现原理、5.8 服务名配置。

七、扩容节点：从 1 主 1 备扩展到 1 主 2 备

以现有 DW1_01、DW1_02、GDW1 为基础，可以把新增节点规划为 DW1_03，IP 使用 192.168.166.134，作为第二个备库加入同一守护组。

项目 新增备库
主机名 dmdw03
业务 IP 192.168.166.134
心跳 IP 192.168.166.134
实例名 DW1_03
数据库端口 15236
MAL 端口 5336
守护进程通信端口 5436
实例监听守护端口 5536
守护组 GDW1
OGUID 45331

扩容的主线不是"多装一个库"，而是让新节点同时进入主备同步、守护监控和客户端访问三条链路。

  1. 新节点先完成系统用户、目录、版本、补丁、时间同步和端口连通性准备。
  2. 新备库仍然要从当前主库备份恢复，恢复后执行 UPDATE DB_MAGIC，保证物理同源。
  3. 新节点 dm.ini 修改为自己的 INSTANCE_NAME=DW1_03，同时启用 MAL_INI、ARCH_INI、RLOG_SEND_APPLY_MON 等集群相关参数。
  4. 所有节点的 dmmal.ini 都要加入 DW1_03 的 MAL 信息，不能只改新增节点。
  5. 所有可能成为主库的节点都要重新审视 dmarch.ini。当前主库要能向 DW1_03 发送日志；如果 DW1_02 或 DW1_03 将来可能切为主库，也要考虑它们切换后的归档目标。
  6. 新节点 dmwatcher.ini 需要和守护组保持一致，重点核对 GROUP_NAME=GDW1、DW_MODE、INST_OGUID=45331。
  7. 监视器 dmmonitor.ini 需要增加新节点的 MON_DW_IP=192.168.166.134:5436。
  8. 如果希望客户端把只读请求分担到新备库，客户端侧 dm_svc.conf 服务名列表也要加入 192.168.166.134:15236。

扩容重点是"老节点也要知道新节点"。dmmal.ini、dmarch.ini、dmmonitor.ini、dm_svc.conf 分别影响通信、归档、监控和访问，其中任何一层漏改，都会出现"数据库能启动，但集群行为不完整"的情况。

来源： 《DM8数据守护与读写分离集群V4.0》7.3.5 配置备库 GRP1_RWW_03、5.8 服务名配置。

扩容完成后，建议按下面顺序确认：

检查项 关注点
监视器 show 是否能看到 DW1_03，实例模式应为 Standby，实例状态应为 Open。
监视器 list 守护进程配置是否包含新节点
主备 LSN 新备库 LSN 是否持续推进
归档状态 主库到新备库的远程归档是否有效
服务名访问 加入 dm_svc.conf 后，客户端是否能识别三节点服务名

来源： 《DM8数据守护与读写分离集群V4.0》6.20 实时/读写分离/MPP 备库数据同步情况分析、5.8 服务名配置。

八、遇到问题怎么排查：先判断问题落在哪一层

先判断问题属于哪一层，再去看对应配置和现象。

排查顺序可以按"四层"来走：

  1. 客户端层：确认应用是否通过服务名访问，dm_svc.conf 是否生效，直连和服务名连接现象是否一致。
  2. 守护层：用监视器 show 看主备角色、状态、LSN 和守护进程状态。
  3. 同步层：看 dmarch.ini、dmmal.ini、归档目录、MAL 网络，判断日志是否能发、能收、能重演。
  4. 切换层：涉及 Switchover 或 Takeover 时，先用 choose switchover 判断候选，再看 LSN、归档状态和守护状态是否满足切换条件。

几个常见现象可以这样收敛：

  • 服务名连不上：先用直连 IP 对比，再看 dm_svc.conf 是否在客户端可读取位置，连接串是否真的走服务名。
  • 读写分离不明显：不要只看 SELECT。如果事务里已经发生写操作，后续查询会绑定主库；如果备库不可用，请求也可能回到主库。
  • 备库读到旧数据：先看当前是事务一致模式还是高性能模式，再看主备 LSN、RSTAT 和归档状态。高性能模式允许短暂旧读。
  • 监视器看不到节点：先核对 MON_DW_IP 是否对应 MAL_HOST:MAL_DW_PORT，再看 OGUID 和守护进程是否正常启动。
  • 新备库加不进来：优先确认备库是否来自主库备份恢复，是否执行 UPDATE DB_MAGIC，再看实例模式、OGUID 和 MAL 配置。
  • 计划切换没有候选：先看备库是否是 Standby + Open，再看归档状态、LSN 差距和 choose switchover 的返回结果。

这种分层方式的好处是不会被单个参数带偏。比如"读写分离不生效"，可能是 RW_SEPARATE 没开，也可能是事务已经绑定主库，还可能是备库不可用后请求回到了主库；先确定层次，再看配置，判断会更稳。

来源： 《DM8数据守护与读写分离集群V4.0》2.6.2 实现原理、2.6.3 事务一致性、6.5 主备库切换、6.20 实时/读写分离/MPP 备库数据同步情况分析。

九、本次学习成果

通过这次整理，我对读写分离集群的理解从"部署步骤"推进到了"配置与现象的对应关系"。读写分离不是简单把 SELECT 发到备库，而是依赖主备同步、守护监控和客户端接口共同完成。

后续再看这类环境时，我会优先关注三件事：备库是否物理同源，ARCH_TYPE 与 ARCH_WAIT_APPLY 分别影响什么，客户端是否真正通过 dm_svc.conf 触发读写分离。扩容或排查时，也要把客户端、归档同步、守护进程和监视器放在一起看。

来源： 《DM8数据守护与读写分离集群V4.0》2.6 读写分离集群、2.6.2 实现原理、2.6.3 事务一致性、5.8 服务名配置。

拓展参考资料

相关推荐
yuzhiboyouye1 小时前
聚合与分组统计 (GROUP BY）常用于web前端什么场景中
数据库
AllData公司负责人1 小时前
亲测丝滑，体验跃迁｜AllData通过集成开源项目StreamPark，实时流任务调度更省心！
java·大数据·数据库·人工智能·算法·实时计算·实时开发平台
Harm灬小海1 小时前
【云计算学习之路】学习Centos7系统：服务搭建(VSFTP)
linux·运维·服务器·学习·云计算
可涵不会debug1 小时前
工业大数据时序数据库选型方法论：核心指标与技术适配分析
大数据·数据库·时序数据库
DolphinDB智臾科技1 小时前
时序数据库国产替代的下一站：从能用到好用，再到敢用作核心
数据库·人工智能·时序数据库
阿坤带你走近大数据2 小时前
Hbase的基本概念，基本用法及常见使用场景
大数据·数据库·hbase
Ws＿2 小时前
C# 学习 Day1
开发语言·学习·c#
z200509302 小时前
【linux学习】linux工具篇（下）
linux·学习
阿坤带你走近大数据2 小时前
mysql从5.7升级到8.0后ONLY_FULL_GROUP_BY是升级后应用报错的第一大原因
数据库·mysql
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03装上就回不去了：CodeGraph 让 AI 编程效率飙升 92%，它到底做了什么？04【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法05【AI】2026 年具身智能模型和世界模型总结06裂开！ChatGPT 居然开始要手机号验证，附详细解决方法07CC-Switch & Claude 基于 Linux 服务器安装使用指南08几个好用的ip纯净度检测网站09用了半年 OpenRouter，我换到了 Ofox.ai — 两个 AI API 聚合平台的真实对比10codex app每次打开重连5次Reconnecting问题解决