真正反映同步异常需查Seconds_Behind_Master（NULL表示出错）、Last_IO_Errno和Last_SQL_Errno（非零必须报警），并排除SQL_Delay干扰，持续2次>60秒才判定延迟异常。
查 SHOW SLAVE STATUS 的哪些字段才真正反映同步异常
只看 Slave_IO_Running 和 Slave_SQL_Running 为 Yes 不够——它们可能卡在“已启动但没干活”的假活状态。关键要看：
• Seconds_Behind_Master：值为 NULL 表示 IO 或 SQL 线程出错，不是延迟大；
• SQL_Delay 和 SQL_Remaining_Delay：主动延迟配置会干扰判断，脚本里得先排除；
• Seconds_Behind_Master > 60 且持续 2 次检测（避免瞬时抖动误报）；
• Last_IO_Errno、Last_SQL_Errno 非零必须报警，哪怕线程显示 running。
用 mysql 命令行写轻量检查脚本，别碰 Python 或 Shell 大框架
生产环境 MySQL 服务器通常没装 Python 或依赖管理工具，用原生 mysql 客户端 + Shell 最稳。
• 连接必须加 --defaults-file 指向只读账号配置，避免密码明文或交互式输入；
• 查询结果用 \G 格式难解析，统一用 -N -s -e 输出纯文本列；
• 示例片段：
mysql --defaults-file=/etc/mysql/replica.cnf -N -s -e "SHOW SLAVE STATUS\G" | grep -E "^(Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master|Last_IO_Errno|Last_SQL_Errno):" | awk -F': ' '{print $2}'• 注意：MySQL 8.0.22+ 默认禁用
SHOW SLAVE STATUS 给非 SUPER 用户，需显式授权 REPLICATION CLIENT。
报警触发后怎么避免“狂轰滥炸”
一次网络抖动可能让脚本每分钟都报一次，运维会被消息淹没。
• 记录上次报警时间戳到本地文件（如 /tmp/replica_alerted_at），15 分钟内重复不发；
• 报警内容必须带完整上下文：Seconds_Behind_Master 值、Last_IO_Error 具体文本、当前时间；
• 邮件/企微/Webhook 发送失败要写日志，别静默丢弃；
• 不要依赖 crontab 的 MAILTO——它不传错误详情，也收不到结构化字段。
主从切换后脚本为什么还在报老主库的错
很多脚本硬编码了主库 IP 或 host，切换后连不上，直接超时失败，反而掩盖了真正的同步问题。
• 用 SELECT @@server_id + SHOW VARIABLES LIKE 'report_host' 动态识别本机角色；
• 或更简单：只在明确标记为 replica 的机器上运行该脚本（比如通过 hostname 含 -replica 判断）；
• 如果用 MHA 或 Orchestrator，优先读取其元数据 API，而不是自己猜主从拓扑；
• 别忘了检查 read_only=ON 是否生效——有些脚本误把可写从库当主库连。
Seconds_Behind_Master 持续 300 秒的告警，对 DBA 是立即登录排查，对 SRE 可能只是记录指标——脚本输出得留好字段接口，别把人肉决策逻辑塞进去。 
