04 binlog 主从复制
binlog 主从复制
源端提交产生 binlog 事件，副本接收成 relay log，再由 applier 回放；接收进度与执行进度是两种状态。
版本：MySQL Community Server 26.10.0（InnoDB）；核实日期：2026-11-12。官方在线文档可能继续更新，源码链接固定到对应发布标签。图为原理抽象，省略非本页重点。
specification {
element actor { style { shape person; color amber } }
element system { style { color muted } }
element component { style { color primary } }
element storage { style { shape storage; color green } }
}
model {
src = system '源端事务'
bin = storage '源端 binlog'
send = component 'Binlog sender'
recv = component '副本 receiver'
relay = storage 'Relay log'
apply = component 'Applier / workers'
data = storage '副本 InnoDB'
}
views {
dynamic view index {
title '核心链路'
variant sequence
src -> bin '提交已记录的事务事件'
recv -> send '连接并按 GTID / 文件位置请求'
send -> bin '读取待传输事件'
send -> recv '发送 binlog 事件流'
recv -> relay '保存接收的事件'
apply -> relay '调度可执行事务'
apply -> data '回放并提交事务'
apply -> apply '更新执行位置 / GTID 集合'
}
}
关键判断
- 异步复制中源端 COMMIT 不等待副本应用；read-after-write 不能仅凭源端成功回复保证。
- receiver 与 applier 分工使复制能缓冲，也会形成接收正常但执行落后的情况；排查要分别看 I/O、SQL 与 worker 状态。
- GTID 标识事务并支持自动定位，不能代替数据初始一致性检查，也不自动消除所有冲突或延迟。
边界
图限于普通 binlog 异步复制；半同步确认不等于副本已执行，Group Replication 则是另一套组成员与认证机制。