MySQL开源数据库复制原理是什么

MySQL 数据库复制（Replication）的核心原理是 基于二进制日志（Binary Log，简称 binlog）的异步复制机制，主库将变更记录到 binlog，从库读取并重放这些变更，从而实现数据同步。下面从整体架构、关键流程、工作细节和常见模式来说明。

一、MySQL 复制的整体架构

MySQL 复制是一种 主从（Master–Slave）架构：

• 主库（Master）：负责处理写操作，并将数据变更记录到 binlog
• 从库（Slave）：从主库获取 binlog，并在本地重放，保持与主库一致

从 MySQL 5.7 开始，也支持多主、级联复制等复杂拓扑。

二、复制的核心原理（三步）

1️⃣ 主库记录 binlog（Binary Log）

前提条件：

• 主库开启 log_bin
• 使用支持事务的存储引擎（如 InnoDB）

过程：

• 主库执行 INSERT / UPDATE / DELETE
• 在事务提交前或提交时，将变更写入 binlog
• binlog 是 顺序写入的日志文件

binlog 格式有三种：

• STATEMENT：记录 SQL 语句（可能主从不一致）
• ROW（推荐）：记录每一行数据的变化
• MIXED：混合模式

✅ 生产环境强烈推荐使用 ROW 模式

2️⃣ 从库 I/O 线程拉取 binlog

从库上有两个核心线程：

✅ I/O Thread（I/O 线程）

• 连接主库
• 请求主库的 binlog
• 将主库的 binlog 复制到本地
• 保存为 relay log（中继日志）

类似“下载 + 缓存”

3️⃣ 从库 SQL 线程重放 relay log

✅ SQL Thread（SQL 线程）

• 读取 relay log
• 按顺序执行其中的变更
• 在从库上重放主库的写操作

⚠️ 早期版本中，SQL 线程是单线程，容易成为瓶颈
✅ MySQL 5.7+ 支持 并行复制（MTS）

三、复制流程图（简化版）

主库
 ├─ 执行事务
 ├─ 写 binlog
 │
从库
 ├─ I/O 线程 → 拉取 binlog → 写入 relay log
 ├─ SQL 线程 → 读取 relay log → 执行 SQL

四、复制的关键文件与状态

主库关键参数

server-id = 1
log_bin = mysql-bin
binlog_format = ROW

从库关键参数

server-id = 2
relay_log = relay-bin
read_only = 1

查看复制状态（从库）

SHOW SLAVE STATUS\G

重点关注：

• Slave_IO_Running
• Slave_SQL_Running
• Seconds_Behind_Master

五、复制的异步特性（重点）

MySQL 默认复制是 异步复制：

• 主库提交事务后 不等待从库确认
• 主库立即返回客户端
• 从库可能在“稍后”才同步

✅ 优点：性能高
❌ 缺点：

• 主库宕机可能丢数据
• 从库可能落后（延迟）

六、复制模式演进

七、并行复制（重要）

MySQL 并行复制原理

• 按 数据库 / 事务依赖 / 逻辑时钟 并行执行
• 减少 SQL 线程瓶颈

相关参数：

slave_parallel_workers = 4
slave_parallel_type = LOGICAL_CLOCK

八、复制的典型用途

• 读写分离
• 数据备份
• 高可用（配合 MHA / Orchestrator）
• 数据分析（从库做报表）

九、一句话总结

MySQL 复制的本质是：主库把数据变更记录到 binlog，从库通过 I/O 线程拉取并在本地重放，从而实现数据同步。

如果你愿意，我可以：

• 画一张更详细的复制流程图
• 对比 binlog vs redo log
• 讲 半同步复制 vs 异步复制
• 结合 主从延迟问题 深入分析