MySQL主从同步的原理

从库的IOThread线程会去主库的binlog日志中读取数据，读取后就写入从库的中继日志Relay log
再由从库的SQL Thread线程去读取中继日志的文件，把里面的命令执行一下，执行完后主库和从库的数据就一致了

MySQL 主从同步（Replication）是数据库高可用、读写分离、数据备份的核心技术。它的核心目标是：将主库（Master）的数据变更，实时或近实时地复制到一个或多个从库（Slave）。

一、主从同步的基本架构

+---------+     binlog     +----------+
| Master  | -------------> |  Slave   |
| (主库)  |   dump thread  | (从库)   |
+---------+                +----------+
   ↑                            ↑
 用户写入                        用户读取

• 主库（Master）：负责处理写操作（INSERT/UPDATE/DELETE）
• 从库（Slave）：复制主库数据，通常用于读操作（实现读写分离）

二、主从同步的核心原理（基于 binlog）

MySQL 主从同步依赖 二进制日志（Binary Log, binlog），整个过程分为三个关键步骤：

✅ 步骤1：主库记录 binlog

• 当主库执行 DML（数据操作语句） 时，会将这些操作以事件（Event） 的形式记录到 binlog 文件中。
• 记录格式由 binlog_format 决定：
  • STATEMENT：记录 SQL 语句（如 UPDATE user SET age=25 WHERE id=1）
  • ROW：记录行的变更（推荐，更安全）
  • MIXED：混合模式

🔍 binlog 是逻辑日志，只记录改变了什么数据。

✅ 步骤2：从库的 I/O Thread 拉取 binlog（日志传输）

• 从库启动一个 I/O Thread，连接到主库。
• 请求从指定的 binlog 文件和位置（position）开始，读取后续的 binlog 事件。
• 主库通过 Dump Thread 将 binlog 发送给从库。
• 从库的 I/O Thread 将接收到的事件写入本地的 中继日志（Relay Log） 文件。

📌 类比：从库像“快递员”，定期去主库“取货”（binlog），然后存到本地“中转仓”（relay log）。

✅ 步骤3：从库的 SQL Thread 回放日志（数据应用）

• 从库启动一个 SQL Thread，读取 relay log 中的事件。
• 按顺序重新执行这些操作，从而在从库上还原主库的数据变更。

📌 类比：从库根据“操作清单”（relay log）一步步执行，确保数据一致。

三、关键组件总结

四、主从同步的三种模式（binlog_format）

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

五、如何保证一致性？GTID（全局事务ID）

传统同步依赖 binlog filename + position，容易出错。

GTID（Global Transaction Identifier） 是 MySQL 5.6+ 引入的改进：

• 每个事务都有一个全局唯一 ID，如：3E11FA47-71CA-11E1-9E33-C80AA9429562:1
• 从库只需告诉主库“我已经同步到哪个 GTID”，自动定位同步位置。
• 支持自动故障切换、简化主从切换。

六、主从延迟（Replication Lag）问题

❌ 现象：

• 主库写入后，从库不能立即读到最新数据。
• 可能导致“读到旧数据”。

🚨 常见原因：

1. 从库 I/O 或 SQL Thread 单线程处理（MySQL 5.7 前）
2. 大事务（如批量更新百万行）
3. 网络延迟
4. 从库性能差

✅ 解决方案：

• 使用 并行复制（Parallel Replication）（MySQL 5.7+）
• 优化大事务
• 监控 Seconds_Behind_Master
• 关键读操作走主库（或使用半同步）

七、半同步复制（Semi-Sync Replication）

默认是异步复制：主库写完 binlog 就返回成功，不管从库是否收到。

半同步：主库至少等待一个从库确认收到 binlog 后才提交。

✅ 提高数据安全性，但增加延迟。

✅ 总结

🎯 一句话记住：
“主库记日志，从库取日志，回放变一致。”

掌握主从同步原理，是构建高可用 MySQL 架构的基础！