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

📌 目录

什么是 MySQL 主从复制
主从复制的应用场景
二进制日志 Binlog 详解
MySQL 主从复制流程
异步复制的问题与优化
Redo Log 与 Binlog 的关系
数据一致性核心机制
主从复制配置与备份

一、什么是 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.系统核心问题：

主从延迟

数据一致性

性能与可靠性的权衡