复制监控工具链是什么
复制监控按复杂度分三档：直接用 performance_schema 与 SHOW REPLICA STATUS 配自研脚本；用 mysqld_exporter 采集指标交给 Prometheus + Grafana；再用 Orchestrator 或云监控做拓扑级管理。不管选哪档，最终都要落到三组告警：两个复制线程是否在跑、延迟是否超过阈值、有无报错导致停止，缺一组就等于漏掉一类故障。
基本信息
| 最低成本方案 | performance_schema.replication_* 表 + 定时脚本 |
|---|---|
| 主流方案 | mysqld_exporter + Prometheus + Grafana + Alertmanager |
| 拓扑级方案 | Orchestrator 或云数据库自带监控 |
| 核心告警 | IO/SQL 线程状态、延迟秒数、relay log 空间、复制错误号 |
| 采集频率 | 15-60 秒足够，过密会增加实例开销 |
| 账号要求 | 只读、最小权限，避免监控账号成为攻击面 |
典型使用场景
- 值班告警配置：复制中断或延迟超标第一时间通知
- 延迟趋势分析：判断是网络瓶颈还是从库重放能力不足
- 大促前压测：观察高写入下从库延迟峰值
- 故障复盘：用历史指标还原复制停止的时间点与原因
- 容量评估：根据延迟与 relay 空间趋势决定是否加从库或升配
工具档位对照
| 方案 | 适用规模 | 特点 |
|---|---|---|
| P_S + 自研脚本 | 小规模 | 零依赖，告警规则要自己写 |
| mysqld_exporter | 中等规模 | Grafana 面板成熟，指标齐全 |
| Orchestrator | 大规模多集群 | 拓扑 API、可视化与切换能力 |
| 云监控 | 云上实例 | 开箱即用，但指标口径受厂商限制 |
自研脚本采集关键项
自研脚本采集关键项
# 每 30 秒采一次，输出便于接入任意告警系统
mysql -N -e "SHOW REPLICA STATUS\G" | grep -E 'Replica_IO_Running|Replica_SQL_Running|Seconds_Behind_Source|Relay_Log_Space|Last_SQL_Error'
# 用位点差计算真实延迟（避免 Seconds_Behind 失真）
mysql -N -e "SHOW REPLICA STATUS\G" | grep -E 'Read_Source_Log_Pos|Exec_Source_Log_Pos'
# 复制线程异常时直接退出码告警
mysql -N -e "SHOW REPLICA STATUS\G" | grep -q 'Replica_SQL_Running: Yes' || echo 'ALERT: sql thread stopped'exporter 关键告警指标
exporter 关键告警指标
# 以下为常见指标名示例，实际名称随 exporter 版本变化
mysql_slave_status_slave_io_running == 0
mysql_slave_status_slave_sql_running == 0
mysql_slave_status_seconds_behind_master > 300
mysql_slave_status_relay_log_space > 10737418240指标名随 exporter 版本调整（如 slave 与 replica 命名），配置告警规则前先看实际抓取到的指标名；用 --collect.slave_status 之类的开关控制采集范围，避免指标口径与面板不一致。
告警规则必须演练：阈值改完、静默期、值班切换都要验证通知能真正送到人手里。历史上最常见的失效模式不是指标采不到，而是告警发了没人收到。