主从复制靠什么日志驱动？
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写错，能让整套灾备切换流程在关键时刻失灵。
