主从复制通过二进制日志传输与重放实现数据同步。1. 主库记录Binary Log；2. 从库I/O线程连接主库获取日志；3. 主库dump线程发送日志事件；4. 从库I/O线程写入Relay Log；5. 从库SQL线程执行中继日志，保持数据一致。
MySQL主从复制的核心是通过日志传输与重放，实现数据在多个数据库实例间的同步。主库负责处理写操作，并将变更记录传播到一个或多个从库，从而达到数据冗余、读写分离和提升系统可用性的目的。
主从复制的基本流程
主从复制依赖于三种关键日志和线程机制，整个过程可分为以下几个步骤：
- 主库记录二进制日志（Binary Log）：所有对数据产生更改的操作（如INSERT、UPDATE、DELETE）都会被记录到二进制日志中，按执行顺序保存。
- 从库启动I/O线程连接主库：从库会启动一个I/O线程，连接到主库并请求获取自上次同步以来的二进制日志内容。
- 主库发送日志事件：主库创建一个dump线程，将二进制日志中的更新事件发送给从库。
- 从库写入中继日志（Relay Log）：从库的I/O线程接收到这些事件后，将其写入本地的中继日志文件。
- 从库SQL线程回放日志：从库的SQL线程读取中继日志中的事件，并逐条执行，从而实现与主库的数据一致。
涉及的关键组件说明
理解主从复制必须掌握以下核心组件的作用：
- Binary Log：主库记录数据变更的日志，是复制的数据源。需在主库配置中开启 log-bin 才能启用。
- Relay Log：从库用于暂存来自主库日志的中间文件，由I/O线程写入，SQL线程读取执行。
- Master Info Repository：存储从库连接主库的信息，如主机地址、用户名、密码、当前读取的日志文件名和位置。
- Relay Log Info Repository：记录SQL线程已执行到中继日志的哪个位置，确保断点续传。
复制模式的选择
MySQL支持多种复制格式，不同模式影响日志内容和复制行为：
- STATEMENT-based：记录SQL语句本身。优点是日志量小，但某些非确定性函数（如NOW()）可能导致主从数据不一致。
- ROW-based：记录每一行数据的修改。更安全准确，适合复杂环境，但日志体积较大。
- MIXED：结合前两者，MySQL自动选择合适的格式。推荐在生产环境中使用。
常见问题与注意事项
虽然主从复制机制成熟，但在实际部署中仍需注意以下几点：
- 确保主从服务器时间同步，避免因时间偏差导致监控误判。
- 主库的server-id和从库必须不同，否则复制无法启动。
- 从库默认为只读（可设置read_only），防止意外写入破坏一致性。
- 网络延迟或从库负载过高会导致复制延迟，需定期监控Seconds_Behind_Master值。
- 使用GTID（全局事务标识符）可简化故障切换和复制管理，避免传统基于文件位置的复杂定位。
基本上就这些。只要理解了日志传递和回放的流程，再结合实际配置，就能搭建稳定可靠的MySQL主从架构。
