③ 主从复制：为什么、原理、搭建与延迟

对应第 118 ~ 124 讲 · 复制流水线 · 异步/半同步/GTID · pt-heartbeat 与并行复制

总览 ① 案例·半连接与选错索引 ② 案例·深分页与慢查询 ③ 主从复制架构 ④ 高可用故障转移 ⑤ 分库分表实战 执行计划篇 85~108 架构与实践篇 01~20
用途与复制原理（118 ~ 119 讲） 异步复制搭建（121 讲） 半同步复制（122 讲） GTID 复制 与 主从延迟治理（123 ~ 124 讲） 原理落地为搭建 还要解决延迟 ① 高可用 主宕机切从 复制的先决条件 必须做 ② 读写分离 写主读从 一主多从抗读 按需做 从库兼职 专跑重型报表 数据同步 隔离慢查询 主库 binlog 记录所有增删改 （04 讲伏笔回收） IO dump 线程 主库侧 发送 binlog 从库 IO 线程 TCP 连接主库 请求接收 binlog ↓ 从库收到 binlog 写入本地 relay 日志 → SQL 线程读取重放，把主库执行过的增删改再做一遍 → 主从数据一致 异步复制（默认） 主库写完 binlog 就返回 · 不管从库收没收到 主库宕机 → binlog 没同步到从库 → 刚写入的数据丢失 搭建步骤 server-id 不同 + 主库开 binlog → 建复制账号（grant replication slave） mysqldump --single-transaction --master-data=2 全量备份（记 binlog 位点） 从库导入 → CHANGE MASTER TO → start slave 验证 show slave status：Slave_IO_Running / Slave_SQL_Running = Yes 主库插一条数据 → 从库能查到 → 复制成功 AFTER_COMMIT（非默认） 写 binlog → 复制到从库 → 提交本地事务 → 等从库响应 → 返回客户端成功 AFTER_SYNC（MySQL 5.7 默认 ★） 写 binlog → 复制给从库 → 等从库响应 → 再提交事务 → 返回客户端成功 开启方式 install plugin rpl_semi_sync_master/slave + set ..._enabled=on 重启从库 IO 线程 · show global status like '%semi%' 验证 GTID 复制（更简便的搭建方式） gtid_mode=on · enforce_gtid_consistency=on · log_slave_updates=1 备份文件带 GTID_PURGED · show master status 对 executed_gtid_set 主从延迟 主库多线程写 · 从库单线程拉 → 从库必然落后 写后立即读 → 读不到新数据（读写分离的经典业务 bug） 延迟监控：pt-heartbeat 主库 heartbeat 表定时更新时间戳 · 从库 monitor 比对 两大解法 并行复制（workers>0 + LOGICAL_CLOCK）· 中间件强制读主 图例 用途 / 推荐做法 复制链路 / 搭建 半同步模式 风险 / 问题 GTID / 工具

复制原理流水线（背下来）

  • • 主库：增删改写入 binlog
  • • 从库 IO 线程：TCP 连主库请求 binlog
  • • 主库 IO dump 线程：发送 binlog
  • • 从库：写 relay 日志 → SQL 线程重放

复制方式怎么选

  • • 异步：性能好，主库宕机可能丢刚写入的数据
  • • 半同步 AFTER_SYNC（5.7 默认）：先同步从库再提交
  • • 提交成功 = binlog 必已到从库 → 切换不丢数据
  • • GTID：免手动找 binlog 位点，搭建更省心

主从延迟治理组合拳

  • • 根因：主库并行写，从库单线程回放
  • • 监控：percona-toolkit 的 pt-heartbeat
  • • 从库并行复制：slave_parallel_workers > 0
  • • 强一致读：中间件里强制读写都走主库

③ 主从复制架构 · MySQL 实战与高可用知识图谱 · 依据第 118 ~ 124 讲整理