【MySQL】主从复制原理详解：从 Binlog 到数据一致性

📌 目录

1. 什么是 MySQL 主从复制

2. 主从复制的应用场景

3. 二进制日志 Binlog 详解

4. MySQL 主从复制流程

5. 异步复制的问题与优化

6. Redo Log 与 Binlog 的关系

7. 数据一致性核心机制

8. 主从复制配置与备份

---

一、什么是 MySQL 主从复制

MySQL 主从复制是一种 基于日志的异步复制机制，用于将主库的数据同步到从库。

其核心依赖两种日志：

• Binlog（二进制日志，主库）

• Relay Log（中继日志，从库）

支持三种复制模式：

模式	说明
Statement	基于 SQL 语句复制
Row	基于行数据复制
Mixed	自动切换

---

二、主从复制的应用场景

在实际项目中，主从复制主要用于：

读写分离（最常见）

负载均衡

数据备份（注意：复制不等于备份）

高可用架构（主从切换）

数据库升级迁移

---

三、二进制日志 Binlog

1. 什么是 Binlog

Binlog 用于记录所有 修改数据的操作：

• INSERT

• UPDATE

• DELETE

注意：

SELECT 查询不会记录

---

2. Binlog 的作用

数据复制的基础

数据恢复（配合备份使用）

---

3. Binlog 三种格式

格式	原理	优点	缺点
STATEMENT	记录 SQL	日志小 性能高	可能不一致
ROW	记录数据变化	精确可靠	日志大
MIXED	自动切换	折中方案	逻辑复杂

---

Tips

生产环境一般建议使用：

binlog_format = ROW

原因是数据一致性更可靠

---

四、MySQL 主从复制流程

1. 五步流程

1 主库写入 Binlog

2 从库 IO 线程请求日志

3 主库 Dump 线程发送日志

4 从库写入 Relay Log

5 从库 SQL 线程执行

---

2. 流程图理解

主库写 Binlog

通过网络发送

从库写入 Relay Log

再执行恢复数据

---

3. 核心线程

线程	作用
IO Thread	拉取主库日志
SQL Thread	执行日志

---

五、异步复制的问题与优化

1. 异步复制问题

主库提交成功

但从库还没同步

可能导致：

主从数据不一致

主库宕机导致数据丢失

---

2. 主从延迟问题

原因：

主库并发写入

从库单线程执行

解决方案：

slave_parallel_workers = 4

开启并行复制

---

3. 半同步复制

为了解决数据丢失问题：

主库提交事务时

至少一个从库确认接收

优点：

降低数据丢失风险

缺点：

性能略有下降

---

六、Redo Log 与 Binlog 的关系

这是 MySQL 面试高频重点

1. 两种日志的区别

日志	层级	作用
Redo Log	存储引擎层	保证崩溃恢复
Binlog	Server 层	用于复制

---

2. 执行流程

1 写 Redo Log（prepare）
2 写 Binlog
3 提交事务

---

七、数据一致性核心机制

1. 为什么需要一致性

如果：

Redo Log 写了

Binlog 没写

会导致：

主从数据不一致

---

2. 两阶段提交

MySQL 使用两阶段提交保证一致性：

阶段	操作
Prepare	写 Redo Log
Commit	写 Binlog

只有 Binlog 写成功

事务才算成功

---

3. 安全配置建议

innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

说明：

每次提交都刷盘

保证数据最安全

---

Tips

这两个参数：

安全性最高

但性能会下降

---

八、主从复制配置与备份

1. 常见备份工具

工具	类型	优点	缺点
mysqldump	逻辑备份	灵活	慢
XtraBackup	物理备份	快 支持热备	依赖工具

---

2. 表级复制配置

replicate-do-table=db_name.table_name

---

Tips

推荐：

全库复制 + 读写分离

---

九、总结

MySQL 主从复制核心可以总结为三点：

1.数据同步流程：

主库写 Binlog

从库拉日志

从库执行日志

2.数据一致性核心：

Redo Log + Binlog

两阶段提交

3.系统核心问题：

主从延迟

数据一致性

性能与可靠性的权衡