MySQL高可用通过数据冗余、自动切换和集群实现。主从复制支持读写分离与半同步减少数据丢失，MHA或Orchestrator实现30秒内自动故障转移，InnoDB Cluster基于Group Replication提供多节点强一致，配合MySQL Router路由请求。使用Keepalived+VIP实现IP漂移，ProxySQL或HAProxy负载均衡，结合监控系统及时告警。方案选择取决于一致性、延迟与复杂度需求，核心是数据不丢、故障快切、运维可控。
MySQL 保证高可用性主要依赖于数据冗余、故障自动切换和集群架构。核心目标是在主节点宕机时，系统能快速恢复服务，避免数据丢失和服务中断。
主从复制（Replication）
这是最基础的高可用手段。通过将一个 MySQL 实例（主库）的数据异步或半同步复制到多个从库，实现数据冗余。
- 主库负责写操作，从库可承担读请求，实现读写分离。
- 当主库故障，可通过手动或工具切换到从库继续提供服务。
- 使用 半同步复制 可减少数据丢失风险，确保至少一个从库接收到事务日志。
高可用架构：MHA 或 Orchestrator
主从结构本身不具备自动故障转移能力，需要借助管理工具实现自动化。
- MHA（Master High Availability） 能在 30 秒内完成主库故障检测与切换，提升系统响应速度。
- Orchestrator 提供更灵活的拓扑管理、自动切换、主从修复等功能，支持复杂的复制结构。
- 这些工具会自动选择最新的从库提升为主库，并重新配置其他从库指向新主库。
使用 InnoDB Cluster（基于 Group Replication）
MySQL 官方提供的高可用解决方案，整合了 Group Replication、MySQL Shell 和 MySQL Router。
- Group Replication 使用 Paxos 协议保证多节点间数据一致性，支持多主或单主模式。
- 任意节点宕机不影响整体服务，写操作在多数节点确认后提交。
- MySQL Router 自动路由应用请求到当前主节点，实现透明访问。
配合负载均衡与故障检测
高可用不仅靠数据库层，还需外围组件支持。
- 使用 Keepalived + VIP 实现虚拟 IP 漂移，避免客户端修改连接地址。
- 部署 ProxySQL 或 HAProxy 作为中间件，监控后端节点状态并动态调整流量。
- 结合监控系统（如 Prometheus + Grafana）及时告警，辅助运维决策。
基本上就这些。选择哪种方案取决于业务对一致性、延迟和复杂度的要求。小规模系统可用主从+MHA，中大型建议用 InnoDB Cluster 或 Orchestrator 管理的复制组。关键点是：数据不丢、故障快切、运维可控。
