复制三线程模型
MySQL 主从复制靠三类线程协作：主库上有一个 dump 线程，从最后已知位点开始持续把二进制日志推送给从库；从库上有一个 IO 线程负责接收并写入中继日志，另一个 SQL 线程负责把中继日志里的事件重放成数据变更。理解这三条线程各自的职责，是排查复制问题的起点——断在拉取环节和断在重放环节，原因与处置完全不同。
基本信息
| 主库线程 | Binlog Dump，按位点推送二进制日志 |
|---|---|
| 从库线程 | IO 线程拉取写中继日志，SQL 线程重放 |
| 术语变化 | 8.0.22 起主从相关名称改用 SOURCE 与 REPLICA |
| 复制基础 | 基于二进制日志的异步复制，另有半同步与组复制 |
| 查看方式 | 主库看连接列表，从库看复制状态 |
| 常见断点 | 网络与认证影响拉取，数据冲突影响重放 |
典型使用场景
- 读写分离：写请求走主库、读请求走从库，前提是链路稳定
- 备份与报表减压：在从库上执行重查询与备份
- 高可用切换：主库故障时由从库提升接替
- 异地容灾：跨机房部署从库保留数据副本
- 数据分析：在从库上跑离线统计，避免影响主库
- 变更验证：把变更先同步到从库观察再推主库
查看三类线程
查看三类线程
SHOW PROCESSLIST; # 主库上能看到来自从库的推送连接
SHOW REPLICA STATUS\G # 从库上看 IO 与 SQL 线程状态和位点
SELECT SERVICE_STATE FROM performance_schema.replication_connection_status; # 8.0 结构化视图，便于监控接入复制相关配置要点
复制相关配置要点
[mysqld]
binlog_format = ROW # 行格式，主从数据一致的基础
log_bin = ON # 主库必须开启二进制日志
server_id = 10 # 同一拓扑内必须唯一
gtid_mode = ON # 开启 GTID，便于位点自动定位
log_replica_updates = ON # 级联复制时从库也要写自己的日志三线程职责与故障特征
| 对象 | 位置与职责 | 异常表现 |
|---|---|---|
| Binlog Dump | 主库为每个从库连接各起一个 | 主库看不到连接说明从库没连上或被拦截 |
| IO 线程 | 从库，拉取日志写入中继日志 | 异常多为网络、账号口令或位点已被清理 |
| SQL 线程 | 从库，重放中继日志为数据变更 | 异常多为主从数据冲突或约束报错 |
| 中继日志 | 从库本地文件，保存待重放事件 | 积压表示重放跟不上拉取，误删会导致数据丢失 |
| 位点 | 拉取位点与执行位点 | 两个位点差距大说明重放明显落后 |
| 延迟 | 从库落后主库的时间 | 是粗略指标，长事务下会失真 |
IO 线程与重放线程解耦是设计上的优点：网络抖动导致拉取中断时，重放线程还能继续消化已拉到的中继日志，数据变化不会立刻停住。
开启行格式日志后，数据变更以行事件重放，主从一致性最好；语句级格式在含有非确定性语句时容易出现主从不一致，因此生产环境以行格式为准。
中继日志不是临时文件，它保存着尚未重放的数据；磁盘清理脚本或人工删除会造成复制中断甚至数据丢失，清理前必须先确认是否已全部执行。
复制链路检查清单
- 确认主库已开启二进制日志且格式为行格式
- 确认拓扑内主机编号唯一，避免复制异常
- 从库拉取账号只授予复制相关权限，最小化授权
- 监控两个线程状态、位点差与中继日志占用
- 复制账号口令变更要同步更新从库配置
- 定期抽样比对主从数据，而不是只看线程是否在跑
延迟指标只反映大致落后程度，主库有长事务时它会失真甚至短暂归零；判断复制健康度要结合位点差、中继日志占用与业务侧的实际读取结果一起看。