主从复制通过二进制日志传输与重放实现数据同步，主库记录变更到binlog，从库I/O线程拉取并写入relay log，sql线程执行relay log中事件完成数据更新；依赖Binary Log Dump Thread、I/O Thread和SQL Thread协同工作，支持STATEMENT、ROW和MIXED三种模式，推荐使用ROW模式以保证一致性，结合sync_binlog、innodb_flush_log等参数及半同步机制提升可靠性，是读写分离与高可用架构的基础。

mysql主从复制的原理是通过日志传输和重放机制，实现数据从一个数据库（主库）自动同步到一个或多个数据库（从库）的过程。核心目标是保证从库的数据与主库保持一致，同时降低主库的读负载压力。

主从复制的基本流程

主从复制主要依赖三种日志和两个线程协同工作：

• 二进制日志（Binary Log）：主库记录所有更改数据的操作（如INSERT、UPDATE、delete）。
• 中继日志（Relay Log）：从库接收到的主库日志事件先写入中继日志。
• 从库的SQL线程：读取中继日志并执行其中的操作，从而更新从库数据。

具体步骤如下：

1. 主库在执行数据变更时，将操作写入二进制日志（Binary Log）。
2. 从库的I/O线程连接主库，请求从指定位置开始读取二进制日志。
3. 主库的dump线程将二进制日志内容发送给从库。
4. 从库的I/O线程接收到日志事件后，写入本地的中继日志（Relay Log）。
5. 从库的SQL线程读取中继日志中的事件，并按顺序执行，完成数据同步。

关键组件说明

理解主从复制需要掌握几个核心组件的作用：

• Binary Log Dump Thread（主库）：负责响应从库的连接请求，推送binlog内容。
• I/O Thread（从库）：负责拉取主库的binlog并保存为relay log。
• SQL Thread（从库）：执行relay log中的sql语句，使数据变化生效。

这些线程独立运行，使得网络延迟或执行延迟不会直接阻塞主库业务。

云从科技AI开放平台

云从AI开放平台

51

查看详情

复制模式的选择

MySQL支持多种复制格式，影响日志记录方式和兼容性：

• STATEMENT（SBR）：记录SQL语句本身。优点是日志量小，但某些非确定性函数可能导致主从数据不一致。
• ROW（RBR）：记录每一行数据的变化。更安全，适合复杂环境，但日志体积大。
• MIXED（MBR）：结合前两者，由系统自动选择合适格式。

推荐使用ROW模式，能有效避免因函数或触发器导致的数据偏差问题。

主从一致性保障

虽然主从复制是异步的，存在短暂延迟，但可以通过以下方式提升可靠性：

• 启用sync_binlog=1和innodb_flush_log_at_trx_commit=1，确保事务持久化。
• 使用半同步复制（semi-sync replication），要求至少一个从库确认接收日志后才提交事务。
• 定期检查Seconds_Behind_Master值，监控复制延迟。

基本上就这些。主从复制机制设计简洁但功能强大，是构建高可用、读写分离架构的基础。