直接回答

主从复制基于 binlog 实现：主库把数据变更写入 binlog；从库的 I/O 线程连接主库拉取 binlog 存入本地的 relay log；从库的 SQL 线程（新版本中可并行）重放 relay log 中的变更，从而保持与主库数据一致。复制默认是异步的，主库不等待从库确认。

展开解析

完整链路：主库执行事务 → 写 binlog → dump 线程把 binlog 推给从库 I/O 线程 → 写 relay log → SQL 线程重放。复制模式有异步（默认）、半同步（至少一个从库收到 binlog 后主库才返回成功）、组复制（MGR，基于 Paxos 协议）。5.7 之后引入基于逻辑时钟的并行复制，缩短从库重放耗时。

主从延迟处理思路：

  1. 减少延迟源头：大事务拆小、DDL 错峰执行、开启并行复制、从库配置不低于主库。
  2. 架构规避：对实时性要求高的读请求强制走主库；用缓存承载热点读。
  3. 监控与兜底：监控 Seconds_Behind_Master，延迟超阈值时摘除从库或读流量切换。

追问方向：半同步与全同步的取舍、GTID 的作用、如何避免主从切换时数据丢失。