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 集群），单靠主从无法完全满足
