vault backup: 2026-05-21 22:11:56

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

@@ -9,21 +9,32 @@ create time: 2026-05-16 10:30
 
 MySQL 主从复制是通过 Binlog 将主库的数据变更传播到从库的过程。它是高可用架构的基础组件，也是读写分离的前提。
 
+> [!tip] 生活中的类比
+> 想象主库是一位「主播」，从库是「观众」。主播做了一个操作（比如画画），观众通过直播画面（Binlog）看到这个操作，然后在自己的画布上**照着做一遍**。
+>
+> 这个"看到 → 照做"的过程，就是主从复制的本质。
+
+> [!question] 为什么需要主从复制？
+> 一台 MySQL 能撑多久？当读请求暴增时，单机性能到顶了怎么办？
+> 主从复制给出了两个关键答案：**读写分离**（主库写、从库读）和**高可用**（主库挂了，从库顶上）。
+
 ## 复制架构
 
+复制的过程可以简化为三个步骤：**主库记录变更** → **网络传输** → **从库重放变更**。
+
 ```mermaid
 flowchart LR
     subgraph "Master"
-        M1["业务写入 → DML"] --> M2["Server 层生成 Binlog"]
+        M1["业务写入 DML"] --> M2["Server 层生成 Binlog"]
         M2 --> M3["Binlog Dump Thread"]
     end
     
     subgraph "Network"
-        M3 -.Binlog Stream.-> I1["IO Thread"]
+        M3 -. "Binlog Stream" .-> I1["IO Thread"]
     end
-    
+
     subgraph "Slave"
-        I1 --> S1["Relay Log<br/>中继日志"]
+        I1 --> S1["Relay Log 中继日志"]
         S1 --> S2["SQL Thread"]
         S2 --> S3["数据文件更新"]
     end
@@ -40,24 +51,37 @@ flowchart LR
 | **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"
+    subgraph "Async 异步复制"
         A1["Client 写入 Master"] --> A2["Master 刷盘返回 OK"]
         A2 -->|"后续"| A3["异步发给 Slave"]
     end
-    
-    subgraph "半同步复制 Semi-Sync"
+
+    subgraph "Semi-Sync 半同步复制"
         S1["Client 写入 Master"] --> S2["Master 刷盘"]
-        S2 --> S3["等待 ≥1 个 Slave ACK"]
-        S3 -->|"超时 10s"| S4["降级为异步 ⚠️"]
+        S2 --> S3["等待至少1个 Slave ACK"]
+        S3 -->|"超时10s"| S4["降级为异步"]
         S3 -->|"收到 ACK"| S5["返回 OK"]
         S5 --> S6["异步发给其他 Slave"]
     end
-    
-    subgraph "组复制 Group Replication"
+
+    subgraph "Group Replication 组复制"
         G1["Client 写入"] --> G2["Paxos 共识"]
         G2 --> G3["多数派确认"]
         G3 --> G4["并行回放"]
@@ -72,6 +96,8 @@ flowchart TD
 
 最简单的模式——Master 写完就不管了，异步发给 Slave。
 
+**在从库上执行以下命令**，告诉它"去连接哪个主库、用什么账号、从哪里开始复制"：
+
 ```sql
 -- MySQL 5.5 (已弃用)
 -- CHANGE MASTER TO
@@ -79,37 +105,42 @@ flowchart TD
 
 -- ✅ MySQL 8.0+ 标准语法
 CHANGE REPLICATION SOURCE TO
-    SOURCE_HOST='10.0.1.10',
-    SOURCE_USER='repl_user',
+    SOURCE_HOST='10.0.1.10',          -- 主库 IP
+    SOURCE_USER='repl_user',           -- 专用的复制账号
     SOURCE_PASSWORD='password',
     SOURCE_PORT=3306,
-    SOURCE_AUTO_POSITION = 1;  -- GTID 模式自动定位
+    SOURCE_AUTO_POSITION = 1;          -- GTID 模式：自动找到正确的起始位置
 
-START REPLICA;
+START REPLICA;  -- 启动复制！
 ```
 
-> [!WARNING] 异步复制的风险
+> [!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 秒超时后降级为异步
-rpl_semi_sync_master_wait_point = AFTER_SYNC  # 刷盘后再等待
+# === 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
+# === Slave 端配置 ===
+plugin_load_add = semisync_slave                     # 加载半同步从库插件
+rpl_semi_sync_slave_enabled = 1                      # 开启
 ```
 
-> [!NOTE] 半同步不是银弹
+> [!note] 半同步不是银弹
 > - 从库收到 Binlog ≠ 已从磁盘持久化
 > - 如果 Master 和从库同时断电，仍可能丢数据
 > - 网络分区时 Master 会超时降级为异步
@@ -120,6 +151,12 @@ rpl_semi_sync_slave_enabled = 1
 
 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
@@ -130,13 +167,13 @@ GTID 格式: source_id:transaction_id
 
 ```mermaid
 flowchart TD
-    A["Client 事务写入 Master"] --> B["Server 层分配 GTID<br/>source_id:next_seq"]
-    B --> C["写入 Binlog 事件<br/>带 GTID 标记"]
-    C --> D["Binlog Dump 线程发送<br/>GTID + 事件到 Slave"]
-    D --> E["Slave IO Thread 写入<br/>Relay Log (含 GTID)"]
-    E --> F{"GTID Set<br/>是否已包含此 GTID?"}
-    F -->|是| G["跳过重复事件 ✅"]
-    F -->|否| H["SQL Worker 重放事务"]
+    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
@@ -146,7 +183,7 @@ flowchart TD
     style H fill:#00B6BC,color:#fff
 ```
 
-> [!NOTE] GTID 的一致性约束
+> [!note] GTID 的一致性约束
 > 启用 `enforce_gtid_consistency = ON` 后，以下操作被**禁止**：
 > - 对非事务引擎（如 MyISAM）的 DML
 > - 创建/删除临时表
@@ -155,41 +192,62 @@ flowchart TD
 
 ### GTID vs 传统 Position
 
+一句话总结：**Position 靠「页码」定位，GTID 靠「身份证号」定位。**
+
 | 特性 | Position-based | GTID-based |
 |------|---------------|------------|
-| **定位方式** | 文件名 + position 号 | GTID set |
+| **定位方式** | 文件名 + 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
-enforce_gtid_consistency = ON
-master_info_repository = TABLE     # 复制信息存在表中而非文件
+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    # 基于 GTID 的并发回放
-replica_parallel_workers = 8             # 并发 worker 数量
+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\n分桶"}
+    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"]
@@ -197,9 +255,9 @@ flowchart LR
     end
 
     subgraph "GROUP_TRANSACTIONS"
-        G1["Relay Log 事件"] --> G2{"判断事务\n依赖关系"}
-        G2 -->|"无冲突"| A1["组 1 → 并行执行"]
-        G2 -->|"有冲突"| A2["组 2 → 串行等待"]
+        G1["Relay Log 事件"] --> G2{"判断事务依赖关系"}
+        G2 -->|"无冲突"| A1["组1 并行执行"]
+        G2 -->|"有冲突"| A2["组2 串行等待"]
         G1 -->|"无冲突"| A1
         A1 --> J2["写入数据"]
         A2 --> J2
@@ -217,23 +275,23 @@ flowchart LR
 | **适用场景** | schema 设计良好的系统 | 多库共享、跨库事务较多的场景 |
 | **引入版本** | MySQL 5.6 | MySQL 5.7+ |
 
-> [!TIP] 如何选择
+> [!tip] 如何选择
 > - 如果业务按 database 做数据隔离（每个 tenant 一个 DB），选 `DATABASE`
 > - 如果多个业务共享少数几个 database，选 `GROUP_TRANSACTIONS`
 
 ### LOGICAL_CLOCK 原理
 
-> [!INFO] `LOGICAL_CLOCK` = GTID 驱动的并行回放
+> [!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 的事件队列"]
-    
+    B --> C["DB1 事件队列"]
+    B --> D["DB2 事件队列"]
+    B --> E["DBn 事件队列"]
+
     C --> W1["Worker 1 执行 DB1 事件"]
     D --> W2["Worker 2 执行 DB2 事件"]
     E --> Wn["Worker n 执行 DBn 事件"]
@@ -243,13 +301,15 @@ flowchart TD
     style Wn fill:#FF9F43,color:#000
 ```
 
-> [!TIP] Parallel Replication 的限制
+> [!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
@@ -276,16 +336,18 @@ FROM (
 
 ## 常见问题与排查
 
+生产环境中，主从复制最容易出问题的三个地方：**IO 线程断连**、**SQL 线程卡住**、**延迟越来越大**。下面逐一分析。
+
 ### IO 线程断开（Slave_IO_Running: No）
 
 ```mermaid
 flowchart TD
     A["IO Thread 断连"] --> B{"原因定位"}
-    B -->|网络不通| C["检查防火墙 / 安全组端口"]
-    B -->|Binlog 已过期| D["purge binary logs / 调整 expire_logs_days"]
-    B -->|认证失败| E["核对 user 权限 & password"]
-    B -->|Server UUID 冲突| F["重置 slave server_uuid"]
-    C --> G["CHANGE REPLICATION SOURCE TO<br/>SOURCE_LOG_FILE = '...',<br/>SOURCE_LOG_POS = ..."]
+    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
@@ -313,7 +375,7 @@ SHOW MASTER LOGS;
 
 这通常是由于数据不一致导致的——例如从库被手动修改过。
 
-> [!WARNING] 不要直接跳过！
+> [!warning] 不要直接跳过！
 > 盲目 `sql_slave_skip_counter` 可能导致数据静默丢失。必须先确认事务内容。
 
 ```sql
@@ -322,13 +384,14 @@ SHOW MASTER LOGS;
 -- STOP SLAVE; START SLAVE;
 
 -- ✅ MySQL 8.0+ GTID 模式：跳过指定事务
-SET GTID_NEXT='3E11FA47-71CA-11E1-9E33-C80AA9429562:100';
-BEGIN; COMMIT;
-SET GTID_NEXT='AUTOMATIC';
+-- 核心思路：假装已经执行过这个事务，让从库跳过它
+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';
+SET GLOBAL gtid_purged = '3E11FA47-71CA-11E1-9E33-C80AA9429562:1-100';  -- 声明从库已拥有这些 GTID
 START REPLICA;
 ```
 
@@ -336,10 +399,10 @@ START REPLICA;
 
 ```mermaid
 flowchart LR
-    A["Seconds_Behind_Master 大"] --> B{"IO 延迟还是 SQL 延迟?"}
-    B -->|"Relay_Log_Space 持续增长"| C["SQL Worker 回放太慢<br/>→ 增加 replica_parallel_workers<br/>→ 考虑 GROUP_TRANSACTIONS"]
-    B -->|"Read_Master_Log_Pos 跟丢"| D["网络带宽不足 / Master<br/>写入量太大<br/>→ 检查网络 / 限制 binlog 传输大小"]
-    B -->|"DDL 执行中"| E["大表 ALTER TABLE 阻塞<br/>→ 使用 pt-online-schema-change"]
+    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