数据库单点是最大隐患

应用服务挂了可以靠多副本顶住，但数据库是整个系统里最难搞高可用的一环——它有状态，数据就一份，主库一旦挂了、或者磁盘坏了，整个系统读写全停。很多系统做了一堆负载均衡、多副本，却把数据库孤零零跑在一台机器上，等于前面都修好了，地基还塌着。

数据库高可用的基本思路是：搞一个主库写、多个从库同步复制，主库挂了把其中一个从库升成新主。这一篇就从这个思路讲起，一步步落到能跑的最小方案。

应用服务多副本是为了扛流量；数据库主从是为了扛故障，目的不一样。
本文核心知识点
  • 主从复制主库的变更自动同步到从库。
  • 读写分离读走从库、写走主库，分摊压力。
  • 故障切换主库挂了，把从库自动升成新主。
  • 脑裂两个主同时写，数据就乱了，必须避免。
数据库高可用与主从切换配图：左侧主数据库圆柱方块经同步箭头连到右侧从数据库圆柱方块、中间故障切换开关图标的蓝色扁平科技插画
主库和从库之间，就是这根同步管道和这个切换开关。

主从复制：数据怎么同步到从库

主从复制的原理说穿了很简单：主库把每一次数据变更记到日志里，从库盯着这份日志、把变更重演一遍。这样从库就有了和主库一样的数据（理论上）。

MySQL 主从复制的关键步骤：
1. 主库开启 binlog，记录所有写操作
2. 从库配好主库地址和复制账号
3. 从库拉取主库 binlog，在本地重演
4. 网络延迟决定了从库数据比主库"新到什么程度"

要记住一个现实：复制是异步的，从库数据会比主库稍微旧一点点。在网络正常时这个延迟通常毫秒级，但网络抖一下可能就几秒。这一点直接决定了下面读写分离能怎么做、不能怎么做。

读写分离：读流量分流到从库

大多数业务的特点是读多写少——一次写、可能读十次。主从搭好后，把读请求分流到从库，主库就只扛写，压力立刻小一大截。这就是读写分离：

读写分离的路由规则：
- 写请求（insert/update/delete）→ 走主库
- 读请求（select）→ 走从库
- 刚写完立刻要读的场景 → 仍走主库（不然读不到刚写的数据）

最后那条特别容易踩坑：用户刚下单、马上去看订单页，如果读的是从库，可能看到空的（复制还没同步过来）。所以「写完立刻读」的场景要特殊处理，让它读主库，别傻傻全分流。

故障切换：主库挂了怎么办

主库真的挂了（机器宕机、磁盘损坏），就得把一台从库升成新主。手动做一遍要好几分钟，业务停好几分钟——所以一般用自动故障切换工具盯着，主库一断自动把某个从库提上来：

自动切换的大致过程：
1. 健康检查发现主库连不上
2. 等一小段时间（确认不是网络抖动）
3. 选一个数据最新的从库
4. 把它提升为新主库
5. 让其他从库重新指向新主
6. 通知应用层切换连接

这套流程别自己从零写，用现成的高可用组件。它们已经把「选谁提升」「怎么防误切」这些坑趟过了。