MySQL主从复制是通过binlog日志实现的异步数据同步机制，主库记录DML/DDL操作至binlog，从库通过IO线程拉取并写入relay log，再由SQL线程重放执行；依赖binlog position或GTID定位同步起点，支持半同步增强一致性。
MySQL主从复制，就是让一台MySQL服务器（主库）把数据变更自动“同步”给另一台或几台服务器（从库），实现主库写、从库读的分工。它不是实时镜像，而是一套有顺序、可追踪、带缓冲的日志转发与重放机制。
主从复制靠什么驱动？——binlog是核心
主库必须开启二进制日志（binlog），所有增删改（DML）和建表改表（DDL）操作都会按时间顺序记入这个日志文件。没有binlog，复制就无从谈起。
- binlog只记录“做了什么”，不关心执行结果是否成功（失败的语句不会写入）
- 格式可选：基于语句（STATEMENT）、基于行（ROW）或混合（MIXED），推荐ROW模式，避免函数、时间戳等导致主从不一致
- binlog文件会滚动，如 mysql-bin.000001、mysql-bin.000002，每个文件有起始位置（pos）
数据是怎么“跑”到从库的？——三个线程各司其职
复制过程由三类线程协作完成，主库一个dump线程，从库两个线程（IO + SQL）：
- 主库的dump线程：当从库发起连接请求时，主库为它单独启动一个dump线程，负责把binlog内容按需“推”过去
- 从库的IO线程：连接主库，拉取binlog事件，并原样写入本地的中继日志（relay log），相当于先缓存下来
- 从库的SQL线程：读取relay log里的事件，一条条在本地重放（执行INSERT/UPDATE等），最终达成数据一致
从库怎么知道该从哪开始同步？——位点（position）是关键
每次从库启动复制，都要告诉主库：“我上次已同步到 mysql-bin.000005 文件的 12345 这个位置”。主库就从那个位置往后发新日志。
- 这个“文件名+位置号”叫binlog position，是传统复制方式的定位依据
- 重启从库或手动跳过错误时，常需要手动指定position（如 CHANGE MASTER TO ... MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy）
- MySQL 5.6+ 支持GTID（全局事务ID），用事务编号代替位置，更易管理、容错性更强
它是实时的吗？——默认异步，但可增强
标准主从是异步复制：主库写完binlog就返回成功，不等从库确认。这意味着从库可能延迟几秒甚至更久，尤其在大事务、网络波动或从库负载高时。
- 若要求更高一致性，可启用半同步复制：主库至少等一个从库写入relay log并返回ACK，才提交事务
- 注意：半同步不能保证SQL线程已执行完毕，只是保证日志已安全落盘
- 强一致性场景（如金融）通常需结合其他方案（如MGR集群），单靠主从无法完全满足
