先说个真事儿。去年有个做电商的朋友，半夜三点给我打电话，声音都在抖——他们的MySQL主库挂了，因为没做高可用，整个网站瘫痪了整整四个小时。等到天亮，老板发现丢了将近两个小时的订单数据，那叫一个惨。这事儿让我意识到，很多团队搞MySQL运维，往往只盯着SQL优化、索引调优这些技术活儿，却忽略了一个最根本的问题：系统挂了怎么办？今天我跟你聊聊，从零开始搭一套真正能扛事儿的MySQL高可用方案，核心要点有哪些。
高可用的前提，是得先搞清楚你的业务到底能容忍多少宕机时间。别一上来就整什么MGR、PXC这些高大上的方案，先问问自己：你接受数据丢几秒？能接受主从切换时服务中断多久？这个叫RPO和RTO。我见过最离谱的，是个日活不到一万的小站，非要上三节点强同步集群，结果运维成本比服务器还贵。实际上，对于大多数中小团队，一个成熟的主从复制加上半同步复制，RPO控制在秒级，RTO控制在分钟级，已经够用了。别为了追求理论上的99.999%可用性，把自己拖进坑里。
说到主从复制，很多人以为就是配个binlog、改个server-id就完事儿了。但真正坑人的地方在于：你怎么保证主库挂了之后，从库能无缝接替？这里面有几个硬伤。第一，主库的binlog格式必须用ROW，别图省事儿用STATEMENT，否则数据一致性分分钟出问题。第二，从库的relay log得定期清理，不然磁盘满了，主从复制会卡死。第三，也是最容易忽略的——主从复制的延迟监控。很多团队配了主从，却从来不关心延迟，等到主库挂了，从库还差几万条binlog没追上，切过去就是数据丢失。写个脚本每分钟检查SecondsBehindMaster，超过阈值就告警，这个动作比任何花哨的方案都实在。
再往上走一层，就是自动故障转移。手工切主库太慢了，等你登录服务器、查状态、改配置，用户早就骂娘了。目前主流方案是MHA或者Orchestrator。MHA老牌但稳定，Orchestrator更现代，可视化界面也友好。但不管用哪个，你得想清楚一件事：谁来仲裁？如果主库和从库之间的网络闪断了，但主库本身还活着，仲裁节点会不会误判？这个叫脑裂问题。解决办法是引入第三方仲裁节点，比如用Consul或者ZooKeeper来存主库的租约，只有租约过期了才允许切主。别小看这个细节，我见过太多人因为脑裂把两个库都搞成主库，数据全乱套了。
说到数据一致性，不得不提备份策略。高可用不代表不丢数据，哪怕你做了半同步复制，极端情况下主库宕机时一批事务还是可能没传过去。所以，必须有定期的全量备份和增量备份。全量备份建议用XtraBackup，物理备份速度快，恢复也方便。增量备份可以结合binlog，每天做一次增量。但真正关键的是恢复演练——你得真的在测试环境里跑一遍恢复流程，而不是只在文档里写“备份路径为/data/backup”。我见过一个团队，备份文件存了两年，结果恢复时发现备份文件早就损坏了，因为没人验证过。每周跑一次恢复测试，这个成本不能省。
监控告警是运维的最后一公里。很多人以为装了Prometheus+Grafana就完事了，但真正有用的告警不是看曲线漂不漂亮，而是能告诉你“现在该干啥”。比如，连接数飙升到80%了，你得知道是慢查询积压还是连接池泄漏；磁盘IO延迟超过50ms了，你得知道是索引碎片还是硬件老化。所以，监控指标要精不要多，核心就几个：QPS、TPS、连接数、慢查询数量、复制延迟、磁盘使用率、IO延迟。每个指标都要配上阈值和响应预案。别等报警了才翻文档，最好把常见问题的处理步骤写成自动化脚本，一键执行。
说个容易被忽视的点：架构的演进要跟业务匹配。刚起步时，一台主库加一台从库就够；日活到十万了，加个读写分离中间件，比如ProxySQL或者MyCat；再往上走，可能需要分库分表，用ShardingSphere或者Vitess。但别一开始就搞分布式，那玩意儿复杂度翻十倍。我的经验是，每做一次架构升级，都要先问自己：当前这个瓶颈，能不能通过优化SQL、加索引、换硬件解决？如果不行，再考虑架构改造。毕竟，一个稳定的单库，比一个天天出bug的分布式集群强多了。
说到底，MySQL高可用不是一套方案，而是一个持续迭代的过程。从主从复制到自动故障转移，从备份恢复到监控告警，每一步都踩过坑才能长记性。别指望一次搞定所有问题，也别因为觉得麻烦就放弃。你的数据库，就是你业务的命根子。把这套东西搭起来，至少下次半夜三点，你能安心睡觉，而不是像开头那位朋友一样，对着瘫痪的系统欲哭无泪。
