MySQL 主从复制是面试高频考点，重点不在命令背诵，而在理解原理、排查思路和实际场景应对能力。 面试官通常通过一个问题层层深入，考察你是否真懂“数据怎么同步”“断了怎么办”“为什么延迟”“主挂了怎么切”这些关键点。
主从复制的基本流程与核心线程
主从复制本质是“日志重放”：主库把变更写入 binlog → 从库拉取并存为 relay log → 从库 SQL 线程回放 relay log。
- 主库有 1 个线程：binlog dump thread，负责把本地 binlog 发送给从库（按位点发送，不主动推送）
-
从库有 2 个关键线程：
- IO thread：连接主库，拉取 binlog 并写入本地 relay log 文件（记录当前已拉到的主库位点）
- SQL thread：读取 relay log，解析并执行其中的事件（记录当前已执行到的 relay log 位点）
- 注意：IO 线程和 SQL 线程是独立运行的，所以 IO 已拉完 ≠ SQL 已执行完 → 这就是 复制延迟（Seconds_Behind_Master）的根本来源
如何判断主从是否正常？关键指标怎么看
别只看 SHOW SLAVE STATUS\G 里 Slave_IO_Running 和 Slave_SQL_Running 是 Yes 就放心。要结合多个字段交叉验证：
- Seconds_Behind_Master = NULL：可能 SQL 线程没启动、正在初始化、或主从 GTID 不一致导致无法计算，不是“快”，而是“算不出来”
- Seconds_Behind_Master = 0：仅说明 SQL 线程追上了 relay log 尾部，不代表实时——如果 IO 线程卡住，relay log 停更，0 就是假象
- 看
Read_Master_Log_Pos和Exec_Master_Log_Pos是否持续增长且差值稳定；差值突然变大 → SQL 执行慢或被阻塞（如大事务、锁等待） - 看
Relay_Log_Space：持续暴涨 → SQL 线程严重落后，relay log 积压（可能磁盘撑爆）
常见故障与快速定位思路
面试常问：“从库报错 1032 或 1062 怎么办？”核心不是背解决方案，而是展现排查逻辑：
-
1062（主键冲突）：通常是人为在从库写了数据，或主库做了 REPLACE/INSERT IGNORE 导致主从行为不一致 → 先查
SHOW CREATE TABLE确认主从表结构/索引是否一致 - 1032（记录不存在）：主库删了一行，从库找不到该行去删 → 往往因从库误写、跳过错误、或主库 binlog 格式为 STATEMENT 时函数结果不一致
- 通用动作：先 STOP SLAVE；再用 mysqlbinlog 解析出错位置的 binlog/relay log，确认具体语句；再决定跳过（SET GLOBAL sql_slave_skip_counter=1）、修复数据，或重建从库
- 不要一上来就
START SLAVE—— 错误未解决，重启后立刻再次报错
GTID 复制相比传统复制的优势与注意事项
GTID（Global Transaction ID）让复制更可靠、切换更简单，但不是万能：
- 优势：自动定位同步位点（不用记 file/pos），避免重复执行（每个事务有唯一 ID），主从切换无需找日志坐标
- 必须开启：
gtid_mode=ON+enforce_gtid_consistency=ON，且所有节点 gtid_mode 严格一致 - 陷阱：不能混用 GTID 和非 GTID 实例做主从；执行
CHANGE MASTER TO必须用MASTER_AUTO_POSITION=1；跳过事务要用SET GTID_NEXT='xxx'; BEGIN; COMMIT;，不能用 sql_slave_skip_counter - GTID 下
Seconds_Behind_Master计算更准确，但遇到大事务或网络抖动仍会延迟
