主从复制+健康检查是MySQL高可用基础，需搭配MHA或Orchestrator实现秒级故障转移，强制开启GTID与半同步复制，部署至少3节点并配置中继备份节点，应用层须支持读写分离、降级与错误重试，定期演练验证RTO/RPO。
主从复制 + 健康检查是基础防线
单点故障最常见的情况就是只依赖一台 MySQL 实例。要破局，必须让服务具备“可切换”能力。主从复制（Master-Slave）是最常用的起点：写操作走主库，读操作可分担到从库，同时从库实时同步主库数据。但这还不够——如果主库宕机，没人自动接管写入，系统就卡住。所以必须搭配健康检查机制，比如用 Keepalived 或 Orchestrator 监控主库状态，一旦发现不可达，立即触发故障转移，把一个从库提升为主库，并更新应用连接配置（可通过 VIP 漂移或 DNS 切换实现）。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
优先选 MHA 或 Orchestrator 这类成熟故障转移工具
手写脚本做主从切换风险高、收敛慢、易出错。MHA（Master High Availability）能 10–30 秒内完成故障检测和提升，还能自动补全从库间 GTID 差异；Orchestrator 更现代，支持可视化、多集群管理、自动修复拓扑，且对 GTID 和半同步复制兼容更好。部署时注意：
- 主从必须开启 GTID，避免日志位点不一致导致切换失败
- 至少部署 3 个节点（1 主 2 从），其中 1 个从库建议设为 relay_log_purge=OFF 并启用 log_slave_updates，作为“中继备份节点”，提升容灾纵深
- 所有节点开启 半同步复制（semisync），确保主库提交前至少一个从库已写入 relay log，防止脑裂丢数据
别忽略应用层的适配与降级能力
再稳的数据库架构，也扛不住应用无脑重连旧地址。应用需支持：
- 连接池具备 自动重试 + 读写分离路由 能力（如 ShardingSphere、ProxySQL 或自研中间件）
- 故障期间允许短暂 读从库降级（即使主库不可用，部分业务仍可查历史数据）
- 写失败时有明确错误码识别（如 MySQL 错误 2003、2013），触发本地缓存暂存 + 异步回写，避免直接报错中断用户流程
- 避免长事务和大事务，它们会拖慢主从延迟，在切换窗口容易引发数据不一致
定期演练比堆配置更重要
高可用不是上线就一劳永逸。每季度至少做一次真实故障注入演练：
- 主动 kill -9 主库 mysqld 进程，观察切换耗时、从库提升是否正确、GTID 是否连续、应用是否自动恢复写入
- 模拟网络分区（如 iptables 拦截主从通信），验证半同步超时行为和仲裁逻辑
- 检查监控告警是否及时（如 Seconds_Behind_Master > 60s、IO/SQL 线程中断、复制错误码）
- 记录每次演练的 RTO（恢复时间目标）和 RPO（数据丢失量），持续优化参数和流程
