MySQL 总结

大型互联网后台中，MySQL 作为关系型数据库如何承担核心数据存储，以及如何通过主从复制、MHA、MMM、MGR 等方案构建高可用架构。

核心主线

整体逻辑可以概括为：

1
2
3
4
5
6
7
8
9

用户请求最终表现为数据读/写
        ↓
RPC 服务访问存储层
        ↓
MySQL 承担核心关系型数据存储
        ↓
通过主从复制保证副本数据同步
        ↓
通过 MHA / MMM / MGR 等方案实现故障切换和高可用

MySQL 是大型互联网后台最常见的核心持久化存储，重点不只是会用 SQL，而是要理解它在生产环境中的高可用架构。

1. 关系型数据库的基本概念

关系型数据库使用关系模型组织数据，最直观的表现形式就是二维表。

在关系型数据库中：

• 行：表示一条实体记录，或实体之间的一条关系记录；
• 列：表示记录的属性；
• 表：由一组行和列组成；
• 数据库：由一组数据表组成；
• SQL：用于定义和操作数据的结构化查询语言。

例如学生选课系统中，可以有：

• 学生信息表；
• 教师信息表；
• 课程信息表；
• 选课信息表；
• 教课信息表。

其中实体和实体之间的关系都可以被表达为二维表。

2. 主键的作用

关系型数据库中的一个重要概念是主键。

主键用于唯一标识一行记录，可以由：

• 单个字段组成；
• 多个字段共同组成。

例如：

• 学生信息表中，学号 可以作为主键；
• 选课信息表中，学号 + 课号 可以共同作为主键，因为它们共同唯一标识一条选课关系。

主键的核心意义是：唯一定位数据记录。

3. MySQL 的优势

MySQL 是最典型、最常用的开源关系型数据库之一，在大型互联网后台中应用非常广泛。

它的主要优势包括：

• 易于使用：生态成熟，工具丰富；
• 功能强大：支持事务、触发器、存储过程等；
• 可承载较大规模数据：可以作为千万级记录量的大型数据库；
• 开源可定制：采用 GPL 开源协议，工程师可以基于源码进行定制；
• 事务可靠：InnoDB 存储引擎符合 ACID 模型，能保证数据完整性和可靠性。

4. MySQL 高可用架构一：主从模式

基本结构

最基础的 MySQL 高可用方案是主从模式：

1
2
3
4
5

Master：处理写请求
  ↓ 复制数据
Slave 1：保存副本
Slave 2：保存副本
...

正常情况下：

• Master 负责写数据；
• Slave 从 Master 复制数据；
• Master 宕机后，可以将某个 Slave 提升为新的 Master。

主从模式的高可用基础是：主从复制。

5. MySQL 主从复制原理

MySQL 主从复制的核心流程如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

Master 数据变更
  ↓
写入 binlog
  ↓
Slave I/O 线程读取 Master binlog
  ↓
写入 Slave relay log
  ↓
Slave SQL 线程读取 relay log
  ↓
在 Slave 本地回放 SQL
  ↓
Slave 数据与 Master 保持一致

关键组件：

6. 异步复制与数据丢失风险

默认的 MySQL 主从复制是异步复制。

也就是说：

1
2

Master 提交事务后直接返回
不会等待 Slave 确认是否收到 binlog

这会带来一个风险：

1
2
3
4
5
6
7
8
9

Master 提交事务成功
  ↓
还没把 binlog 发给 Slave
  ↓
Master 宕机
  ↓
Slave 被提升为新 Master
  ↓
这笔事务数据丢失

因此，异步复制性能好，但一致性风险更高。

7. 半同步复制

为降低数据丢失风险，MySQL 5.5 引入了半同步复制。

半同步复制的流程是：

1
2
3
4
5
6
7
8
9

Master 执行事务
  ↓
写 binlog
  ↓
等待至少一个 Slave 收到 binlog 并写入 relay log
  ↓
Slave 返回 ACK
  ↓
Master 提交事务

注意：Slave 返回 ACK 的时机不是执行完 SQL，而是把事务日志写入 relay log 之后。

这样做的好处是：

• 事务数据已经在至少一个 Slave 上持久化；
• 相比等待 Slave 完成 SQL 回放，延迟更低；
• 数据丢失风险显著下降。

代价是：

• Master 提交事务需要等待 Slave 确认；
• 写性能会下降；
• 更适合对一致性要求较高的业务。

8. 复制风暴问题

如果 Master 同时向大量 Slave 复制数据，Master 的复制压力会很大，这被称为复制风暴。

解决思路是构建层级复制：

1
2
3
4
5

Master
  ↓
一级 Slave
  ↓
二级 Slave

也就是让部分 Slave 再向其他 Slave 复制数据，从而减轻 Master 压力。

9. MySQL 高可用架构二：MHA

MHA 的定位

MHA，全称 Master High Availability，是 MySQL 主从高可用领域较成熟的方案。

它主要解决两个问题：

• 自动检测 Master 故障；
• 自动完成主从切换。

通常可以在 10～30 秒 内完成故障检测和切换，并尽可能保证主从数据一致。

MHA 的组成

MHA 故障转移流程

1
2
3
4
5
6
7
8
9
10
11

MHA Manager 周期性探测 Master 心跳
  ↓
连续多次探测失败，判断 Master 宕机
  ↓
检查各个 Slave 的 binlog / relay log 状态
  ↓
选择数据最接近 Master 的 Slave 作为新 Master
  ↓
尽量补齐 Slave 与 Master 或 Slave 之间的数据差异
  ↓
将其他 Slave 重新指向新 Master

MHA 的核心思想是：选出数据最新的 Slave，并尽量补齐缺失日志，最大程度降低主从切换时的数据丢失风险。

如果 MHA 与半同步复制结合使用，效果更好，因为半同步复制通常能保证至少一个 Slave 拥有和 Master 一致的数据。

10. MySQL 高可用架构三：MMM

MMM，全称 Multi-Master Replication Manager for MySQL，是一个用于 MySQL 双主故障切换和双主管理的脚本组件。

MMM 基本架构

1
2
3
4
5
6
7

Master 1：真正处理写请求
Master 2：备用 Master，与 Master 1 相互复制
Slave：负责读请求，从 Master 复制数据
mmm-monitor：监控和决策节点
mmm-agent：部署在每台 MySQL 上的代理
write vip：对外写服务虚拟 IP
read vip：对外读服务虚拟 IP

MMM 故障切换流程

当 Master 1 宕机：

1
2
3
4
5
6
7
8
9

monitor 发现 Master 1 不可用
  ↓
请求 Master 1 移除 write vip
  ↓
请求 Master 2 绑定 write vip
  ↓
Master 2 接管写请求
  ↓
通知 Slave 改为向 Master 2 复制数据

MMM 的核心机制是：通过移动 write vip，让备用 Master 快速接管写请求。

MMM 的局限

书中指出，MMM 比较古老：

• 不支持 MySQL GTID；
• 社区活跃度不足；
• 当前组件处于无人维护状态。

因此更多作为理解历史方案和思路的参考。

11. MySQL 高可用架构四：MGR

MGR，全称 MySQL Group Replication，MySQL 组复制，是 MySQL 5.7.17 推出的高可用方案。

MGR 的主要特性

MGR 的提交机制

MGR 至少由 3 个 MySQL 节点组成一个复制组。

一个事务必须经过复制组内超过半数节点决议通过后才能提交。

例如 3 个节点组成复制组：

1
2
3
4
5
6
7

事务提交
  ↓
组内节点进行 certify 决议
  ↓
至少 2 个节点通过
  ↓
事务才能提交

这种机制提升了数据一致性，但也提高了写入成本。

12. MGR 单主模式与多主模式

MGR 支持两种模式。

单主模式

复制组自动选择一个 Master 处理写请求。

如果超过半数节点与 Master 通信失败，MGR 会认为 Master 宕机，并根据节点权重和 ID 自动重新选主。

官方更推荐单主模式。

多主模式

每个 MySQL 节点都可以处理写请求。

但在高并发写场景下，不同节点可能同时执行冲突事务，导致后提交的事务被回滚。

因此，多主模式事务冲突概率较高，不适合高并发写入场景。

13. MGR 的优缺点

优点

• 数据一致性强；
• 容错能力高；
• 自动选主；
• 适合对数据不丢失要求较高的场景。

缺点

• 每个写请求都需要和复制组内多数节点通信；
• 写性能不如异步复制和半同步复制；
• 更适合强一致、写请求量不大的业务场景。

14. 几种 MySQL 高可用方案对比

本节最重要的架构思想

1. MySQL 是大型互联网后台最常见的核心持久化存储。
2. 关系型数据库通过二维表表达实体和实体关系，逻辑清晰、容易理解。
3. 主键用于唯一定位一条数据记录，是表设计的基础概念。
4. MySQL 高可用的基础是主从复制。
5. 异步复制性能好，但存在数据丢失风险。
6. 半同步复制通过等待至少一个 Slave 写入 relay log，降低数据丢失风险，但牺牲写性能。
7. Master 向大量 Slave 复制会引发复制风暴，可以通过层级复制缓解。
8. MHA 通过自动故障检测、选主和日志补齐，实现主从自动切换。
9. MMM 通过移动 VIP 实现双主切换，但方案较老，不适合新系统优先选择。
10. MGR 基于多数派决议提供强一致和高容错，但写性能成本更高。
11. 数据库高可用设计的核心权衡是：性能、一致性、可用性、复杂度。

一句话总结

MySQL 作为大型互联网后台的核心关系型数据库，依靠主从复制构建基础高可用能力；异步复制性能高但可能丢数据，半同步复制提升一致性但降低写性能，MHA、MMM、MGR 则分别从自动切主、VIP 双主切换、组复制强一致等角度解决 MySQL 高可用问题，架构选型需要在性能、一致性、可用性和维护成本之间权衡。