MySQL 日志与复制
核心定位 本文整理 MySQL 日志体系与复制机制的面试题，重点覆盖 redo log、undo log、binlog、relay log、两阶段提交、主从复制线程和 GTID。
1. MySQL 有哪些核心日志
1.1. 题目
MySQL 中 redo log、undo log、binlog 分别有什么作用？
1.2. 参考答案
| 日志 | 所属层级 | 作用 |
|---|---|---|
| redo log | InnoDB 引擎层 | 崩溃恢复，保证持久性 |
| undo log | InnoDB 引擎层 | 事务回滚和 MVCC 历史版本 |
| binlog | Server 层 | 主从复制和时间点恢复 |
| relay log | 从库本地 | 保存从主库拉取的 binlog 事件 |
| slow log | Server 层 | 记录慢 SQL |
| error log | Server 层 | 记录启动、停止和异常信息 |
2. redo log 与 binlog 的区别
2.1. 题目
redo log 和 binlog 有什么区别？
2.2. 参考答案
| 对比项 | redo log | binlog |
|---|---|---|
| 所属层 | InnoDB 引擎层 | MySQL Server 层 |
| 记录内容 | 物理页修改 | 逻辑或行变更事件 |
| 主要用途 | 崩溃恢复 | 主从复制、PITR |
| 写入方式 | 循环写 | 追加写 |
| 是否所有引擎都有 | 否 | 是 |
redo log 解决“事务提交后宕机如何恢复”的问题，binlog 解决“如何复制和按时间点恢复”的问题。
3. 两阶段提交
3.1. 题目
为什么 MySQL 需要两阶段提交？
3.2. 参考答案
两阶段提交用于保证 redo log 和 binlog 的一致性。
prepare redo log
↓
write binlog
↓
commit redo log如果没有两阶段提交，可能出现 redo 已提交但 binlog 未写入，或 binlog 已写入但 redo 未提交，导致主库崩溃恢复后与从库复制结果不一致。
4. 主从复制流程
4.1. 题目
MySQL 主从复制的流程是什么？
4.2. 参考答案
主库写 binlog
↓
主库 dump thread 发送 binlog
↓
从库 IO thread 写 relay log
↓
从库 SQL thread 重放 relay log重点字段：
SHOW REPLICA STATUS\G关注 IO 线程、SQL 线程、复制延迟和错误信息。
5. GTID 的作用
5.1. 题目
GTID 相比传统 file + position 有什么优势？
5.2. 参考答案
GTID 使用全局事务编号定位复制进度，格式是：
server_uuid:transaction_id优势：
- 主从切换时无需人工找 binlog position。
- 从库可根据已执行 GTID 自动定位缺失事务。
- 更容易判断复制缺口和日志是否被清理。
- 故障恢复比传统位点更可靠。
6. 面试总结
标准回答 MySQL 日志体系中，redo log 用于 InnoDB 崩溃恢复，undo log 用于事务回滚和 MVCC，binlog 用于主从复制和时间点恢复。redo 属于引擎层、循环写；binlog 属于 Server 层、追加写。事务提交时通过两阶段提交保证 redo 和 binlog 一致。主从复制中，主库写 binlog，从库 IO 线程拉取写入 relay log，SQL 线程重放 relay log。GTID 用全局事务编号替代传统位点，能降低主从切换和故障恢复复杂度。
关联文档
- MySQL 复制原理与配置：系统理解主从复制链路。
- GTID 集合详解：理解 GTID 集合和复制定位。
- MySQL binlog 保留时间与清理：理解 binlog 保留与恢复窗口。