主从复制与高可用
1. 这是什么
主从复制用于把主库的数据变更同步到从库。
高可用则关注数据库节点故障时系统如何保持服务能力。
一句话理解：
- 主从复制解决的是“数据怎么从主库同步出去”
- 高可用解决的是“主库或节点出问题时怎么办”
2. 为什么重要
数据库往往是系统最关键的状态中心。
如果不理解复制和高可用，系统在这些场景下会很被动：
- 扩展读能力
- 数据容灾
- 节点故障恢复
- 故障切换
3. 先建立直觉：有从库不等于天然高可用
这是学习这章最重要的一条直觉。
很多人会以为：
- 有主从复制
- 就已经高可用了
其实不是。
复制只说明：
- 数据在同步
但高可用还要额外解决：
- 节点故障检测
- 角色切换
- 业务接入切换
- 延迟一致性问题
4. 核心内容
4.1 Binlog
MySQL 主从复制最核心的基础之一是：
- Binlog
你可以先把它理解成：
- 主库上的变更日志
从库正是基于这些变更日志去追赶主库状态。
4.2 主从复制基本流程
学习阶段先记这条主线就够用：
- 主库写入数据并记录 binlog
- 从库拉取主库日志
- 从库重放日志
- 从库数据逐步追平主库
所以复制不是“瞬时魔法同步”，而是一个：
- 拉取 + 重放 + 追平
的过程。
4.3 读写分离
主从复制很常见的落地方向是：
- 主库负责写
- 从库负责读
它的价值在于：
- 分担读压力
但它也带来新的问题：
- 主从延迟
- 读到旧数据
4.4 复制延迟
复制延迟是主从架构里非常关键的问题。
典型现象是：
- 数据已经写入主库
- 但从库还没追上
- 结果读请求读到了旧值
这对这些场景尤其敏感：
- 写后立刻读
- 强一致查询
- 状态流转类业务
4.5 故障切换
高可用体系里最关键的问题之一就是：
- 主库挂了以后，谁接替它
这通常涉及：
- 主从角色切换
- 服务发现或连接配置切换
- 业务恢复过程
4.6 高可用方案基本思路
学习阶段先抓住概念主线即可：
- 复制提供数据同步能力
- 监控和选主机制提供切换依据
- 接入层切换保证业务流量继续可达
5. 学习重点
这一章最重要的是掌握：
- 主从复制依赖 binlog 等日志机制
- 复制的主要目标是扩展读能力和容灾
- 读写分离会带来一致性风险
- 高可用一定伴随切换成本和管理复杂度
- 有复制不等于真正高可用
6. 常见问题
6.1 读写分离后忽略主从延迟
这会让业务在“写后马上读”场景下出现诡异问题。
6.2 只关注吞吐，不关注故障恢复
这会让系统平时看起来很强，一出故障就很脆。
6.3 认为有从库就天然高可用
复制和高可用不是同一件事。
7. 动手验证
当前环境没有 mysql 客户端，也没有可直接操作的主从集群，所以这一节改成“架构验证步骤 + 观察点”。
7.1 复制链路验证思路
如果你在真实 MySQL 环境中做实验，建议重点观察：
sql
SHOW MASTER STATUS;
SHOW REPLICA STATUS\G或旧版本兼容命令：
sql
SHOW SLAVE STATUS\G重点看：
- 当前主库 binlog 位点
- 从库复制线程状态
- 延迟时间
7.2 读写分离一致性演练
你可以设计一个最小场景：
- 向主库插入一条新记录
- 立刻从从库查询
- 观察是否立即可见
这个实验很适合理解：
- 主从延迟为什么会变成业务问题
7.3 高可用思考题
可以把自己代入生产环境问三个问题：
- 主库挂了以后，谁来发现？
- 发现后，谁来切换角色？
- 切换后，应用连接怎么更新？
这三个问题答不完整，就说明“复制”和“高可用”还没有真正连起来。
8. 练习建议
- 画出主从复制流程图
- 思考一个读写分离场景下的一致性风险
- 总结常见数据库高可用方案差异
- 用自己的话解释“为什么有从库不等于高可用”
9. 自测问题
- MySQL 主从复制依赖什么日志机制？
- 主从延迟会带来什么业务问题？
- 为什么“有复制”不等于“高可用”？
- 读写分离为什么会引入一致性风险？
10. 自测核对要点
- Binlog 是主从复制的重要基础
- 主从复制主要解决扩展读能力和容灾问题
- 主从延迟会直接影响业务一致性体验
- 高可用必须包含故障检测、切换和接入恢复能力