mysql主从复制完全依赖binlog驱动；io线程负责拉取日志，sql线程负责重放；server-id必须唯一以避免循环复制；异步复制不等待从库确认，存在数据丢失风险。
主从复制靠什么日志驱动？
MySQL 主从复制完全依赖 binlog（二进制日志）——它不是事务日志，也不是 redo log，而是专为复制设计的逻辑变更日志。只要主库启用了 log-bin，所有 DML（INSERT/UPDATE/DELETE）和部分 DDL（如 CREATE TABLE）操作，都会按执行顺序写入 binlog。从库不直接读主库磁盘，而是通过网络拉取这些日志事件，再重放。
常见错误现象：从库同步延迟、数据不一致、SHOW SLAVE STATUS 中 Seconds_Behind_Master 持续增长——十有八九是 binlog 格式或落盘策略没配对。
-
binlog_format=row是当前推荐配置：避免函数（如NOW()、UUID()）、自增主键、触发器等导致主从不一致 - 别用
binlog_format=statement配合READ-COMMITTED隔离级别，极易出现主从行数差异 -
sync_binlog=1+innodb_flush_log_at_trx_commit=1才能保证主库崩溃后不丢 binlog 事件（但会轻微影响性能）
I/O 线程和 SQL 线程各干啥？为什么不能合二为一？
从库靠两个独立线程完成复制：IO_THREAD 负责“搬运”，SQL_THREAD 负责“执行”。它们解耦设计，是为了应对网络抖动、大事务、锁竞争等现实问题。
典型卡点场景：SQL_THREAD 执行一个耗时 5 分钟的 UPDATE，而 IO_THREAD 已经把后续 10 分钟的 binlog 全部拉到本地 relay-log 里了——这正是 Seconds_Behind_Master 的来源，但复制本身并未中断。
-
IO_THREAD连接主库后，会持续监听master.info记录的位点（File+Position），并请求新事件；断连重试由它自动处理 -
SQL_THREAD每执行完一个 relay-log 事件，就更新relay-log.info，这是从库“知道自己同步到哪”的唯一依据 - MySQL 8.0+ 支持多线程复制（
slave_parallel_workers > 0），但仅对不同库/表的并发事务有效，单表大事务仍只能串行回放
为什么必须设不同的 server-id？
server-id 不是“名字”，而是复制拓扑里的唯一身份标识。主库靠它识别哪个从库在连自己，从库靠它避免 relay-log 被自己再次读取（防止循环复制）。一旦重复，轻则同步停止，重则整个复制链路雪崩。
容易踩的坑：
- 克隆虚拟机部署 MySQL 后，忘记改
/etc/my.cnf里的server-id，两台机器 ID 相同 →START SLAVE报错ERROR 1236 (HY000) - Docker 容器未绑定固定
server-id，每次重启随机分配 → 复制元数据错乱 - 级联复制（A→B→C）中，B 既要当 A 的 slave，又要当 C 的 master，必须同时启用
log-bin和设置唯一server-id，否则 C 无法从 B 继续同步
异步复制到底“异步”在哪？
异步复制的“异步”，特指主库提交事务时，**不等待任何从库确认**。主库写完 binlog 并刷盘、通知引擎层提交，就立刻返回客户端成功。此时从库可能还没收到这条日志，甚至网络已断。
这意味着：主库宕机瞬间，最后几秒的事务大概率丢失，从库永远追不回来。
- 想降低丢失风险？开启半同步复制：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'，并设rpl_semi_sync_master_enabled=1 - 但要注意：半同步下，若所有从库都超时未响应，主库会自动退化为异步模式（由
rpl_semi_sync_master_timeout控制），这个降级行为常被忽略 - 真正强一致？得上 MGR（MySQL Group Replication），但它不是简单开关，而是要重构集群架构和应用容错逻辑
真正难的从来不是配通复制，而是理解每个参数背后承担的风险边界——比如 binlog_format 选错，可能让线上订单号在从库重复；server-id 写错，能让整套灾备切换流程在关键时刻失灵。
