一、单机数据库的风险有多大
很多业务系统的数据库只有一台服务器：磁盘坏了、内存报错、机房断电，业务就直接停摆。更麻烦的是，如果连备份都不完整，损失就不只是停机时间，而是数据本身。
数据库高可用的核心目标有两个：数据不丢和停机时间可控。这两个目标决定了后面所有方案的选择。
二、主从复制解决什么问题
MySQL 主从复制的基本原理是：主库把数据变更写进 binlog，从库拉取并重放，从而保持数据同步。它一次解决了三个问题：
- 数据冗余：从库是主库的实时副本，主库故障时可顶上；
- 读扩展：把查询压力分流到从库，主库专注写入；
- 备份窗口：在从库上做备份，不影响主库性能。
但主从复制本身不等于高可用——它只保证数据同步，不负责自动切换。主库挂了之后谁来接管，需要额外的组件。
三、常见的复制模式
- 异步复制：主库写完即返回，性能最好，但主库崩溃时可能丢最后一段事务；
- 半同步复制：至少一个从库确认收到后才返回，兼顾性能与安全，是生产环境常用选择；
- 全同步复制：所有从库确认才返回，安全性最高，但延迟明显；
- 多源复制：一个从库接收多个主库的数据，适合数据汇聚场景。
大多数业务选择半同步复制，在对数据一致性要求极高的场景才考虑全同步。
另外要注意复制账号的权限控制：只授予复制所需的最小权限，并限制来源 IP，避免复制通道成为新的攻击面。同时把主从状态纳入监控，对 IO 线程与 SQL 线程的中断及时告警。
四、从库的硬件怎么配
从库不是"配角"，配置过低会拖垮整个架构：
- CPU 与内存不低于主库：从库要重放 binlog，还要承担读查询，配置低会导致复制延迟持续扩大；
- 磁盘性能要接近主库：从库的写入模式与主库相似，慢盘会直接表现为延迟；
- 内存留足缓冲池：缓冲池太小会导致从库重放时频繁读盘；
- 网络要稳：主从之间的网络抖动会直接造成复制中断。
具体的硬件档位可参考数据库服务器硬件指南与数据库服务器配置推荐。
五、高可用方案怎么选
主从之上的自动切换方案，主流有三种：
- MHA：成熟稳定，能在主库故障时自动提升从库，但需要额外管理节点，且存在脑裂风险需要配合处理；
- MGR（组复制）：MySQL 官方方案，基于 Paxos 协议，一致性强，但对网络延迟敏感，配置门槛较高；
- 云托管高可用：由云厂商负责切换，运维成本最低，但数据在第三方、可控性较弱。
自建机房且要求数据完全自控的场景，MHA 与 MGR 更合适；如果业务对停机时间极度敏感且团队运维力量有限，可以评估托管方案。
六、读写分离与主从延迟
读写分离能显著提升读能力，但会引入一个经典问题：主从延迟。刚写入的数据马上从从库读，可能读不到，用户会看到"提交成功但数据没变"的诡异现象。
处理思路有三条：一是对一致性要求高的读强制走主库；二是用半同步复制压缩延迟窗口；三是监控 Seconds_Behind_Master 并设置告警。磁盘层面的 IO 瓶颈排查可参考磁盘 IO 诊断。
七、切换与演练
高可用方案最怕"配置了但没演练"。真正发生故障时，切换脚本报错、账号权限缺失、应用连接串没改，都是常见问题。建议：
- 每季度至少做一次主动切换演练，验证流程可用；
- 把切换步骤写成文档，避免依赖个人记忆；
- 应用侧配置连接重试与超时，减少切换瞬间的报错；
- 切换前后做数据一致性校验。
备份策略方面，注意快照不能替代备份，两者区别可参考快照和备份的区别；备份系统的搭建可参考企业级备份服务器配置。
八、结语
MySQL 高可用的路径是清晰的：先做主从复制解决数据冗余，再叠加切换方案解决停机时间，最后用演练验证整套流程真的能用。从库配置不能缩水，否则延迟会成为新瓶颈。今朝恒业可提供数据库服务器与存储的选型配置、报价与交付服务。
延伸阅读推荐：
