适用场景

读写分离能显著提升读能力，但代价是"可能读到旧数据"。哪些场景能接受延迟、哪些必须走主库，要提前定清楚。

配置步骤（延迟监控与摘除）

# 1) 采集：SHOW SLAVE STATUS 的 Seconds_Behind_Master
# 2) 阈值：>5 秒告警，>30 秒自动摘除（按业务容忍度）
# 3) 恢复：延迟归零后自动加回，观察再纳入流量
# 4) 报表：每日最大延迟与次数

关键参数与建议

  • 实现方式：应用层路由、中间件（代理）、驱动层（如 ShardingSphere）
  • 强一致读：写后立即查询、支付与库存类必须走主库
  • 延迟监控：主从延迟超阈值时自动摘除从库
  • 故障切换：从库故障透明摘除，主库故障走高可用流程
  • 压测验证：读流量分摊是否生效、延迟是否可控

容易踩的坑

  • 不监控延迟，业务读到旧数据才发现
  • 摘除阈值过严，从库频繁被摘导致主库压力
  • 摘除后无告警，读能力长期只有一半

验证与巡检

SHOW SLAVE STATUS\G | grep -i seconds_behind
  • 巡检：延迟报表、摘除/恢复记录

小结

读写分离的验收：读 QPS 显著分担、延迟可控、切换演练通过、没有业务"读到旧数据"投诉。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。