MySQL 复制与高可用架构：从主从复制到故障切换

MySQL 复制是生产架构的基础能力。它可以提供读扩展、故障恢复、备份副本和数据分发。但复制不是强一致魔法，也不是完整容灾方案。主从延迟、复制中断、误切主、双写冲突和应用读旧数据，都是常见事故来源。

高可用设计的目标是：主库故障时能安全切换，业务知道该连谁，数据丢失风险可控，切换过程可观测、可演练。

binlog 复制

MySQL 复制基于 binlog。主库记录数据变更，从库拉取并重放。binlog 格式常见有 statement、row、mixed。生产更常用 row 格式，因为它记录行级变更，确定性更好。

要关注：

• binlog 是否开启。
• server_id 是否唯一。
• binlog 保留周期。
• GTID 是否启用。
• 从库复制线程状态。
• 主从延迟。

GTID 能简化故障切换和复制拓扑调整，生产环境通常建议启用。

异步与半同步

默认异步复制下，主库提交事务后不等待从库确认。如果主库突然宕机，最新事务可能尚未复制到从库，切换后产生数据丢失。

半同步复制要求至少一个从库确认收到事务日志后，主库才向客户端返回成功。它能降低数据丢失风险，但会增加提交延迟，并依赖从库和网络状态。

半同步不是绝对零丢失。还要看配置、超时降级和故障时日志是否真正应用。

主从延迟

主从延迟会影响读写分离。用户刚写入订单，马上从从库读取，可能读不到。解决方案包括：

• 写后读主。
• 按业务关键性选择读源。
• 监控延迟，延迟过高时摘除从库。
• 使用 GTID 或位点等待。
• 对强一致接口禁用从库读。

不要为了分摊读压力，把所有查询都路由到从库。读旧数据可能比慢一点更糟糕。

读写分离

读写分离需要应用、代理或中间件配合。常见方案包括 ProxySQL、MySQL Router、云数据库代理或应用内路由。

需要明确：

• 哪些查询必须读主。
• 哪些查询允许读从。
• 从库延迟阈值。
• 事务内读写是否固定主库。
• 故障切换后连接如何刷新。

读写分离不是简单把 SELECT 发到从库。事务、会话变量、临时表、锁读都可能影响路由。

故障切换

故障切换要避免两个风险：选错新主和脑裂。自动切换工具要确认旧主不可写，选择数据最新的候选从库，并让其他从库重新指向新主。

切换流程通常包括：

1. 检测主库故障。
2. 确认故障不是网络抖动。
3. 选择最优从库提升为主。
4. 重建复制拓扑。
5. 更新应用连接入口。
6. 验证读写。
7. 记录审计和通知。

自动化越强，越要重视防脑裂机制。

备份副本

从库常用于备份，但备份不应影响在线读。从库备份时可能增加 IO 和延迟，建议使用专门备份从库，或使用存储快照和物理备份工具。

复制不是备份。误删数据会复制到所有从库，仍然需要独立备份和时间点恢复。

监控指标

生产复制至少监控：

• Seconds_Behind_Master 或等价延迟指标。
• IO/SQL 线程状态。
• relay log 增长。
• GTID 集合差异。
• 半同步状态。
• 主从切换次数。
• 复制错误。

延迟告警要按业务分级。备份从库延迟可以容忍更高，读流量从库延迟必须严格控制。

总结

MySQL 高可用不是搭一个主从就结束。复制延迟、一致性、读写路由、切换流程和备份恢复都要一起设计。可靠的数据库高可用来自持续演练和清晰边界：哪些数据可能丢、多久能恢复、谁负责切换、应用如何感知。