复制与高可用

用途：设计读写分离、评估主从延迟与故障切换影响

复制原理

主库 binlog → 从库 IO 线程写入 relay log → SQL 线程重放

模式	语义	影响
异步复制（默认）	主库提交不等从库	性能最好，故障切换可能丢数据
半同步	至少一个从库确认收到日志后主库才提交	减少丢失窗口；确认“收到”不等于“执行完”
组复制 / Paxos 类（MGR、PolarDB-X 等）	多数派确认	更强一致与自动选主，运维复杂度高

binlog 格式：ROW（记录行变更，安全且可恢复，体积大）、STATEMENT（可能不确定，如 NOW()、UUID()）、MIXED。使用 RR 之外隔离级别或非确定函数时，ROW 是必须的（也是 RC 方案的前提）。

主从延迟

成因	对策
从库单线程重放大事务	并行复制（基于组提交/binlog_transaction_dependency_tracking）
从库配置低于主库（缓冲池、IO）	对齐规格
从库承担过多读流量	拆分只读实例、按标签路由
大表 DDL、批量更新	分批、online DDL、错峰
网络抖动	就近部署、检查带宽

延迟监控：SHOW REPLICA STATUS 的 Seconds_Behind_Source（注意它是“秒级差”而非真实积压量，配合队列指标看）。

读写分离的正确性问题

1. 写后读不到：写走主、读走从，延迟窗口内读到旧值。对策：写后短时间内强制读主（会话粘性）、或业务侧“我刚刚提交的数据”用主库读。
2. 分页跨库不一致：同一请求多次读从库可能落在不同副本。对策：会话内固定同一从库。
3. 事务内读：必须在主库（或至少同一连接）。
4. 级联复制：从库再下挂从库会放大延迟，需评估拓扑。

高可用与故障切换

组件	职责
探活	主库健康判定（避免误判导致脑裂）
选主	数据最全优先，其次固定优先级
VIP/DNS/代理切换	让应用指向新主
fencing	隔离旧主，防止双写
半同步/多数派	控制丢数据窗口

运维要点：切换必须演练；应用要有连接失败快速重试与只读降级；备份与 binlog 归档是最后防线（PITR 恢复能力）。

备份与恢复

• 逻辑备份：mysqldump / mydumper（小库、跨版本迁移）。
• 物理备份：Percona XtraBackup（大库、配合 binlog 做 PITR）。
• 恢复演练：定期真实恢复，验证备份可用性；备份不演练等于没有备份。

常见误区

误区	修正
半同步=不丢数据	只保证日志被从库接收，仍需关注确认策略与切换流程
用 Seconds_Behind_Source 判断一切延迟	该指标在积压场景下会失真
所有读都打到从库	报表与批量扫描会拖垮从库并放大延迟
忽视 DNS 缓存	切换后应用仍连旧主，需短 TTL 或代理层
备份只有一份	3-2-1 原则：多副本、异介质、异地

延伸阅读

• MySQL 官方文档：Replication、Group Replication、Backup and Recovery
• Percona 博客与《MySQL High Availability》