双主模式

适用场景

MySQL双主模式是一种常见的高可用数据库架构方案，特别适合以下业务场景：

1. 业务快速增长阶段

很多创业公司或中小型企业初期通常采用MySQL主从架构，通过一主（写库）多从（读库）的方式实现读写分离。但随着业务规模扩大，这种架构的局限性逐渐显现：

  • 单主节点成为系统瓶颈，所有写操作都集中在一个节点
  • 主库出现故障时，需要手动将从库提升为主库，切换过程复杂且存在数据丢失风险
  • 高峰期可能出现单主库性能不足的问题

2. 高可用性要求高的系统

双主模式通过以下方式提升系统可用性：

  • 两个数据库节点互为主从，形成双向复制
  • 任一节点故障时，另一个节点可立即接管服务
  • 自动故障转移，减少人工干预
  • 避免单点故障，提高系统整体稳定性

3. 读写压力均衡的场景

典型应用包括：

  • 电商平台的订单系统（双主节点可同时处理订单创建和状态更新）
  • 社交媒体的用户数据服务（不同地域用户可以就近写入）
  • 金融交易系统的账务处理（确保交易记录的高可用性）

技术实现细节

双主模式的工作机制：

  1. 数据同步：两个MySQL实例都配置为master，同时又是对方的slave
  2. 冲突处理：通过设置auto_increment_increment和auto_increment_offset避免主键冲突
  3. 复制方式：通常采用基于行的复制(RBR)确保数据一致性
  4. 故障检测：配合keepalived或MHA实现自动故障转移

注意事项

  • 需要确保网络连接稳定，避免复制延迟
  • 建议使用相同版本的MySQL服务器
  • 需要监控复制状态，及时处理复制错误
  • 对应用程序需要做好连接池的故障转移配置

使用双主双写还是双主单写？

建议大家使用双主单写，因为双主双写会有如下的问题：

ID冲突问题

在A主库写入数据时，如果该数据还未同步到B主库，此时对B主库写入数据就会产生ID冲突。具体表现为：

  • 当采用自增ID时，两个主库可能生成相同的ID值
  • 虽然可以通过设置不同的自动增长步长来避免（如A主库设置为奇数步长：1、3、5、7，B主库设置为偶数步长：2、4、6、8），但这种方式会带来：
    • 运维复杂度增加
    • 后续扩展困难
    • 主键值不连续可能导致性能问题

更新丢失问题

当同一条记录在两个主库中同时被更新时，会出现以下情况：

  1. 用户A在Master1更新记录
  2. 用户B在Master2更新同一条记录
  3. 由于异步复制，先更新的数据可能被后更新的数据覆盖
  4. 最终导致部分更新操作丢失

高可用架构建议

推荐的双主单写架构：

  1. 主从结构：

    • 一个Master作为主库处理所有写请求
    • 另一个Master作为热备库，用于高可用切换

  2. 读写分离：

    • 主库下游挂载多个Slave节点
    • Slave节点承担所有读请求

  3. 故障转移：

    • 当主库故障时，备库自动切换为新主库
    • 原主库恢复后自动降级为备库

这种架构既能保证高可用性，又能避免双主双写带来的数据一致性问题。

随着业务发展，架构会从主从模式演变为双主模式，建议用双主单写，再引入高可用组件，例如：Keeplived、MMM等工具，实现主库故障自动切换。

MMM架构

基本介绍

MMM（Master-Master Replication Manager for MySQL）是一套开源的MySQL数据库高可用解决方案，专门用于管理和监控MySQL双主复制架构，并支持主节点故障自动切换。该软件由MySQL社区开发者使用Perl语言编写，最初发布于2008年，广泛应用于需要高可用性的MySQL部署环境。

MMM的核心功能包括：

  1. 监控MySQL主从复制状态
  2. 自动检测节点故障并进行故障转移
  3. 管理虚拟IP地址实现客户端透明切换
  4. 提供节点状态监控和告警功能

虽然MMM采用双主（Master-Master）架构，但实际业务运行时同一时间只有一个节点处于可写状态（Active Master），另一个节点作为热备（Passive Master）。这种设计既保证了高可用性，又避免了双向复制可能带来的数据冲突问题。当活动主节点出现故障时，MMM会自动将写操作切换到备用主节点，同时调整复制关系，确保数据库服务的连续性。

典型应用场景：

  • 电商网站订单数据库
  • 金融交易系统
  • 需要24/7高可用的企业应用

注意事项：

  • 需要配合MySQL的复制功能使用
  • 建议部署在可靠的网络环境中
  • 切换过程中可能会有秒级的服务中断
  • 需要合理配置监控参数以避免误切换

MMM故障处理机制详解

MMM（Master-Master Replication Manager）是一个用于管理MySQL主主复制架构的工具，它能够自动处理节点故障并维护高可用性。该系统主要包含两类角色：

1. 节点角色划分

  • Writer节点：负责处理所有的写操作，通常只有一个活跃的Writer节点
  • Reader节点：负责处理读请求，可以包含多个Slave节点

2. Writer节点故障处理流程

当检测到Writer节点（通常为Master1）出现故障时，MMM会自动执行以下故障转移流程：

  1. VIP移除：立即移除故障节点上的虚拟IP（VIP），避免应用继续连接
  2. 角色切换：
    • 将写操作自动切换到Master2节点
    • 将Master2节点提升为新的Writer角色
  3. 拓扑重构：
    • 重新配置所有Slave节点，使其指向新的Master2节点
    • 更新复制关系，确保数据一致性

3. Slave节点管理机制

MMM不仅管理主节点，还持续监控所有Slave节点的状态，处理以下异常情况：

  • 节点宕机：立即移除该节点的VIP，将其标记为不可用
  • 复制延迟：当延迟超过预设阈值时，自动将该节点从读池中剔除
  • 复制错误：检测到复制错误后，暂停该节点的服务直到问题修复

故障恢复流程：

  1. 持续监控异常节点状态
  2. 当节点恢复正常后：
    • 重新加入复制拓扑
    • 恢复VIP分配
    • 重新加入读池提供服务

4. 典型应用场景

  • 电商网站：确保订单写入不中断
  • 金融服务：保证交易数据一致性
  • 社交平台：维持读服务的高可用性

该机制通过自动化的故障检测和转移，最大程度减少了人工干预需求，确保数据库服务的高可用性。

MMM监控机制详解

1. 系统架构与组件功能

MMM(Master-Master Replication Manager)监控系统采用主从式架构，主要包括两大核心组件：

(1) Monitor监控服务器
  • 核心职责：作为监控系统的中枢神经，持续监测整个MySQL集群的运行状态
  • 部署方式：推荐独立部署在专用监控服务器上，与数据库服务器物理隔离
  • 主要功能：
    • 实时收集各节点健康状态指标（如服务可用性、复制延迟等）
    • 通过心跳检测机制判断节点故障
    • 根据预设策略触发故障转移流程
    • 记录故障事件和切换日志
  • 典型配置：建议部署2台Monitor形成主备架构，避免单点故障
(2) Agent代理程序
  • 运行位置：必须安装在每个MySQL服务器实例上
  • 工作模式：作为常驻进程运行（通常以daemon方式）
  • 核心功能：
    • 监控执行：
      • 定期采集本地MySQL服务状态（如进程状态、端口监听）
      • 检查主从复制状态（Seconds_Behind_Master等）
      • 监控系统资源（CPU、内存、磁盘空间）
    • 命令执行：
      • 接收并执行Monitor下发的管理指令
      • 完成VIP（虚拟IP）的漂移操作
      • 修改MySQL只读/读写状态
      • 控制复制线程启停
  • 通信机制：通过加密通道与Monitor保持心跳通信（默认端口9988）

2. 典型工作流程示例

以主节点故障切换场景为例：

  1. 故障检测阶段：

    • Agent每10秒向Monitor发送心跳包
    • Monitor连续3次未收到主节点心跳响应（可配置）
    • Monitor通过备用通道（如SSH）验证节点状态

  2. 切换决策阶段：

    • Monitor确认主节点不可达（超过阈值时间如30秒）
    • 检查从节点复制延迟是否在允许范围内（如<30秒）
    • 根据优先级选择最合适的从节点晋升

  3. 切换执行阶段：

    • Monitor向新主节点的Agent发送提升指令
    • Agent执行： a. 停止复制线程 b. 重置read_only参数 c. 绑定VIP到新主节点
    • Monitor向其他从节点的Agent发送： a. 修改复制源指向新主 b. 重启复制线程

  4. 状态同步阶段：

    • 各Agent反馈执行结果
    • Monitor更新集群拓扑状态
    • 记录完整切换日志

3. 网络配置要求

为确保监控系统可靠运行，需要满足以下网络条件：

方向协议端口用途
Monitor→AgentTCP9988控制命令传输
Agent→MonitorTCP9989状态报告
Agent之间ICMP-节点间连通性检测
VIP网络--需要二层可达的广播域

4. 高可用性保障措施

  1. Monitor冗余：

    • 部署2个Monitor实例
    • 采用keepalived实现VIP浮动
    • 通过分布式锁协调主备角色

  2. Agent自愈机制：

    • 心跳超时后自动重启
    • 本地状态缓存防止网络分区误判
    • 关键操作前进行预检

  3. 网络可靠性：

    • 建议配置独立的管理网络
    • 重要链路采用bonding多网卡绑定
    • 设置合理的TCP重试参数 slave_parallel_type=LOGICAL_CLOCK binlog_group_commit_sync_delay=10000

## MySQL 8.0 - 基于Writeset的并行复制

- 使用binlog_transaction_dependency_tracking参数
- 支持WRITESET或WRITESET_SESSION模式
- 自动识别行级别无冲突的事务

### 实现原理
- 使用主键哈希
- 更高并行度

## InnoDB两阶段提交

1. Prepare阶段
2. Commit阶段

### binlog标记
- last_committed
- sequence_number

## 性能影响

- 可减少60%-80%的复制延迟
- 可提高30%-50%的CPU利用率