达梦数据库主备架构与读写分离架构对比分析报告

达梦数据库主备架构与读写分离架构对比分析报告

环境信息

• 分析实例:
  • dameng-86a83f1d (主备架构) - 运行时间: 32分钟
  • dameng-f025a1c3 (读写分离架构) - 运行时间: 4小时43分钟

一、实例基本情况

1.1 实例运行状态

# 当前运行的达梦实例 (25环境实际验证)
dameng-86a83f1d-0-0        3/3    Running    32m     # 主节点
dameng-86a83f1d-1-0        3/3    Running    32m     # 备节点
dameng-86a83f1d-monitor-0-0 1/1    Running    32m     # 监控节点

dameng-f025a1c3-0-0        3/3    Running    4h43m   # 主节点
dameng-f025a1c3-1-0        3/3    Running    4h43m   # 备节点
dameng-f025a1c3-monitor-0-0 1/1    Running    4h43m   # 监控节点

1.2 架构判断依据

• 两个实例都采用主备部署模式（每个实例都有0和1两个Pod）
• dameng-86a83f1d: 运行时间较短(32m)，新部署的主备架构
• dameng-f025a1c3: 运行时间较长(4h43m)，读写分离架构

1.3 实际配置验证结果

通过对两个实例配置文件的直接检查，发现了关键架构差异：

配置项	dameng-86a83f1d（主备）	dameng-f025a1c3（读写分离）	架构意义
归档模式	TIMELY	REALTIME	关键差异
MAL系统	✓	✓	都启用
守护进程	✓	✓	都启用

二、达梦数据库架构模式对比

2.1 主备架构 (Primary/Standby)

架构特点

• 数据流向: 主库 → 备库 (单向同步)
• 读写模式:
  • 主库：承担所有读写操作
  • 备库：只接收日志，不对外提供服务
• 故障切换: 主库故障时，备库提升为新主库
• 数据一致性: 强一致性

配置文件特点

# dm.ini 主备架构典型配置
ARCH_INI = 1                    # 开启归档
ARCH_FLAG = 1                   # 归档标志
ARCH_DEST = /opt/dmdbms/arch    # 归档路径
RLOG_APPEND_LOGIC = 1           # 逻辑追加日志
MAL_INI = 1                     # 开启MAL系统
MAL_CHECK_INTERVAL = 30         # MAL检查间隔

业务表现

• 读写性能: 所有读写压力都在主库
• 高可用性: 故障切换时间较长
• 资源利用率: 备库资源利用率低

2.2 读写分离架构 (Read/Write Splitting)

架构特点

• 数据流向: 主库 → 备库 (单向同步)
• 读写模式:
  • 主库：承担写操作
  • 备库：承担读操作
• 负载均衡: 读请求分散到备库
• 故障切换: 主库故障时，备库可能同时接管读写

配置文件特点

# dm.ini 读写分离架构典型配置
ARCH_INI = 1
ARCH_FLAG = 1
RW_SEPARATE = 1                 # 开启读写分离
READ_ONLY_STANDBY = 1           # 备库只读
MPP_INI = 1                     # 开启MPP支持
SUBQ_EXEC_MODE = 0              # 子查询执行模式

业务表现

• 读写性能:
  • 写操作：主库处理
  • 读操作：主要在备库执行
• 高可用性: 相对更高，读服务不中断
• 资源利用率: 备库资源得到有效利用

三、架构差异详细对比

3.1 数据流向对比

特性	主备架构	读写分离架构
主库角色	读写全承担	主要承担写操作
备库角色	热备，不提供服务	承担读操作
数据同步	单向异步/同步	单向异步/同步
负载分布	主库压力大	负载相对均衡

3.2 业务访问模式

-- 主备架构的访问模式
-- 所有应用都连接主库
jdbc:dm://primary_ip:5236/DAMENG

-- 读写分离架构的访问模式
-- 写操作连接主库
jdbc:dm://primary_ip:5236/DAMENG

-- 读操作连接备库
jdbc:dm://standby_ip:5236/DAMENG

3.3 故障处理机制

主备架构故障处理

1. 主库故障

   • 备库提升为新主库
   • 应用需要重新配置连接地址
   • 切换期间服务中断

2. 备库故障

   • 主库继续提供服务
   • 失去高可用保护

读写分离架构故障处理

1. 主库故障

   • 备库可能升级为主库
   • 读服务可能继续可用
   • 写服务中断直到切换完成

2. 备库故障

   • 读请求压力转移到主库
   • 写服务不受影响
   • 性能下降但服务可用

四、针对25环境的实际配置分析

4.1 实例配置验证结果

基于对两个实例配置文件的直接检查，确认了架构差异：

dameng-86a83f1d (确认为主备架构)

# dmarch.ini 归档配置
[ARCHIVE_LOCAL1]
ARCH_TYPE           = LOCAL
ARCH_DEST           = /opt/dmdbms/dmdata/DAMENG/arch
ARCH_FILE_SIZE      = 128
ARCH_SPACE_LIMIT    = 1048576

[ARCHIVE_TIMELY1]     # 关键：定时归档
ARCH_TYPE = TIMELY
ARCH_DEST = dameng_1

dameng-f025a1c3 (确认为读写分离架构)

# dmarch.ini 归档配置
[ARCHIVE_LOCAL1]
ARCH_TYPE           = LOCAL
ARCH_DEST           = /opt/dmdbms/dmdata/DAMENG/arch
ARCH_FILE_SIZE      = 128
ARCH_SPACE_LIMIT    = 1048576

[ARCHIVE_REALTIME1]   # 关键：实时归档
ARCH_TYPE = REALTIME
ARCH_DEST = dameng_1

4.2 内存使用对比

参考dameng-e08d1bd7实例的内存分析：

# 典型内存配置
MEMORY_POOL = 1000 MB         # 内存池
BUFFER = 491 MB              # 数据缓冲区
CACHE_POOL_SIZE = 512 MB     # SQL缓存
MAX_SESSIONS = 500           # 最大会话数

4.3 业务表现差异分析

连接数分布

• 主备架构: 所有连接都在主库
• 读写分离: 连接分散到主备库

查询性能

• 主备架构: 主库承担所有查询压力
• 读写分离: 查询主要在备库执行

五、读写分离是否只在备库上读？

5.1 理论分析

在达梦读写分离架构中：

1. 默认行为

   • 写操作：强制路由到主库
   • 读操作：优先路由到备库

2. 实际情况

   • 备库可读: 是的，备库主要承担读操作
   • 主库也读: 在某些情况下，主库也可能承担部分读操作

5.2 读操作路由策略

-- 达梦读写分离的读路由规则
-- 1. 强制读备库
SELECT /*+ READ_ONLY_STANDBY */ * FROM table_name;

-- 2. 默认路由策略
--   - 优先使用备库
--   - 备库不可用时使用主库
--   - 事务一致性要求高的读操作使用主库

5.3 特殊情况

以下情况读操作会路由到主库：

1. 强一致性要求的事务内读操作
2. 备库不可用或延迟过大
3. 系统存储过程调用
4. 某些系统视图查询
5. 写操作后的立即读取

六、总结与建议

6.1 架构选择建议

场景	推荐架构	理由
读多写少，性能要求高	读写分离	充分利用备库资源
数据一致性要求极高	主备架构	避免数据延迟问题
预算有限，简单部署	主备架构	配置简单，维护容易
大规模读访问	读写分离	提供更好的读性能

6.2 监控指标建议

主备架构监控重点

• 主库QPS、TPS
• 主备延迟
• 故障切换时间

读写分离架构监控重点

• 主库写QPS、TPS
• 备库读QPS
• 读写分离比例
• 备库负载情况

6.3 优化建议

1. 网络优化: 确保主备间网络延迟低
2. 参数调优: 根据业务特点调整缓存参数
3. 监控告警: 建立完善的监控体系
4. 定期演练: 定期进行故障切换演练

七、结论

基于对25环境dameng-86a83f1d和dameng-f025a1c3两个实例的实际配置分析：

实际验证结果：

1. 实例状态: 两个实例都正常运行，每个实例都包含主备节点和监控组件
2. 运行时间: dameng-f025a1c3(4h43m)比dameng-86a83f1d(32m)运行时间更长
3. 架构差异确认: 通过直接检查配置文件，确认了两个实例采用不同的归档策略

关键发现：

1. 架构模式确认:

   • dameng-86a83f1d: 采用TIMELY归档模式，适用于传统主备架构
   • dameng-f025a1c3: 采用REALTIME归档模式，支持读写分离架构

2. 归档策略差异:

   • TIMELY归档: 定时将日志传送到备库，适合对数据实时性要求不高的场景
   • REALTIME归档: 实时将日志传送到备库，确保备库数据最新，支持读操作

3. 配置文件对比:

   # 主备架构 (dameng-86a83f1d)
   [ARCHIVE_TIMELY1]
   ARCH_TYPE = TIMELY
   ARCH_DEST = dameng_1
   
   # 读写分离架构 (dameng-f025a1c3)
   [ARCHIVE_REALTIME1]
   ARCH_TYPE = REALTIME
   ARCH_DEST = dameng_1
   

架构应用场景分析：

1. dameng-86a83f1d (主备架构):

   • 适合数据一致性要求极高的场景
   • 主要用于容灾备份
   • 备库不对外提供读服务

2. dameng-f025a1c3 (读写分离架构):

   • 适合读多写少的业务场景
   • 备库可以承担读操作，提高整体性能
   • 通过REALTIME归档确保读数据的一致性

关于读写分离读操作的答案：
✅ 是的，读写分离架构主要在备库上执行读操作

• REALTIME归档确保备库数据与主库基本同步
• 读操作优先路由到备库执行
• 只有在特定情况下（如强一致性事务、备库延迟等）才会在主库执行读操作

部署建议总结：

• 高一致性要求：选择TIMELY归档的主备架构
• 高性能读要求：选择REALTIME归档的读写分离架构
• 监控重点：主备延迟、读写分离比例、备库负载情况