读写分离落地前，监控指标要是没定好，上线后出了问题连根都查不到，核心结论：先定延迟、一致性、流量分配三类监控基线，再动手改架构，否则一切优化都是盲人摸象。
读写分离方案选型对比，监控粒度差在哪
做读写分离，第一步不是买机器，而是想清楚用哪种方案，不同方案的监控口径完全不一样，换方案等于换一套监控逻辑，先搞清这个,后面才不至于手忙脚乱。
自建MySQL主从的监控死角
自己搭主从，自由度最高，但监控压力全在自己身上，用SHOW SLAVE STATUS能看到Seconds_Behind_Master，这个值代表SQL线程回放主库binlog的落后秒数，但行业共识认为，这个值只有参考价值，很多场景下它压根不更新，比如从库长时间没有写入流量时，这个值会定格在0，看起来一切正常,实际上网络早就断了。
- 必须额外盯binlog拉取状态，看IO线程是否在跑
- relay log有没有堆积，靠
SHOW PROCESSLIST观察SQL线程卡在哪个GTID - 半同步复制开了没有，若主库崩溃，半同步能决定丢不丢数据
Proxy中间件的监控汇总能力
用ProxySQL或ShardingSphere这类中间件，读写流量在代理层就有了统一出入口，ProxySQL自带stats库，能查到路由到每个从库的实际查询次数、连接池占用情况。
mysql_connection_pool里的连接数，判断从库连接是否打满mysql_query_rules命中次数，验证读写分离规则是否真正生效- 统计结果可以直接拉出来做成Grafana面板
云RDS只读实例的监控现成与否
用云厂商的只读实例，控制台自带监控面板，CPU、内存、连接数开箱即用，但有个坑，部分云产品的只读实例延迟指标精确度不够，不显示具体落后多少秒，只给一个
lag
| 方案对比 | 延迟指标粒度 | 自定义监控难度 | 存量成本 |
|---|---|---|---|
| 自建主从 | 秒级，可加心跳表 | 较高，需自己写脚本 | 机器加运维人力 |
| Proxy中间件 | 代理层统一采集 | 中，需熟悉代理语法 | 多一层组件维护 |
| 云RDS只读 | 多数为分钟级聚合 | 低，API可取数 | 实例费用偏高 |
读写分离延迟监控怎么做才能真实反映故障
延迟是读写分离的头号敌人，用户刚下完单，刷新页面看不到订单，体验直接崩塌，但“延迟”这个词太笼统,必须拆成物理延迟和业务延迟两层分别监控。
主从延迟的真实数值靠心跳表
Seconds_Behind_Master靠不住,就自己建一张心跳表打底。
- 在主库建一张
heartbeat表，字段就两个：id、ts - 写个定时任务，每秒钟更新一次
ts字段 - 从库去查这张表，用当前时间减掉
ts，得出真实延迟秒数
这个过程不能省，只有主库持续有写入，从库的复制线程才保持活跃,回放落后的时间才能被准确测量。
业务延迟用探针模拟用户行为
物理延迟再低，如果代码在事务提交后才查询从库，依然会读到旧数据,这时候需要引入探针脚本。
- 模拟真实业务路径，创建订单 -> 等待1秒 -> 查从库订单状态”
- 记录每一步的耗时和返回结果，判断业务侧能否读到刚写入的数据
- 探针结果直接决定要不要切换流量回主库
一致性校验不能只看延迟，还得有自动兜底方案
延迟只能说明复制链路健康，却不能保证主从数据一定一致，主库上一个大事务回滚、从库执行出错、磁盘写满,都会导致数据差得越来越远。
定期跑数据比对任务
MySQL场景下，用percona-toolkit里的pt-table-checksum是最常见做法，在原库执行校验语句，把每张表的行级校验和算一遍，再去从库比对,有差异会标记出来。
- 建议每周挑业务低峰期跑一次全库比对
- 发现不一致用时，用
pt-table-sync生成修复SQL，先人工过一眼再执行 - 不要在生产高峰期跑，比较消耗IO
把校验做成监控项
比对结果别只输出成日志，要把异常状态推送到告警平台，触发一致性告警后，哪怕延迟是0,也要立刻介入排查。
流量分配和容量水位决定从库能扛多久
读写分离不是配好规则就完事，流量分配是否均匀、从库水位什么时候到顶,这些都属于监控前置工作。
读写比例靠路由日志统计
在Proxy层或代码框架层，记录读写操作的请求数量,用路由统计观察：
- 读流量占比是否如预期，比如预估7：3，实际跑了9：1，说明写操作也被路由到从库
- 是否存在慢查询把某个从库的CPU打满，而其他从库空闲
从库容量水位设置告警
每个从库的CPU、内存、磁盘IO、慢查询数都要单独成图，多个从库的负载差异超过50%,就要考虑负载均衡策略是否失效。
报警阈值定多少才不会被频繁打扰
阈值设得太灵敏，半夜连呼带叫全是误报；设得太迟钝，主库都挂了还没反应，业内专家指出,阈值设定要分两级走：
- 警告级：主从延迟超过10秒、某从库CPU超过70%、慢查询数量突增，通知到负责人企业微信
- 严重级：延迟超过60秒、复制线程中断、心跳表超过30秒未更新，直接电话报警
阈值定完别急着上线，先试跑观察两周，看正常业务的抖动范围,再微调修正。
上线前预案和回切监控
读写分离改造完成不是终点，主库故障后的切换流程才是真正的考验，从库提升为主库后，原先的监控IP、告警规则全部要跟着机器身份走。
- 提前写好
failover脚本，包含切换后的监控检查项 - 切换演练重点观察数据补齐时间，用心跳表确定从库追平主库的耗时
- 回切操作同样要留出窗口期，不要在流量高峰直接反向操作
监控指标定得越靠前，后面踩的坑就越少，把延迟、一致性、流量、水位四类基线记在本子上，每一项都给出具体阈值和检查频率,再动手改代码。
Q&A：读写分离常见监控疑问
读写分离价格成本高不高？
自建方案成本在机器和人力，至少需要一主一从两台机器，外加日常巡检维护开销，Proxy中间件方案还要多一台代理节点，云RDS方案按实例规格计费，只读实例通常为主实例价格的70%至80%，前期改造的代码成本也不低，如果框架不支持动态切换数据源,还得额外开发。
主从延迟超过多少秒必须强制回切？
没有统一标准值，取决于业务容忍度，订单支付场景建议超过5秒就切换读流量回主库，因为用户刷新页面的等待极限就在几秒内，报表分析场景可以放宽到30秒，但要把延迟指标和业务场景绑定记录,方便事后追溯。
读写分离从库CPU飙高，第一步该看什么？
第一步查慢查询日志，确认是否有大范围扫描SQL被路由到从库，第二步看连接数是否被打满，排查是否存在连接泄漏，第三步检查是否有批量刷数据任务集中执行,错峰安排即可恢复。