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。
