1. 主从复制 + 手动 / 自动切换（最基础）
- 原理：一台主库负责写入，多台从库负责读取 / 备份，主库挂了，从库顶上。
- 高可用方式：
- 手动切换：运维人员手动改配置、切流量
- 自动切换：用工具接管（比如 MHA）
- 举例：主库在上海，从库在杭州，主库断电，工具自动把杭州从库升为主库，业务无感。
- 优点：简单、成本低、所有 MySQL 版本都支持
- 缺点：纯主从没有自动故障感知，必须搭配工具
2. MHA（经典自动切换方案）
- 企业最常用的轻量高可用方案
- 功能：自动检测主库故障 → 自动选最优从库 → 自动切换 → 自动修复复制关系
- 举例：主库宕机 30 秒内完成切换，业务只短暂卡顿，无需人工操作
- 优点：切换快、稳定、不侵入 MySQL、适配所有版本
- 缺点：无法做到绝对零数据丢失（极端场景丢极少量）
3. MySQL InnoDB Cluster（官方原生高可用）
- MySQL 官方推出的集群方案，自带高可用
- 原理：多节点同步数据，自动选举主节点，故障自动剔除
- 举例：3 台服务器组成集群，任意一台挂掉，剩下两台继续提供服务
- 优点：官方支持、稳定、配置简单、数据强一致
- 缺点：只支持新版 MySQL，对服务器数量有要求
4. Galera Cluster（多主高可用）
- 特点：所有节点都能读写，没有主从之分
- 优势：任意节点挂了都不影响写入，切换无感知
- 举例：4 节点集群，坏 2 台依然正常运行，业务不用改连接地址
- 缺点：对网络质量要求高，写入性能略低
5. 主从 + VIP + 代理层（企业级标准架构）
- 最稳定、最通用的生产架构
- 结构：主从复制 → 自动切换工具 → VIP（虚拟 IP）/ 代理 → 业务
- 举例：业务只连一个虚拟地址，主库挂了，地址自动飘到新主库，代码完全不用改
- 代理常用：HAProxy、MaxScale
- 优点：业务无感知、高可用最彻底、可搭配读写分离
-
数据一致性
- 异步复制：性能好，可能丢数据
- 半同步复制：性能适中，基本不丢数据（企业首选）
- 强一致：完全不丢数据，性能稍降
-
故障自动切换高可用≠双机热备，必须满足：
- 自动检测故障
- 自动选举新主库
- 自动切换流量
- 自动修复复制
-
读写分离高可用常搭配读写分离：主库写、从库读，提升性能同时提高可用性。
-
小公司 / 简单业务：主从 + MHA
-
中大型企业 / 金融 / 支付：半同步复制 + MHA + 代理 + VIP
-
追求官方稳定：InnoDB Cluster
-
必须多节点同时写入：Galera
-
高可用不能替代备份：删库、误操作，高可用救不了，必须定期备份
-
网络差的环境，不要用强一致集群
-
切换必须测试：不演练的高可用，故障时一定会出问题
总结
- MySQL 高可用核心：主从复制 + 自动切换 + 流量统一入口
- 最实用组合：半同步主从 + MHA 自动切换 + 代理层
- 最终效果：单节点故障 → 秒级 / 数十秒切换 → 业务无感 → 数据安全