MySQL主从复制是通过binlog日志将主库数据变更有序同步至从库，依赖主库binlog、唯一server_id、复制账号及从库relay log；由dump、I/O、SQL三线程协同完成记录、传输、重放三阶段；支持SBR、RBR、MBR三种复制模式。
MySQL主从复制，本质是把主库（Master）上执行的数据变更操作，通过日志机制完整、有序地同步到一个或多个从库（Slave），从而实现数据冗余、读写分离和高可用支撑。
主从复制依赖的核心组件
要让复制正常运转，必须满足几个基础条件：
- 主库开启 binlog：所有增删改、建表、授权等操作都记录在二进制日志中，这是复制的唯一数据源；
- 主从配置唯一 server_id：每个 MySQL 实例必须有全局唯一的 server_id，否则复制线程无法识别身份；
-
从库创建复制账号：主库需创建具备
REPLICATION SLAVE权限的用户，供从库连接并拉取日志； - 从库开启 relay log：中继日志是 binlog 的“本地缓存”，SQL 线程从中读取并重放，避免 I/O 和执行耦合。
三个关键线程协同工作
复制不是单一线程完成的，而是由三类角色明确分工：
- Master 的 binlog dump 线程：每当一个从库连接上来，主库就启动一个 dump 线程，负责按请求位置读取 binlog 并实时推送；
-
Slave 的 I/O 线程：模拟客户端连接主库，持续接收 dump 线程发来的 binlog 事件，写入本地 relay log，并更新
master.info记录已同步到的位置； - Slave 的 SQL 线程：串行读取 relay log 中的事件，解析成 SQL 并在本地执行，完成数据还原。注意：它是单线程的，这也是主库高并发写时从库容易延迟的根本原因。
复制过程分三步走
整个流程可简化为清晰的三阶段：
- 记录：主库事务提交前，先将变更写入 binlog（顺序写，高效）；
- 传输：从库 I/O 线程拉取 binlog 内容，落盘为 relay log（异步、非阻塞）；
- 重放：从库 SQL 线程回放 relay log，逐条执行，使从库数据状态逐步逼近主库。
复制类型与适用场景
MySQL 支持三种日志格式，影响复制行为和一致性：
-
基于语句的复制（SBR）：默认方式，记录原始 SQL。优点是日志体积小；缺点是某些函数（如
NOW()、UUID()）或非确定性语句可能造成主从不一致； - 基于行的复制（RBR）：记录每一行数据变更前后的镜像。安全性高、一致性好，但日志体积大、排查问题稍难；
- 混合模式（MBR）：MySQL 自动判断——确定性语句用 SBR，风险操作自动切 RBR，兼顾效率与安全，生产环境推荐使用。
