cs-note/hhs/MySQL/07-高可用与分布式/30-主从复制详解.md

tags, create time

tags	create time
MySQL 主从复制 Replication Semi-Sync GTID	2026-05-16 10:30

主从复制

概述

MySQL 主从复制是通过 Binlog 将主库的数据变更传播到从库的过程。它是高可用架构的基础组件，也是读写分离的前提。

[!tip] 生活中的类比 想象主库是一位「主播」，从库是「观众」。主播做了一个操作（比如画画），观众通过直播画面（Binlog）看到这个操作，然后在自己的画布上照着做一遍。

这个"看到 → 照做"的过程，就是主从复制的本质。

[!question] 为什么需要主从复制？ 一台 MySQL 能撑多久？当读请求暴增时，单机性能到顶了怎么办？ 主从复制给出了两个关键答案：读写分离（主库写、从库读）和高可用（主库挂了，从库顶上）。

复制架构

复制的过程可以简化为三个步骤：主库记录变更 → 网络传输 → 从库重放变更。

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 个	中（大幅降低丢数据概率）	中
组复制	等多数派共识	高	较低

下面的流程图展示了三种模式的完整过程：

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。

在从库上执行以下命令，告诉它"去连接哪个主库、用什么账号、从哪里开始复制"：

-- 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 才返回写成功。

半同步需要在主库和从库两端都开启插件：

# === 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        # 先刷盘，再等从库确认（避免幻读）

# === 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 复制流程

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：

# 启用 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+ 引入从库并行回放，大幅提升复制延迟处理能力。

在从库配置中开启并行复制：

# 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 并行模式对比

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。 区别仅在于如何把连续事件流切分成可并行的逻辑组。

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 线程是否在正常运行？从库落后主库多少秒？

-- 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 线程

-- 实时延迟监控（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）

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

常见排查步骤：

-- 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 可能导致数据静默丢失。必须先确认事务内容。

-- ⚠️ 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;

延迟过大如何诊断

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 多主复制进阶方案