注册
主备集群
专栏/技术分享/ 文章详情 /

主备集群

Eric 2025/08/01 124 0 0
摘要

前言

1 主备集群架构与核心组件

1.1 传统主备架构(DataWatch)

  • 节点角色
    • 主库(Primary)​​:唯一处理读写请求,实时生成Redo日志并通过MAL系统传输
    • 备库(Standby)​​:仅接收Redo日志并重演(Redo Apply),不提供写服务(可配置只读查询)
    • 守护进程(dmwatcher)​​:监控节点状态,主库故障时触发备库自动接管(切换时间<30秒)
    • 监视器(dmmonitor)​​:全局状态监控,支持手动切换和仲裁脑裂
  • 数据同步机制
    • MAL通信系统​:专用网络链路传输Redo日志,通过实时归档(ARCHIVE_REALTIME)确保低延迟同步
    • 强一致性保障​:主库事务提交需等待备库日志落盘(RPO=0)

1.2 RAFT主备集群

Raft 算法:

Raft 算法通过选举一个领导者(Leader)来管理所有复制日志的更新。领导者接收来自客户端的请求,并将这些请求作为日志条目附加到本地日志中,然后通过复制机制将日志条目安全地复制到所有跟随者(Follower)节点上。一旦大多数节点(包括领导者自身)确认了日志条目,该条目就被认为是已提交的,随后可以安全地应用到系统的状态机中。

核心改进​:

  • RAFT协议替代传统守护进程,实现多副本数据一致性(如3节点RAFT组)
  • 节点角色动态选举:Leader(主库)、Follower(备库)、Candidate(选举态)

数据同步流程:

aXdXQr3PG9Jw2n48jtm9X2osrMR_Wsz6ePe0kKrzI.png

2 RAFT主备集群原理

2.1 RAFT在达梦中的实现

RAFT概念 达梦
Leader Primary节点
Follower Standby节点
Log Entry Redo日志
Committed Index 已持久化LSN
  • 关键机制​:
    • 领导者选举​:节点超时未收到心跳自动发起选举,需多数节点投票通过
    • 日志复制​:
      1. Leader发送日志条目(AppendEntries RPC)
      2. Followers持久化日志后返回ACK
      3. Leader收到多数ACK后提交日志
    • 脑裂规避​:任期(Term)递增机制确保仅最新Leader有效

2.2 与传统主备差异对比

维度 传统主备 RAFT主备集群
一致性机制 同步复制(MAL系统) RAFT多数确认
故障切换速度 依赖守护进程检测(秒级) 选举自动完成(毫秒级)
扩展性 仅支持1主多备 支持多节点动态扩展
资源利用率 备库闲置 所有节点参与读写负载均衡

3 主备集群搭建

3.1 环境配置

节点 IP 角色 数据目录
Node1 192.168.1.101 Leader /dm_data/raft1
Node2 192.168.1.102 Follower /dm_data/raft2
Node3 192.168.1.103 Follower /dm_data/raft3

3.2 关键步骤

  1. 每个节点修改dm.ini
INSTANCE_NAME = RAFT_NODE1  # 节点唯一标识
RAFT_GROUP_ID = 1001        # RAFT组ID
RAFT_SELF_ID = 1            # 节点自身ID(1~n)
RAFT_PEERS = "192.168.1.101:5236,192.168.1.102:5236,192.168.1.103:5236" 
  1. 启动流程
  2. 首次启动需强制指定Leader./dmserver dm.ini RAFT_FORCE_LEADER=1 # 仅在初始节点执行
  3. 其他节点以Follower身份加入./dmserver dm.ini RAFT_JOIN=192.168.1.101:5236

4 应用场景

  1. 传统主备适用​:
  • 强一致性要求的金融交易系统(如核心账务)
  • 资源有限的中小型业务(RTO<1分钟)
  1. RAFT主备适用​:
  • 跨地域多活部署(如异地容灾)
  • 高吞吐且允许毫秒级延迟的物联网数据平台
  1. 混合架构示例​:
  • 全局RAFT集群 + 关键分片传统主备(如支付模块双保险)
评论
后发表回复

作者

文章

阅读量

获赞

扫一扫
联系客服