419 lines
15 KiB
Markdown
419 lines
15 KiB
Markdown
---
|
||
tags: [MySQL, 主从复制, Replication, Semi-Sync, GTID]
|
||
create time: 2026-05-16 10:30
|
||
---
|
||
|
||
# 主从复制
|
||
|
||
## 概述
|
||
|
||
MySQL 主从复制是通过 Binlog 将主库的数据变更传播到从库的过程。它是高可用架构的基础组件，也是读写分离的前提。
|
||
|
||
> [!tip] 生活中的类比
|
||
> 想象主库是一位「主播」，从库是「观众」。主播做了一个操作（比如画画），观众通过直播画面（Binlog）看到这个操作，然后在自己的画布上**照着做一遍**。
|
||
>
|
||
> 这个"看到 → 照做"的过程，就是主从复制的本质。
|
||
|
||
> [!question] 为什么需要主从复制？
|
||
> 一台 MySQL 能撑多久？当读请求暴增时，单机性能到顶了怎么办？
|
||
> 主从复制给出了两个关键答案：**读写分离**（主库写、从库读）和**高可用**（主库挂了，从库顶上）。
|
||
|
||
## 复制架构
|
||
|
||
复制的过程可以简化为三个步骤：**主库记录变更** → **网络传输** → **从库重放变更**。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph "Master"
|
||
M1["业务写入 DML"] --> M2["Server 层生成 Binlog"]
|
||
M2 --> M3["Binlog Dump Thread"]
|
||
end
|
||
|
||
subgraph "Network"
|
||
M3 -. "Binlog Stream" .-> I1["IO Thread"]
|
||
end
|
||
|
||
subgraph "Slave"
|
||
I1 --> S1["Relay Log 中继日志"]
|
||
S1 --> S2["SQL Thread"]
|
||
S2 --> S3["数据文件更新"]
|
||
end
|
||
|
||
style M2 fill:#C44569,color:#fff
|
||
style S2 fill:#00B6BC,color:#fff
|
||
```
|
||
|
||
### 三线程模型
|
||
|
||
| 线程 | 归属 | 职责 |
|
||
|------|------|------|
|
||
| **Binlog Dump Thread** | Master | 连接到一个 Slave 就创建一个，负责发送 binlog |
|
||
| **IO Thread** | Slave | 连接 Master，拉取 binlog 写入本地 Relay Log |
|
||
| **SQL Thread** | Slave | 读取 Relay Log 重放应用到本地数据库 |
|
||
|
||
> [!question] 为什么要多一个 Relay Log，而不是直接在从库上执行？
|
||
> 其实这和消息队列的「削峰填谷」是一个道理。Relay Log 起到了**缓冲区**的作用：即使从库暂时卡住了（比如正在做慢查询），主库发来的 Binlog 也不会丢失，先暂存在 Relay Log 里，等从库空闲了再慢慢回放。
|
||
|
||
## 同步模式
|
||
|
||
复制的「同步」和「异步」，核心问题只有一个：**主库写完后，要不要等从库确认？**
|
||
|
||
| 模式 | 等不等从库？ | 数据安全 | 性能 |
|
||
|------|------------|---------|------|
|
||
| **异步** | 不等 | 低（可能丢数据） | 最高 |
|
||
| **半同步** | 至少等 1 个 | 中（大幅降低丢数据概率） | 中 |
|
||
| **组复制** | 等多数派共识 | 高 | 较低 |
|
||
|
||
下面的流程图展示了三种模式的完整过程：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
subgraph "Async 异步复制"
|
||
A1["Client 写入 Master"] --> A2["Master 刷盘返回 OK"]
|
||
A2 -->|"后续"| A3["异步发给 Slave"]
|
||
end
|
||
|
||
subgraph "Semi-Sync 半同步复制"
|
||
S1["Client 写入 Master"] --> S2["Master 刷盘"]
|
||
S2 --> S3["等待至少1个 Slave ACK"]
|
||
S3 -->|"超时10s"| S4["降级为异步"]
|
||
S3 -->|"收到 ACK"| S5["返回 OK"]
|
||
S5 --> S6["异步发给其他 Slave"]
|
||
end
|
||
|
||
subgraph "Group Replication 组复制"
|
||
G1["Client 写入"] --> G2["Paxos 共识"]
|
||
G2 --> G3["多数派确认"]
|
||
G3 --> G4["并行回放"]
|
||
end
|
||
|
||
style A3 fill:#FF9F43,color:#000
|
||
style S5 fill:#00D866,color:#fff
|
||
style G3 fill:#00B6BC,color:#fff
|
||
```
|
||
|
||
### 异步复制（默认）
|
||
|
||
最简单的模式——Master 写完就不管了，异步发给 Slave。
|
||
|
||
**在从库上执行以下命令**，告诉它"去连接哪个主库、用什么账号、从哪里开始复制"：
|
||
|
||
```sql
|
||
-- MySQL 5.5 (已弃用)
|
||
-- CHANGE MASTER TO
|
||
-- MASTER_HOST='10.0.1.10', ...
|
||
|
||
-- ✅ MySQL 8.0+ 标准语法
|
||
CHANGE REPLICATION SOURCE TO
|
||
SOURCE_HOST='10.0.1.10', -- 主库 IP
|
||
SOURCE_USER='repl_user', -- 专用的复制账号
|
||
SOURCE_PASSWORD='password',
|
||
SOURCE_PORT=3306,
|
||
SOURCE_AUTO_POSITION = 1; -- GTID 模式：自动找到正确的起始位置
|
||
|
||
START REPLICA; -- 启动复制！
|
||
```
|
||
|
||
> [!tip] 关键参数 `SOURCE_AUTO_POSITION`
|
||
> 设为 `1` 表示开启 GTID 自动定位——从库会自动告诉主库"我已经有哪些事务了"，主库从缺失的部分开始发送。再也不用手动查 Binlog 文件和偏移量了。
|
||
|
||
> [!warning] 异步复制的风险
|
||
> Master 宕机后，尚未传输到 Slave 的数据会丢失。对于金融系统这是不可接受的。
|
||
|
||
### 半同步复制（Semi-Sync）
|
||
|
||
至少一个从库确认收到 Binlog 后，Master 才返回写成功。
|
||
|
||
半同步需要在**主库和从库两端都开启**插件：
|
||
|
||
```ini
|
||
# === Master 端配置 ===
|
||
plugin_load_add = semisync_master # 加载半同步主库插件
|
||
rpl_semi_sync_master_enabled = 1 # 开启
|
||
rpl_semi_sync_master_timeout = 10000 # 10 秒收不到 ACK 就降级为异步（保护性能）
|
||
rpl_semi_sync_master_wait_point = AFTER_SYNC # 先刷盘，再等从库确认（避免幻读）
|
||
```
|
||
|
||
```ini
|
||
# === Slave 端配置 ===
|
||
plugin_load_add = semisync_slave # 加载半同步从库插件
|
||
rpl_semi_sync_slave_enabled = 1 # 开启
|
||
```
|
||
|
||
> [!note] 半同步不是银弹
|
||
> - 从库收到 Binlog ≠ 已从磁盘持久化
|
||
> - 如果 Master 和从库同时断电，仍可能丢数据
|
||
> - 网络分区时 Master 会超时降级为异步
|
||
>
|
||
> **最佳实践**：Semi-Sync + 定期备份 + PITR 恢复组合使用
|
||
|
||
## GTID 复制
|
||
|
||
GTID（Global Transaction Identifier）给每个事务分配全局唯一的 ID，替代传统的 position-based 复制。
|
||
|
||
> [!question] 为什么传统 Position 复制让人抓狂？
|
||
> 传统模式下，从库靠 `mysql-bin.000003:154`（文件名 + 偏移量）来记录复制进度。
|
||
> 想象一下：主库挂了，你要把从库切到新主库上，但新旧主库的 Binlog 文件名和偏移量完全不同——你得**手动计算**该从哪个位置继续复制。
|
||
>
|
||
> GTID 的思路就简单多了：给每个事务贴一个「身份证号」。无论主库怎么切换，从库只要说"我已经执行到 23 号事务了"，新主库就知道该从 24 号开始发。
|
||
|
||
```
|
||
GTID 格式: source_id:transaction_id
|
||
例: 3E11FA47-71CA-11E1-9E33-C80AA9429562:23
|
||
↑ UUID of server ↑ Sequence number
|
||
```
|
||
|
||
### GTID 复制流程
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A["Client 事务写入 Master"] --> B["Server 层分配 GTID"]
|
||
B --> C["写入 Binlog 事件, 带 GTID 标记"]
|
||
C --> D["Binlog Dump 线程发送 GTID 和事件到 Slave"]
|
||
D --> E["Slave IO Thread 写入 Relay Log"]
|
||
E --> F{"GTID Set 已包含此 GTID?"}
|
||
F -->|"是"| G["跳过重复事件"]
|
||
F -->|"否"| H["SQL Worker 重放事务"]
|
||
H --> I["更新 Slave gtid_executed"]
|
||
G --> J["继续下一个事件"]
|
||
I --> J
|
||
|
||
style B fill:#C44569,color:#fff
|
||
style F fill:#FFD166,color:#000
|
||
style H fill:#00B6BC,color:#fff
|
||
```
|
||
|
||
> [!note] GTID 的一致性约束
|
||
> 启用 `enforce_gtid_consistency = ON` 后，以下操作被**禁止**：
|
||
> - 对非事务引擎（如 MyISAM）的 DML
|
||
> - 创建/删除临时表
|
||
> - `CREATE TABLE ... SELECT`（混合语句级和语句级二进制日志）
|
||
> - 对视图的 DML（无法追踪来源表）
|
||
|
||
### GTID vs 传统 Position
|
||
|
||
一句话总结：**Position 靠「页码」定位，GTID 靠「身份证号」定位。**
|
||
|
||
| 特性 | Position-based | GTID-based |
|
||
|------|---------------|------------|
|
||
| **定位方式** | 文件名 + position 号（像书签） | GTID set（像身份证号集合） |
|
||
| **跨库切换** | 需要手动查 position | 自动定位 |
|
||
| **跳过事务** | 困难 | `SET gtid_next = '...'; BEGIN; COMMIT; SET gtid_next = AUTOMATIC;` |
|
||
| **一致性检查** | 手动比对 | `pt-table-checksum` + GTID 验证 |
|
||
|
||
> [!tip] 实际建议
|
||
> MySQL 8.0 中 GTID 已经非常成熟，**新项目强烈建议默认开启**。传统 Position 模式仅在兼容老版本时使用。
|
||
|
||
在主库和从库的 `my.cnf` 中添加以下配置即可启用 GTID：
|
||
|
||
```ini
|
||
# 启用 GTID
|
||
gtid_mode = ON # 开启 GTID
|
||
enforce_gtid_consistency = ON # 强制一致性：禁止不安全的 SQL 写法
|
||
master_info_repository = TABLE # 复制元数据存到系统表，比文件更可靠
|
||
relay_log_info_repository = TABLE
|
||
```
|
||
|
||
> [!tip] 热知识
|
||
> MySQL 8.0 中 `master_info_repository` 和 `relay_log_info_repository` 默认就是 TABLE，无需手动配置。
|
||
|
||
## 并行复制（Multithreaded Slave, MTS）
|
||
|
||
前面提到 SQL Thread 负责重放 Relay Log。问题来了——默认只有一个 SQL Thread，所有事务都**排队串行**执行。如果主库很忙，从库就很容易「越落越远」。
|
||
|
||
> [!tip] 用快递仓库来理解并行复制
|
||
> 串行回放 = 一个分拣员按顺序处理所有包裹。
|
||
> 并行回放 = 多个分拣员**同时**处理，只要包裹之间没有依赖关系（比如不会同时操作同一行），就可以并行。
|
||
|
||
MySQL 5.6+ 引入从库并行回放，大幅提升复制延迟处理能力。
|
||
|
||
在从库配置中开启并行复制：
|
||
|
||
```ini
|
||
# MySQL 5.x（已弃用）
|
||
# slave_parallel_type = LOGICAL_CLOCK
|
||
# slave_parallel_workers = 8
|
||
|
||
# ✅ MySQL 8.0+ 标准命名
|
||
replica_parallel_type = LOGICAL_CLOCK # 按事务依赖关系决定哪些可以并行
|
||
replica_parallel_workers = 8 # 并发 worker 数量（建议 CPU 核数的一半）
|
||
```
|
||
|
||
> [!TIP] worker 数量设多少合适？
|
||
> 不是越多越好。每个 worker 都占内存和 CPU，一般建议 **CPU 核数的一半**，上限不超过 16。设太多反而会因为锁竞争导致更慢。
|
||
|
||
### MTS 并行模式对比
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph "DATABASE 默认"
|
||
D1["Relay Log 事件"] --> D2{"按 database 分桶"}
|
||
D2 -->|"db_a"| W1["Worker 1"]
|
||
D2 -->|"db_b"| W2["Worker 2"]
|
||
D2 -->|"db_c"| W3["Worker 3"]
|
||
W1 & W2 & W3 --> J1["写入数据"]
|
||
end
|
||
|
||
subgraph "GROUP_TRANSACTIONS"
|
||
G1["Relay Log 事件"] --> G2{"判断事务依赖关系"}
|
||
G2 -->|"无冲突"| A1["组1 并行执行"]
|
||
G2 -->|"有冲突"| A2["组2 串行等待"]
|
||
G1 -->|"无冲突"| A1
|
||
A1 --> J2["写入数据"]
|
||
A2 --> J2
|
||
end
|
||
|
||
style A1 fill:#00D866,color:#fff
|
||
style A2 fill:#FF9F43,color:#000
|
||
```
|
||
|
||
| 维度 | `DATABASE` | `GROUP_TRANSACTIONS` |
|
||
|------|-----------|---------------------|
|
||
| **分组依据** | database 名称 | 事务间的写集依赖关系 |
|
||
| **并发度** | 受限于 database 数量 | 取决于并发事务比例，通常更高 |
|
||
| **精确度** | 粗粒度——同一 DB 内串行 | 细粒度——无依赖即可并行 |
|
||
| **适用场景** | schema 设计良好的系统 | 多库共享、跨库事务较多的场景 |
|
||
| **引入版本** | MySQL 5.6 | MySQL 5.7+ |
|
||
|
||
> [!tip] 如何选择
|
||
> - 如果业务按 database 做数据隔离（每个 tenant 一个 DB），选 `DATABASE`
|
||
> - 如果多个业务共享少数几个 database，选 `GROUP_TRANSACTIONS`
|
||
|
||
### LOGICAL_CLOCK 原理
|
||
|
||
> [!info] `LOGICAL_CLOCK` = GTID 驱动的并行回放
|
||
> 无论选择 `DATABASE` 还是 `GROUP_TRANSACTIONS`，底层引擎都是 LOGICAL_CLOCK。
|
||
> 区别仅在于如何把连续事件流切分成可并行的逻辑组。
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A["Relay Log 事件流"] --> B{"按 database 分组"}
|
||
B --> C["DB1 事件队列"]
|
||
B --> D["DB2 事件队列"]
|
||
B --> E["DBn 事件队列"]
|
||
|
||
C --> W1["Worker 1 执行 DB1 事件"]
|
||
D --> W2["Worker 2 执行 DB2 事件"]
|
||
E --> Wn["Worker n 执行 DBn 事件"]
|
||
|
||
style W1 fill:#00D866,color:#fff
|
||
style W2 fill:#00B6BC,color:#fff
|
||
style Wn fill:#FF9F43,color:#000
|
||
```
|
||
|
||
> [!tip] Parallel Replication 的限制
|
||
> - 基于 database 的并行要求同一 database 内没有冲突事务
|
||
> - 跨 database 的操作无法并行
|
||
> - innodb_table_locks=OFF 且 autocommit=1 时才能并行（避免表锁冲突）
|
||
|
||
## 监控复制状态
|
||
|
||
复制搭好了，日常巡检同样重要。最常见的关注点：**IO 线程和 SQL 线程是否在正常运行？从库落后主库多少秒？**
|
||
|
||
```sql
|
||
-- MySQL 8.0+ 已弃用 SHOW SLAVE STATUS
|
||
-- SHOW SLAVE STATUS\G
|
||
|
||
-- ✅ 使用 performance_schema 视图
|
||
SELECT * FROM performance_schema.replication_connection_status;
|
||
SELECT * FROM performance_schema.replication_applier_status;
|
||
|
||
-- ⚠️ 以上两表各返回一行，多从库场景下需要关联：
|
||
-- connection: 一条代表 Master → Slave 的 IO 连接
|
||
-- applier: 每行代表一个 SQL Worker 线程
|
||
```
|
||
|
||
```sql
|
||
-- 实时延迟监控（MySQL 8.0+, GTID 模式）
|
||
SELECT
|
||
MAX(latency) / 1000000000 AS max_lag_seconds
|
||
FROM (
|
||
SELECT
|
||
MAX(clock_timestamp) - MIN(clock_start) AS latency
|
||
FROM performance_schema.replication_applier_status_by_worker
|
||
) lag;
|
||
```
|
||
|
||
## 常见问题与排查
|
||
|
||
生产环境中，主从复制最容易出问题的三个地方：**IO 线程断连**、**SQL 线程卡住**、**延迟越来越大**。下面逐一分析。
|
||
|
||
### IO 线程断开（Slave_IO_Running: No）
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A["IO Thread 断连"] --> B{"原因定位"}
|
||
B -->|"网络不通"| C["检查防火墙和安全组端口"]
|
||
B -->|"Binlog 已过期"| D["purge binary logs"]
|
||
B -->|"认证失败"| E["核对 user 权限和 password"]
|
||
B -->|"Server UUID 冲突"| F["重置 slave server_uuid"]
|
||
C --> G["CHANGE REPLICATION SOURCE TO"]
|
||
D --> G
|
||
E --> G
|
||
F --> G
|
||
G --> H["START REPLICA"]
|
||
H --> I["确认 IO 恢复"]
|
||
|
||
style A fill:#FF6B6B,color:#fff
|
||
style I fill:#00D866,color:#fff
|
||
```
|
||
|
||
**常见排查步骤：**
|
||
|
||
```sql
|
||
-- 1. 查看具体错误信息
|
||
SELECT LAST_ERROR_MESSAGE FROM performance_schema.replication_connection_status;
|
||
|
||
-- 2. 检查 Master Binlog 是否已被清理
|
||
SHOW MASTER LOGS;
|
||
|
||
-- 3. 如果 Binlog 已过期，需要全量恢复（mysqldump + --single-transaction）
|
||
-- 或使用 xtrabackup 做 In-place Slave 重建
|
||
```
|
||
|
||
### SQL 线程卡住（Slave_SQL_Running: No）
|
||
|
||
这通常是由于数据不一致导致的——例如从库被手动修改过。
|
||
|
||
> [!warning] 不要直接跳过！
|
||
> 盲目 `sql_slave_skip_counter` 可能导致数据静默丢失。必须先确认事务内容。
|
||
|
||
```sql
|
||
-- ⚠️ MySQL 5.7 及以下（已弃用）
|
||
-- SET GLOBAL sql_slave_skip_counter = 1;
|
||
-- STOP SLAVE; START SLAVE;
|
||
|
||
-- ✅ MySQL 8.0+ GTID 模式：跳过指定事务
|
||
-- 核心思路：假装已经执行过这个事务，让从库跳过它
|
||
SET GTID_NEXT='3E11FA47-71CA-11E1-9E33-C80AA9429562:100'; -- 指定要跳过的 GTID
|
||
BEGIN; COMMIT; -- 提交一个空事务, 标记该 GTID 为已执行
|
||
SET GTID_NEXT='AUTOMATIC'; -- 恢复自动分配 GTID
|
||
|
||
-- 如果需要从头重建从库的 GTID 记录（慎用！）
|
||
STOP REPLICA;
|
||
SET GLOBAL gtid_purged = '3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100'; -- 声明从库已拥有这些 GTID
|
||
START REPLICA;
|
||
```
|
||
|
||
### 延迟过大如何诊断
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A["Seconds_Behind_Master 大"] --> B{"IO 延迟还是 SQL 延迟"}
|
||
B -->|"Relay_Log_Space 持续增长"| C["SQL Worker 回放太慢, 增加 replica_parallel_workers"]
|
||
B -->|"Read_Master_Log_Pos 跟丢"| D["网络带宽不足或 Master 写入量太大"]
|
||
B -->|"DDL 执行中"| E["大表 ALTER TABLE 阻塞, 使用 pt-online-schema-change"]
|
||
|
||
style C fill:#00B6BC,color:#fff
|
||
style D fill:#FF9F43,color:#000
|
||
style E fill:#C44569,color:#fff
|
||
```
|
||
|
||
---
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/MySQL/07-高可用与分布式/29-Binary Log]] — Binlog 是主从复制的数据源
|
||
- [[hhs/MySQL/07-高可用与分布式/31-MHA与Orchestrator]] — 自动故障切换工具
|
||
- [[hhs/MySQL/07-高可用与分布式/32-Group Replication]] — Paxos 多主复制进阶方案
|