在 MySQL 架构中，有哪些常用策略可以消除或降低单点故障带来的风险？请说明各自的适用场景和不足。

回答思路

1. 【回答框架 1】单点故障指系统某组件失效导致整体不可用，MySQL 中常见于单实例部署。核心思路是引入冗余与自动切换，常见方案包括主从复制、半同步复制、集群方案（如 MHA、Orchestrator、Group Replication）以及共享存储方案（如 SAN/DRBD）等。
2. 【回答框架 2】主从复制是最基础的方案，通过 binlog 将主库变更同步到从库，备库提供只读能力或用于故障切换。但普通异步复制在主库故障时可能丢失已提交事务，需结合半同步复制或 GTID 提升一致性。半同步复制保证至少一个从库收到 binlog，但会引入额外延迟，在高并发下可能影响吞吐。
3. 【回答框架 3】高可用管理工具（如 MHA、Orchestrator）基于主从复制实现自动故障检测与切换，通常秒级完成，但依赖于从库数据的完整性，且切换后需处理应用连接重路由。Group Replication 或 InnoDB Cluster 提供基于 Paxos 的组复制，保证数据强一致，但性能开销较大，更适合对一致性要求高的场景。
4. 【回答框架 4】共享存储方案（如 SAN、DRBD）让多个节点访问同一份数据，切换后数据不丢失，但存储本身可能成为新单点，且需考虑脑裂问题。无论采用哪种方案，都要结合应用层连接池、读写分离和监控告警，才能形成完整的高可用体系。
5. 【回答框架 5】实际方案选择需综合考虑 RPO（最多丢失多少数据）、RTO（恢复时间目标）、成本与运维复杂度。例如金融系统可能选强一致方案，互联网高并发场景更看重可用性和扩展性。建议通过压测验证切换时间，并定期演练故障切换流程。
6. 【关键点 1】主从复制是基础，但异步复制有数据丢失风险，半同步可降低该风险但增加延迟
7. 【关键点 2】MHA/Orchestrator 等工具实现自动故障切换，但依赖数据同步状态，切换可能丢失事务
8. 【关键点 3】Group Replication/InnoDB Cluster 提供强一致复制，但性能开销较大
9. 【关键点 4】共享存储可避免数据丢失，但存储本身可能成新单点，且需防脑裂
10. 【关键点 5】高可用方案需配套监控、告警、连接重试与定期演练，才能保障 RTO 与 RPO
11. 【易错点 1】错误认为主从复制能保证不丢数据，实际异步复制在故障时必然丢失已提交但未同步的事务
12. 【易错点 2】盲目追求强一致性而忽视性能损耗，或相反只选异步复制导致数据不一致
13. 【易错点 3】忽略脑裂问题，如网络分区时多个节点同时认为自己是主库，需借助仲裁或 quorum 机制避免