MySQL主从复制是指将一个MySQL实例（主库，Master）上的数据变更，自动同步到至少一个其他MySQL实例（从库，Slave）上的机制。它是MySQL实现高可用、读写分离和数据备份的底层基础。主库负责处理写请求，从库通常通过重放主库的日志来保持数据一致，并可以承接读请求以减轻主库压力。
一、MySQL主从复制的核心概念
在理解主从复制前，需要先厘清几个基础概念。首先是binlog（二进制日志），它是主库记录所有数据修改操作（如INSERT、UPDATE、DELETE以及DDL）的日志文件，主从复制的数据源头就是它。从库并不会直接读取主库表数据，而是读取binlog中的事件。
其次是server-id，每个MySQL实例在复制集群中必须拥有全局唯一的server-id，否则主从之间会出现冲突或拒绝连接。另外还有“中继日志”（relay log），它是从库接收到主库binlog后，在本地暂存的日志，供SQL线程后续执行。复制位点（Position）则标记了当前已同步到哪个binlog的哪个偏移量，是故障恢复的重要依据。
二、主从复制的基本工作流程
MySQL主从复制依赖三个核心线程协作。主库上有一个Binlog Dump线程，当从库连接时，它负责读取binlog并发送给从库。从库上则有IO线程和SQL线程：IO线程向主库发起请求，接收binlog事件并写入本地的中继日志；SQL线程读取中继日志，在从库上重放这些事件，从而实现数据同步。
典型的异步复制过程如下：主库提交事务并写入binlog，Dump线程通知从库；从库IO线程拉取binlog存入relay log，并更新主库位点信息；SQL线程执行relay log中的语句。由于主库提交后不等待从库确认，因此异步模式下从库数据可能短暂滞后，但性能影响最小。
-- 主库创建用于复制的账号 CREATE USER 'repl'@'192.168.0.%' IDENTIFIED BY 'repl_pass'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.%'; -- 查看主库binlog状态 SHOW MASTER STATUS; -- 从库配置主库连接信息（需替换实际IP、位点） CHANGE MASTER TO MASTER_HOST='192.168.0.10', MASTER_USER='repl', MASTER_PASSWORD='repl_pass', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; -- 启动从库复制 START SLAVE; -- 查看从库复制状态 SHOW SLAVE STATUSG
三、复制模式与数据一致性
除了默认的异步复制，MySQL还支持半同步复制和全同步复制。半同步复制要求主库提交事务时，至少等待一个从库接收并写入relay log后再返回成功，这降低了数据丢失概率，但增加了写延迟。全同步复制则需所有从库确认，一致性最高但性能开销大，实际中较少使用。
对于业务选型，如果读多写少且允许秒级延迟，异步复制最合适；如果金融类业务要求不丢数据，可开启半同步复制。需要注意，即使开启半同步，在网络分区时也可能降级为异步，因此应用层仍需兜底校验机制。
| 复制模式 | 数据安全性 | 写性能 | 适用场景 |
|---|---|---|---|
| 异步复制 | 可能丢失最后事务 | 最高 | 普通互联网业务 |
| 半同步复制 | 较高 | 中等 | 订单、支付类 |
| 全同步复制 | 最高 | 最低 | 强一致内部系统 |
四、常见误区与基础排查
不少初学者认为主从复制能替代备份，这是错误的。复制是实时同步，若主库执行了DROP TABLE，从库也会立刻删除，无法防范人为误删。真正的数据备份应使用mysqldump或物理备份工具，并异地保存。
当从库出现Slave_SQL_Running: No时，多是主键冲突或表结构不一致导致。可先通过SHOW SLAVE STATUS查看Last_Error，若是无关紧要的冲突，可跳过错误位点后重启复制，但生产环境应优先修复数据差异而非盲目跳过。
主从复制不是银弹，它解决的是扩展读能力和容灾，而非数据误操作的回滚。
五、小结
MySQL主从复制以binlog为纽带，通过主库Dump线程、从库IO与SQL线程的配合，实现数据跨实例同步。掌握server-id、复制位点、中继日志等概念，理解异步与半同步的差异，才能在设计数据库架构时做出合理取舍，并为后续读写分离、高可用切换打好基础。