SQL 高可用架构的核心目标

SQL高可用架构核心是缩短故障时业务不可用时间并保障数据不丢失；需应对主从延迟、选主失败、脑裂、RPO/RTO不达标等关键问题，强调可测量、可验证、可回滚。

SQL 高可用架构的核心目标不是“永不宕机”，而是**在故障发生时，尽可能缩短业务不可用时间，并保证数据不丢失或最多丢失极小窗口内的数据**。

主从同步延迟导致查询结果不一致

常见于读写分离场景：应用从 slave 读取刚写入 master 的数据，却查不到。这不是 bug，而是异步复制的固

有行为。

• MySQL 默认是异步复制，binlog 写完就返回成功，不等从库回放
• 可改用半同步（rpl_semi_sync_master_enabled=ON），但会增加写入延迟
• 更稳妥的做法是：对强一致性读，强制走 master；或使用 SELECT ... FOR UPDATE 触发事务级读主逻辑
• 监控必须包含 Seconds_Behind_Master，超过阈值应自动剔除该从库

主库单点故障后选主失败或脑裂

当 master 崩溃，高可用组件（如 MHA、Orchestrator、Patroni）需在秒级内完成探测、选主、切换、VIP/域名重绑定。失败常因配置不当或网络分区。

• 选主策略要明确：优先级（candidate_master=1）、权重、GTID 位置比对，避免低延迟但从落后太多节点被误选
• 必须启用 read_only=ON 在所有非主节点，防止脑裂时写入分裂
• 切换后需验证：新主的 server_uuid 是否已更新到应用连接池、DNS 缓存是否过期、从库是否重新指向新主
• 不要依赖心跳超时单一判断——建议结合进程存活、端口响应、SQL 线程状态三重检测

备份与恢复无法满足 RPO/RTO 要求

RPO（恢复点目标）和 RTO（恢复时间目标）是高可用架构的硬约束。只靠每天一次 mysqldump 备份，RPO 可能达 24 小时，完全不满足生产要求。

• 物理备份（xtrabackup）+ 持续 binlog 归档是标配，RPO 可压至秒级
• binlog 必须开启 sync_binlog=1 和 innodb_flush_log_at_trx_commit=1，否则崩溃可能丢事务
• 恢复演练不能只跑通命令：要测全量恢复 + binlog 回放到指定 GTID 的耗时，记录真实 RTO
• 备份集本身要定期校验（xtrabackup --verify），否则恢复时才发现损坏就晚了

真正难的不是部署几个组件，而是让每个环节都可测量、可验证、可回滚。比如一次主从切换后，没人检查应用连接池是否还在往旧 IP 发请求；又比如 binlog 归档路径磁盘满了，归档脚本静默失败，连续三天没新 binlog，RPO 实际已退化为 0。