第 15 章 主从复制面试精讲

📖 本篇简介：主从复制是 MySQL 高可用、读写分离、备份的基石，也是面试中最常被深入追问的架构知识点。本篇基于 MySQL 8.0，系统讲解 binlog 三种格式（STATEMENT/ROW/MIXED）、dump 线程/SQL 线程/IO 线程、异步复制/半同步复制/组复制、主从延迟原因与监控、GTID 复制、并行复制、如何搭建主从、如何处理主从延迟与数据不一致。学完后你能讲清楚"从库为什么会延迟""半同步解决什么问题""GTID 比传统位点复制好在哪"，并能独立搭建一套主从复制环境。

目录

• 题目 1：MySQL 主从复制的基本原理是什么
• 题目 2：binlog 三种格式 STATEMENT/ROW/MIXED 区别
• 题目 3：主从复制涉及哪几个线程，各自做什么
• 题目 4：异步复制、半同步复制、组复制区别
• 题目 5：GTID 复制是什么，比传统位点复制好在哪
• 题目 6：主从延迟产生的原因有哪些
• 题目 7：怎么监控主从延迟，常用命令是什么
• 题目 8：从库并行复制是什么，8.0 有什么增强
• 题目 9：如何搭建一套主从复制环境
• 题目 10：主从数据不一致怎么发现与修复
• 题目 11：binlog 与 redo log 的区别
• 题目 12：双主复制有什么风险，怎么避免
• 题目 13：半同步复制的等待超时怎么配置
• 题目 14：从库误写数据会怎样，怎么防止
• 题目 15：大事务为什么会造成主从延迟
• 题目 16：复制过滤有哪些方式，优缺点
• 题目 17：GTID 复制下主从切换怎么做
• 题目 18：binlog_group_commit 是什么，与并行复制关系
• 题目 19：从库只读怎么配置，super_read_only 是什么
• 题目 20：常见坑与注意事项
• 速查表：主从复制速记
• 复习清单
• 练习题

题目 1：MySQL 主从复制的基本原理是什么

考点

• 三步：主库写 binlog、从库拉 binlog、从库回放 relay log
• 异步默认
• 最终一致性

参考答案

1. 第一步（主库）：主库把所有数据修改事务写入 binlog（二进制日志）。

2. 第二步（从库 IO 线程）：从库启动 IO 线程连接主库，主库创建 dump 线程把 binlog 发给从库；从库 IO 线程把收到的事件写入本地 relay log（中继日志）。

3. 第三步（从库 SQL 线程）：从库 SQL 线程读取 relay log，重放（replay）SQL 事件，把数据修改应用到从库。

4. 默认异步：主库写完 binlog 就返回客户端，不等从库确认；从库异步追。

5. 结果：从库数据最终与主库一致，但有延迟窗口。

-- 从库查看复制状态
SHOW REPLICA STATUS\G   -- 8.0 用 REPLICA，5.7 用 SLAVE

追问

• 追问：主库宕机时从库数据一定全吗？应对：不一定，异步复制下已提交但未发送到从库的事务会丢，要半同步或组复制。
• 追问：从库能同时当主库吗？应对：能，形成级联复制或双主。

题目 2：binlog 三种格式 STATEMENT/ROW/MIXED 区别

考点

• STATEMENT 记 SQL 原文
• ROW 记行变更
• MIXED 自动选
• 8.0 默认 ROW

参考答案

| 格式 | 记录内容 | 优点 | 缺点 |

|------|----------|------|------|

| STATEMENT | SQL 原文 | 日志小 | 函数（NOW()、UUID()）在从库重放结果不一致 |

| ROW | 每行前后镜像 | 数据绝对一致 | 日志大，UPDATE 全表会产生海量行事件 |

| MIXED | 自动选择 | 折中 | 8.0 已不推荐 |

1. STATEMENT：UPDATE emp SET salary=salary+1 WHERE dept=5 记这条 SQL。风险：NOW()、UUID()、LOAD_FILE() 等非确定性函数在从库执行结果不同。

2. ROW：记每一行改前/改后的镜像，从库直接应用，绝对一致；日志体积大。

3. MIXED：普通语句用 STATEMENT，非确定性场景自动切 ROW。

4. 8.0 默认 ROW：binlog_format=ROW，生产强烈推荐。

-- 查看 binlog 格式
SHOW VARIABLES LIKE 'binlog_format';
-- 设置
SET GLOBAL binlog_format = 'ROW';

追问

• 追问：ROW 模式日志太大怎么办？应对：设 binlog_row_image=MINIMAL，只记变更列；但崩溃恢复时不够用。
• 追问：STATEMENT 有哪些函数不安全？应对：NOW()、UUID()、RAND()、USER() 等，从库重放结果不同。

题目 3：主从复制涉及哪几个线程，各自做什么

考点

• 主库 dump 线程
• 从库 IO 线程
• 从库 SQL 线程
• 8.0 worker 线程

参考答案

1. 主库 dump 线程：每个从库连接对应一个 dump 线程，负责把 binlog 发送给从库。

2. 从库 IO 线程：连接主库，接收 binlog 事件，写入本地 relay log。

3. 从库 SQL 线程：读取 relay log，重放事件到从库数据。

4. 8.0 并行复制：SQL 线程变成协调者，多个 worker 线程并行重放 relay log。

-- 主库查看当前连接的从库
SHOW REPLICAS;   -- 8.0，5.7 用 SHOW SLAVE HOSTS
-- 从库查看复制线程状态
SHOW REPLICA STATUS\G

追问

• 追问：dump 线程阻塞主库吗？应对：一般不；大事务发送时可能短暂占用，但不影响主库其他业务。
• 追问：IO 线程与 SQL 线程哪个更容易延迟？应对：SQL 线程重放慢导致延迟，IO 线程一般很快。

题目 4：异步复制、半同步复制、组复制区别

考点

• 异步：主库不等从库
• 半同步：至少一个从库收到 binlog 才返回
• 组复制：Paxos 多数派确认

参考答案

| 模式 | 主库返回时机 | 数据安全 | 性能 |

|------|--------------|----------|------|

| 异步复制 | 写 binlog 即返回 | 主库宕机可能丢事务 | 最好 |

| 半同步复制 | 至少一个从库收到 binlog 并 ACK | 不丢已返回客户端的事务 | 略差 |

| 组复制 MGR | 多数派节点持久化 | 强一致 | 较差 |

1. 异步复制：默认，主库写完 binlog 就返回，从库异步追。

2. 半同步复制：主库提交后等至少一个从库把 binlog 写到 relay log 并 ACK，才返回客户端；超时降级为异步。

3. 组复制 MGR：基于 Paxos，事务要多数派节点确认才能提交，强一致但性能开销大。

-- 主库安装半同步插件
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled = 1;
-- 从库
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_replica_enabled = 1;

追问

• 追问：半同步一定不丢数据吗？应对：从库收到 binlog 写 relay log 但还没重放时从库宕机，已 ACK 的事务仍在 relay log，新主库可追；但极端情况仍要配合 MGR。
• 追问：半同步超时怎么配？应对：rpl_semi_sync_source_timeout=10000（毫秒），超时降级异步。

题目 5：GTID 复制是什么，比传统位点复制好在哪

考点

• GTID 全局事务 ID
• 自动定位位点
• 主从切换简单
• 格式 UUID:NUMBER

参考答案

1. GTID（Global Transaction ID）：每个事务在主库提交时生成一个全局唯一 ID，格式 source_uuid:transaction_id。

2. 传统位点复制：要手动指定 master_log_file 和 master_log_pos，主从切换时容易找错位点。

3. GTID 优势：

• 从库自动找到缺失的事务，不用手动算位点；
• 主从切换简单，CHANGE REPLICATION SOURCE TO ... SOURCE_AUTO_POSITION=1；
• 一眼看出哪些事务在哪些节点执行过。

4. 开启：主从都要 gtid_mode=ON、enforce_gtid_consistency=ON。

-- 从库配置 GTID 复制
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.0.1',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='xxx',
  SOURCE_AUTO_POSITION=1;   -- 关键：自动定位
START REPLICA;

追问

• 追问：GTID 复制下还能跳过事务吗？应对：能，用 gtid_executed + 空事务注入，但要小心。
• 追问：GTID 有什么限制？应对：不支持 CREATE TABLE ... SELECT、临时表在事务中等，要 enforce_gtid_consistency 检查。

题目 6：主从延迟产生的原因有哪些

考点

• 从库单线程重放
• 大事务
• 从库性能差
• 网络问题
• 从库承担读流量

参考答案

1. 从库重放慢：传统 SQL 线程单线程重放，主库高并发写入时从库追不上。

2. 大事务：主库一个事务更新百万行，从库必须整个重放完才能执行下一个。

3. 从库性能差：从库 CPU/磁盘/内存不如主库，重放能力弱。

4. 从库承担读流量：从库既要追 binlog 又要跑业务查询，资源争抢。

5. 网络问题：主从跨机房，binlog 传输慢。

6. 锁冲突：从库重放 SQL 与从库查询锁冲突，重放被阻塞。

追问

• 追问：怎么减少延迟？应对：开启并行复制（slave_parallel_workers）、拆分大事务、从库硬件升级、读写分离合理。
• 追问：延迟多少算正常？应对：毫秒~秒级；超过 1 秒要告警，超过 10 秒要紧急处理。

题目 7：怎么监控主从延迟，常用命令是什么

考点

• SHOW REPLICA STATUS
• Seconds_Behind_Source
• GTID 差值
• Heartbeat

参考答案

-- 从库查看复制状态
SHOW REPLICA STATUS\G
-- 关键字段：
-- Replica_IO_Running: Yes/No
-- Replica_SQL_Running: Yes/No
-- Seconds_Behind_Source: 0   -- 延迟秒数
-- Executed_Gtid_Set: ...     -- 已执行的 GTID
-- Retrieved_Gtid_Set: ...    -- 已接收的 GTID

1. Seconds_Behind_Source：从库 SQL 线程当前正在重放的事务的时间戳与主库当前时间差，粗略延迟。

2. GTID 差值：对比主库 Executed_Gtid_Set 与从库 Executed_Gtid_Set，差多少个事务。

3. 心跳检测：pt-heartbeat 工具，主库每秒更新时间戳，从库查差值，更准确。

4. 监控告警：Seconds_Behind_Source > 10s 告警，IO/SQL 线程中断立刻告警。

追问

• 追问：Seconds_Behind_Source=0 就一定没延迟吗？应对：不一定，IO 线程断了也会显示 NULL；要结合 IO/SQL 线程状态。
• 追问：pt-heartbeat 为什么更准？应对：它测的是真实时间差，不是事务时间戳，不受大事务影响。

题目 8：从库并行复制是什么，8.0 有什么增强

考点

• 多 worker 线程重放
• 基于组提交
• 8.0 WRITESET 并行

参考答案

1. 5.6 并行复制：按库（database）并行，不同库的事务并行重放，同库串行。

2. 5.7 基于组提交：MTS 基于 binlog_group_commit，同一组提交的事务在从库并行重放。

3. 8.0 WRITESET 并行：binlog_transaction_dependency_history_size 基于事务修改的行集合（writeset），不冲突的事务并行，并行度更高。

4. 配置：

-- 开启并行复制
SET GLOBAL slave_parallel_workers = 4;           -- worker 数
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; -- 基于组提交
-- 8.0 writeset 模式
SET GLOBAL binlog_transaction_dependency_tracking = 'WRITESET';

追问

• 追问：worker 数开多少合适？应对：CPU 核数的一半到一倍，开太多反而上下文切换开销大。
• 追问：并行复制保序吗？应对：同一事务内的语句保序；不同事务只要不冲突可乱序，最终一致。

题目 9：如何搭建一套主从复制环境

考点

• 主库建复制账号
• 从库配连接信息
• 锁表备份
• CHANGE REPLICATION SOURCE

参考答案

-- 第一步：主库建复制账号
CREATE USER 'repl'@'从库IP' IDENTIFIED BY '强密码';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'从库IP';

-- 第二步：主库 my.cnf 配置
-- server-id=1
-- log_bin=mysql-bin
-- binlog_format=ROW
-- gtid_mode=ON
-- enforce_gtid_consistency=ON

-- 第三步：主库锁表导出数据（或用 mysqldump --master-data）
FLUSH TABLES WITH READ LOCK;
-- mysqldump -uroot -p --all-databases --master-data=2 > dump.sql
UNLOCK TABLES;

-- 第四步：从库导入 dump.sql

-- 第五步：从库配置
-- server-id=2（与主库不同）
-- relay_log=relay-bin
-- gtid_mode=ON
-- enforce_gtid_consistency=ON

-- 第六步：从库连接主库
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='主库IP',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='强密码',
  SOURCE_AUTO_POSITION=1;
START REPLICA;

-- 第七步：验证
SHOW REPLICA STATUS\G

追问

• 追问：不锁表怎么做备份？应对：用 mysqldump --single-transaction（InnoDB 一致性快照）。
• 追问：搭建完从库要开只读吗？应对：开 read_only=ON 或 super_read_only=ON。

题目 10：主从数据不一致怎么发现与修复

考点

• pt-table-checksum 校验
• pt-table-sync 修复
• 原因分析

参考答案

1. 发现：

• pt-table-checksum：主库跑校验，对比主从数据 CRC；
• 业务层比对关键字段；
• 从库报错 1062 Duplicate entry 或 1032 Row not found。

2. 常见原因：

• 从库误写数据；
• 大事务中断；
• 非确定性 SQL（STATEMENT 模式下 NOW()、UUID()）；
• 手动跳过事务。

3. 修复：

• pt-table-sync：根据校验结果自动同步；
• 重新搭从库（最干净）。

# 校验
pt-table-checksum h=主库,u=repl,p=xxx --databases=db1
# 修复（先 --print 看会改什么，再 --execute 执行）
pt-table-sync --execute h=从库,u=root,p=xxx --databases=db1

追问

• 追问：从库 1062 错误怎么处理？应对：说明从库已有重复行，通常是从库误写；找出冲突行删除后 START REPLICA。
• 追问：不一致表太大怎么修？应对：业务低峰重建从库，比 pt-table-sync 更稳。

题目 11：binlog 与 redo log 的区别

考点

• 层不同：Server 层 vs InnoDB 层
• 用途不同：复制/恢复 vs 崩溃恢复
• 写入时机不同
• 循环写 vs 追加写

参考答案

| 维度 | redo log | binlog |

|------|----------|--------|

| 所属层 | InnoDB 引擎层 | Server 层 |

| 用途 | 崩溃恢复（crash safe） | 主从复制、时间点恢复 PITR |

| 记录内容 | 物理日志（页修改） | 逻辑日志（SQL/行镜像） |

| 写入方式 | 循环写，固定大小 | 追加写，滚动生成 |

| 写入时机 | 事务执行中不断写 | 事务提交时写 |

1. redo log：InnoDB 保证 crash safe，事务修改先写 redo log（WAL），宕机后重放恢复。

2. binlog：Server 层记录所有数据修改，用于主从复制与 PITR。

3. 两阶段提交：redo log prepare → binlog 写 → redo log commit，保证两者一致。

追问

• 追问：没有 binlog 主从能复制吗？应对：不能，binlog 是复制的数据来源。
• 追问：redo log 大小怎么定？应对：一般 1~4GB，太小会频繁切换刷脏页。

题目 12：双主复制有什么风险，怎么避免

考点

• 双向写冲突
• 自增主键冲突
• 解决：只写一端/奇数位点

参考答案

1. 双主：两台互为主从，都可写。

2. 风险：

• 同一行两边同时更新，冲突；
• 自增主键两边生成相同 id，主键冲突。

3. 缓解：

• 只写一端，另一端做热备（主主架构但实际主写从读）；
• 自增步长错开：auto_increment_increment=2、auto_increment_offset=1/2；
• 业务层避免双向写同一行。

追问

• 追问：双主架构故障切换快吗？应对：快，VIP 漂移即可，但数据一致性要靠半同步/组复制保证。
• 追问：双主与 MGR 区别？应对：双主是传统异步复制，MGR 是 Paxos 强一致。

题目 13：半同步复制的等待超时怎么配置

考点

• rpl_semi_sync_source_timeout
• 超时降级为异步
• 生产建议值

参考答案

-- 主库等待从库 ACK 的超时时间（毫秒）
SET GLOBAL rpl_semi_sync_source_timeout = 10000;  -- 10 秒
-- 至少等待几个从库 ACK
SET GLOBAL rpl_semi_sync_source_wait_for_replicas = 1;

1. 超时降级：超过 timeout 没等到 ACK，主库自动降级为异步复制，避免业务被拖死。

2. wait_for_replicas：要几个从库 ACK 才算成功，生产一般 1 个。

3. 超时后恢复：从库追上后自动恢复半同步。

追问

• 追问：超时设多少合适？应对：跨机房 5~10 秒，同机房 1~2 秒；太长业务被拖死，太短失去半同步意义。
• 追问：半同步对性能影响多大？应对：同机房 5%~10% 延迟增加，跨机房看网络 RTT。

题目 14：从库误写数据会怎样，怎么防止

考点

• read_only 不防 super
• super_read_only
• 复制账号权限最小化

参考答案

1. 误写后果：从库数据与主库分叉，后续重放 binlog 时报 1032/1062 错误，复制中断。

2. 防止：

• read_only=ON：普通用户不能写，super 用户仍可写；
• super_read_only=ON：super 用户也不能写（推荐）；
• 复制账号只授 REPLICATION SLAVE，不给写权限。

-- 从库配置
SET GLOBAL super_read_only = ON;

追问

• 追问：super_read_only 连 mysqldump --master-data 都不让写？应对：从库备份本来就不该写，不影响读备份。
• 追问：从库要建索引怎么办？应对：超级管理员临时关掉 super_read_only，建完再开，或走 pt-osc。

题目 15：大事务为什么会造成主从延迟

考点

• 从库单线程重放整个事务
• undo/redo 压力
• 主库 binlog 发送慢

参考答案

1. 从库重放：一个事务百万行，从库 SQL 线程必须整事务重放完才能下一个事务，期间其他事务排队。

2. binlog 体积大：ROW 模式下大事务 binlog 几百 MB，网络传输慢。

3. 锁等待：大事务重放时持有行锁，从库查询被阻塞。

4. 解决：拆分大事务为小批次，每批 COMMIT。

追问

• 追问：并行复制能缓解大事务吗？应对：不能，单个事务内部不能并行，只能拆事务。
• 追问：大事务对主库有什么影响？应对：undo 膨胀、锁持有久、复制延迟。

题目 16：复制过滤有哪些方式，优缺点

考点

• 主库 binlog 过滤
• 从库 replication 过滤
• 过滤风险

参考答案

| 方式 | 配置位置 | 优点 | 缺点 |

|------|----------|------|------|

| binlog_do_db / binlog_ignore_db | 主库 | 不记录无关 binlog，省空间 | 过滤不灵活，影响所有从库 |

| replicate_do_db / replicate_wild_do_table | 从库 | 从库按需同步 | 不同从库数据不同，切换复杂 |

| replicate_wild_ignore_table | 从库 | 灵活排除表 | 容易漏配导致数据缺失 |

-- 从库只同步 db1 库
CHANGE REPLICATION FILTER REPLICATE_DO_DB=(db1);
-- 从库不同步日志表
CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE=('db1.log_%');

追问

• 追问：过滤复制下主从切换要注意什么？应对：新主库的数据可能不全，业务读写要重新路由。
• 追问：推荐主库过滤还是从库过滤？应对：一般从库过滤，主库 binlog 全量保留方便恢复。

题目 17：GTID 复制下主从切换怎么做

考点

• 确认从库已追完
• 执行 STOP REPLICA
• 应用切新主
• 旧主重新搭从库

参考答案

1. 确认从库追上：对比主从 Executed_Gtid_Set 一致。

2. 提升从库为新主：STOP REPLICA → RESET MASTER（8.0 RESET BINARY LOGS AND GTIDS）→ 开写。

3. 其他从库指向新主：CHANGE REPLICATION SOURCE TO SOURCE_HOST=新主IP, SOURCE_AUTO_POSITION=1; START REPLICA;。

4. 旧主修复后重新当从库：用 GTID 自动定位缺失事务。

追问

• 追问：人工切换风险？应对：网络分区时脑裂，要配合 VIP/Proxy 自动判断。
• 追问：MHA 与 GTID 关系？应对：MHA 管理工具基于 GTID 自动选最新从库提升。

题目 18：binlog_group_commit 是什么，与并行复制关系

考点

• 组提交减少 fsync
• 从库按组并行重放
• binlog 顺序写

参考答案

1. binlog_group_commit：主库把多个事务的 binlog 合并一次 fsync 刷盘，减少磁盘 I/O，提升并发提交吞吐。

2. 与并行复制关系：同一组提交的事务在从库可以并行重放（基于组提交的 MTS）。

3. 参数：binlog_group_commit_sync_delay（组提交延迟微秒数，攒更多事务）、binlog_group_commit_sync_no_delay_count。

追问

• 追问：组提交延迟设越大越好吗？应对：攒更多事务提升吞吐，但增加单事务延迟，要权衡。
• 追问：半同步与组提交关系？应对：半同步 ACK 也按组批量处理，减少网络开销。

题目 19：从库只读怎么配置，super_read_only 是什么

考点

• read_only vs super_read_only
• 复制线程不受影响
• 生产推荐

参考答案

-- 从库 my.cnf
read_only = ON;           -- 普通用户只读，super 用户仍可写
super_read_only = ON;     -- super 用户也只读（推荐）

1. read_only=ON：阻止非 SUPER 用户写，复制线程（具有 SYSTEM_REPLICATION_SLAVE 权限）仍能重放。

2. super_read_only=ON：连 SUPER 用户都不能写，最严格。

3. 推荐：从库一律 super_read_only=ON，防止误写。

追问

• 追问：super_read_only 时怎么建索引？应对：临时 SET GLOBAL super_read_only=OFF，建完再开；或用 pt-osc。
• 追问：read_only 对临时表生效吗？应对：不生效，临时表会话级。

题目 20：常见坑与注意事项

考点

• 复制高频坑汇总
• 数据一致性
• 运维操作

参考答案

1. 坑 1：从库没开 super_read_only，业务误写导致数据分叉。

2. 坑 2：大事务一次性更新百万行，主从延迟几十分钟。

3. 坑 3：STATEMENT 模式下用 NOW()/UUID()，主从不一致。

4. 坑 4：Seconds_Behind_Source=0 就认为没延迟，实际 IO 线程已断。

5. 坑 5：半同步超时太短，频繁降级成异步。

6. 坑 6：双主双向写，自增主键冲突。

7. 坑 7：从库承担太多读流量，重放被查询阻塞。

8. 坑 8：GTID 没开，主从切换手动算位点出错。

9. 坑 9：binlog 保留时间太短，误操作后无法 PITR。

10. 坑 10：从库版本比主库低，复制不兼容。

追问

• 追问：从库版本可以比主库高吗？应对：可以，从库高版本一般兼容低版本主库；反过来不行。
• 追问：binlog 保留多久合适？应对：至少 3~7 天，大促期间更长，满足 PITR 需求。

速查表：主从复制速记

| 概念 | 关键点 |

|------|--------|

| binlog_format | 生产 ROW，绝对一致 |

| 复制线程 | 主库 dump、从库 IO + SQL（worker） |

| 异步/半同步/MGR | 性能递减，数据安全递增 |

| GTID | 自动定位位点，切换简单 |

| 延迟监控 | Seconds_Behind_Source + pt-heartbeat |

| 并行复制 | slave_parallel_workers，8.0 writeset |

| 从库只读 | super_read_only=ON |

| 数据校验 | pt-table-checksum / pt-table-sync |

| 大事务 | 拆小批次，避免主从延迟 |

| 双主 | 自增步长错开，避免双向写 |

复习清单

| 题目 | 核心结论 | 易错点 |

|------|----------|--------|

| 1 | 主库写 binlog，从库 IO 拉、SQL 重放 | 以为从库实时同步 |

| 2 | ROW 模式数据绝对一致 | STATEMENT 非确定性函数 |

| 3 | dump/IO/SQL 三线程 | 8.0 worker 并行重放 |

| 4 | 半同步至少一从库 ACK | 半同步超时降级 |

| 5 | GTID 自动定位位点 | 不开 GTID 手动算位点 |

| 6 | 大事务/单线程重放致延迟 | 从库承担读流量 |

| 7 | Seconds_Behind_Source 粗略延迟 | IO 断时显示 NULL |

| 8 | 8.0 writeset 并行度高 | worker 开太多上下文切换 |

| 9 | 建账号→备份→CHANGE→START | --single-transaction 不锁表 |

| 10 | pt-table-checksum 校验 | 从库误写致 1062 |

| 11 | redo crash safe，binlog 复制/PITR | 两阶段提交 |

| 12 | 双主自增步长错开 | 双向写同一行冲突 |

| 13 | 半同步超时降级异步 | 超时太短频繁降级 |

| 14 | super_read_only 防误写 | read_only 不防 super |

| 15 | 大事务从库串行重放 | 拆小批次 |

| 16 | 从库过滤灵活但切换复杂 | 过滤复制数据不全 |

| 17 | GTID 下切换自动定位 | 人工切换脑裂 |

| 18 | 组提交减少 fsync | 延迟攒太多事务 |

| 19 | super_read_only=ON | 建索引临时关闭 |

| 20 | 大事务/误写/STATEMENT 三大坑 | binlog 保留太短 |

练习题

1. 题目：主库执行 INSERT INTO t VALUES (NOW())，STATEMENT 模式下从库数据会和主库一致吗？

• 参考答案：不一致，NOW() 是非确定性函数，从库重放时取的是从库当前时间；应改用 ROW 模式。

2. 题目：从库 Seconds_Behind_Source 突然飙到几千秒，可能原因？

• 参考答案：主库跑了大事务、从库性能瓶颈、从库查询锁阻塞重放、网络问题；先看从库 CPU/IO 与当前重放的事务。

3. 题目：怎么配置从库完全只读（包括 super 用户）？

• 参考答案：SET GLOBAL super_read_only=ON;，并写入 my.cnf 持久化。

4. 题目：GTID 相比传统位点复制最大的优势是什么？

• 参考答案：主从切换时不需要手动找 binlog 文件和位点，SOURCE_AUTO_POSITION=1 自动同步缺失事务。

5. 题目：半同步复制下主库已经返回成功的事务，还会丢吗？

• 参考答案：从库已把 binlog 写入 relay log 并 ACK，即使从库宕机，relay log 仍在磁盘，恢复后可重放；比异步安全，但极端故障仍建议 MGR。

下一篇预告：第 16 章 高可用与故障切换面试精讲