主从复制如何提升高可用？同步、异步、半同步复制有什么区别？

简化版

主从复制通过把主节点数据复制到从节点，让从节点在主节点故障时接管服务，也能承担部分读流量。异步复制性能好但可能丢数据，同步复制一致性强但延迟高，半同步复制在性能和数据安全之间折中。

详细版

三种复制方式区别：

方式	写入返回时机	优点	风险
异步复制	主库写完本地就返回	延迟低、吞吐高	主库宕机可能丢未复制数据
同步复制	多个副本都确认后返回	数据安全性强	写延迟高，副本慢会拖主库
半同步复制	至少一个从库确认收到后返回	降低丢数据概率	仍可能有窗口，性能有损耗

主从复制提升高可用的前提是：从库延迟可监控，故障时能安全提升从库，应用路由能切换，并且旧主恢复后不会形成双主。只搭主从不等于自动高可用，还需要故障检测、选主、切流和恢复流程。

完整版教学

一、主从复制解决了“主节点坏了怎么办”

单主数据库如果没有副本，主库故障后只能从备份恢复，恢复时间可能很长。主从复制把主库的变更持续同步到从库，让从库成为候选接班人。主库故障时，可以把某个从库提升为新主，缩短恢复时间。

复制还可以用于读扩展。主库负责写，从库承接报表、查询、备份等读流量。但读写分离不是高可用的全部，从库能读不代表它能随时安全接管写入。

二、异步复制性能最好，但有数据丢失窗口

异步复制中，主库提交事务后就返回客户端，然后再把日志传给从库。如果主库刚提交成功，还没来得及把日志发给从库就宕机，这部分数据在从库上不存在。切到从库后，客户端认为写成功的数据可能丢失。

这个风险就是 RPO 问题。异步复制的 RPO 不一定为 0，它取决于复制延迟和故障时未同步的数据量。互联网系统里很多业务可以接受极小概率的数据延迟或通过补偿修复，所以异步复制仍然非常常见。

三、同步复制更安全，但会牺牲性能和可用性

同步复制要求多个副本确认后，主库才向客户端返回成功。它能显著降低已提交数据丢失风险，但每次写入都要等待网络和从库响应。只要从库慢，主库写入也会变慢。

如果同步副本不可用，系统可能无法继续写入。也就是说，一致性更强时，可用性和性能会承受压力。这也是 CAP 和一致性权衡在数据库复制里的体现。

四、半同步复制是常见折中

半同步复制通常要求至少一个从库确认收到日志后，主库才返回成功。它比异步更安全，因为至少有一个副本拿到了数据；又比全同步成本低，因为不要求所有副本都完成应用。

但半同步不是绝对零丢失。不同实现里，“收到日志”和“应用完成”可能不是一回事；网络超时后也可能退化为异步；从库确认后如果新主选择不当，仍可能有一致性风险。因此半同步要配合选主规则和日志位点判断。

五、复制延迟会影响读写分离和故障切换

主从复制常见问题是复制延迟。用户刚写完订单，下一秒从库查询可能查不到。这会造成读己之写不一致。解决办法包括关键读走主库、按用户会话短时间读主、使用 GTID/位点等待、或者业务上接受短暂延迟。

故障切换时也要看延迟。延迟越大，提升从库后的数据缺口越大。监控中应持续关注从库延迟、复制线程状态、日志位点和主从一致性校验。

六、主从复制下的读一致性要单独设计

主从复制常和读写分离一起出现，但读写分离会引入读一致性问题。用户刚提交订单，写入主库成功，马上跳到订单列表，如果列表读从库，而从库复制延迟，用户会看到订单不存在。这类问题叫读己之写不一致。

解决方式有多种。关键链路写后短时间读主库；在会话中记录最近写入时间，一段时间内强制读主；使用 GTID 或日志位点等待从库追上；对允许延迟的数据直接提示处理中。不同方案成本不同，不能一概而论。

读从库还要防止从库被慢查询打垮。报表查询、导出任务最好使用专门只读副本或分析库，不要和在线读共享同一组从库。否则主库没挂，从库被后台任务拖慢，用户查询同样不可用。

七、复制拓扑和故障恢复要考虑旧主回归

主从架构故障切换后，旧主恢复是一个容易被忽略的阶段。旧主可能缺少新主上的数据，也可能曾经接受过部分写入。如果直接让旧主重新作为主或从加入，可能造成数据冲突。正确做法是先隔离旧主，确认它的日志位点和新主差异，再选择重放、回滚、重建或人工修复。

复制拓扑也会影响高可用。单主多从简单，但主故障时要选从；级联复制可以降低主库复制压力，但中间节点故障会影响下游；多主复制写冲突复杂，不适合所有场景。数据库高可用不仅是复制参数，还包括拓扑、选主、路由、权限和恢复流程。

面试回答主从复制时，最好补一句：主从解决的是副本和接管能力，但不自动等于强一致。异步复制有 RPO，半同步降低风险，同步复制提高安全但增加延迟。复制延迟监控和故障演练是生产可用的关键。

八、常见误区与追问

这道题要紧扣「主从复制」本身回答，不能把它混成泛泛的高可用套话。面试官通常不是只听定义，而是看你能不能把适用场景、关键流程、失败边界和工程取舍串起来，尤其要说明故障域、冗余、健康检查、切换流程、RPO/RTO 和演练结果。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	主从复制用主节点承接写入、从节点复制数据提供备份或读扩展，核心关注复制延迟、切换和一致性	不要停在名词解释
流程机制	主库接收写入 -> 记录复制日志 -> 从库拉取或接收日志 -> 回放生成副本 -> 监控复制延迟 -> 故障时提升从库	要说清触发点、状态变化、确认点和失败兜底
工程取舍	主库写入后 200ms 才复制到从库，立刻读从可能读到旧值，这就是主从延迟	高可用不是永不故障，而是用冗余、隔离、自动切换和演练降低故障影响

主从复制 面试拆解：
1. 主库接收写入
2. 记录复制日志
3. 从库拉取或接收日志
4. 回放生成副本
5. 监控复制延迟
6. 故障时提升从库

记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「主从复制」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。

• 误区：主从复制等于强一致。 异步复制常有延迟，读从可能读到旧数据。
• 误区：从库只用于备份。 从库也可读扩展、报表隔离，但要考虑延迟。
• 误区：主挂了从库自动无损接管。 是否自动、是否丢数据取决于复制模式和选主机制。
• 追问：如何处理读写一致？ 写后读主、延迟监控、半同步复制或会话一致性。
• 追问：主从延迟来源？ 网络、日志传输、从库回放速度、长事务和大 SQL。
• 追问：切主风险是什么？ 旧主未下线可能双写，新主缺日志可能丢数据。

九、加强记忆

主从复制提升高可用靠的是“主挂了有从可接”，但复制方式决定数据安全边界：异步快但可能丢， 同步稳但慢，半同步折中但不是万能。真正可靠的主从高可用还必须包含延迟监控、选主规则、路由切换和旧主隔离。