标准答案
- 写请求通常进入主库，副本通过日志回放复制变更；复制是否同步、确认到什么程度决定延迟与故障时的数据风险。
- 刚写成功后马上从副本读取，可能因复制尚未追上而读不到自己的写入，应在关键链路回主库、使用会话黏性或等待复制位点。
- 读写分离路由要识别事务、锁定读、强一致读和后台报表，不能把所有 SELECT 无差别分到副本。
- 故障切换需要确认新主库的数据进度、禁止旧主继续写入、刷新连接与路由，并验证未确认事务的处理语义。
- 副本不是备份，误删、逻辑错误和异常写入通常会被正常复制，需要独立备份与恢复方案。
题目解析
读写分离解决的是读扩展，不是免费的一致性。用户刚创建订单、刚更新权限或刚完成支付时，如果页面立刻从落后的副本读取，会造成“写成功但页面显示失败”的体验和后续重复操作。
切换流程的难点在数据和流量边界。若旧主在网络隔离后仍接受写入，就可能出现双主；若新主落后，则需要明确可接受的 RPO、补偿手段和用户可见状态。
常见误区
- 把所有只读 SQL 都路由到副本，导致事务内读、权限校验和刚写后查询出现不一致。
- 把副本当备份，发生误操作后才发现所有副本都已同步错误。