快速定位mysql主从复制中断需紧盯show slave status中的slave_sql_running、last_sql_error等关键字段，90%中断源于last_sql_error，如主键冲突、表不存在等，应通过脚本定期提取并报警。
如何快速定位 MySQL 主从复制中断的错误信息
主从复制一旦出错，SHOW SLAVE STATUS\G 是第一入口，但它的输出太长，关键字段容易被忽略。真正要盯住的是 Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running 和 Last_IO_Error/Last_SQL_Error 这几个字段。其中 Last_SQL_Error 最具实操价值——90% 的业务中断都源于它，比如主键冲突、表不存在、SQL 模式不一致等。
常见错误现象包括：Slave_SQL_Running: No 但 Seconds_Behind_Master 显示为 NULL；或 Seconds_Behind_Master 突然卡在某个固定值不再变化。这时不要只查 error log，MySQL 的复制错误默认不会写入全局 error.log，而是只保留在 SHOW SLAVE STATUS 中。
用 shell 脚本定期巡检并提取关键错误字段
别依赖人工登录，写个轻量脚本每 5 分钟查一次即可。核心逻辑是用 mysql 命令行连接后解析 SHOW SLAVE STATUS 输出，而不是 grep 全日志——因为复制错误不落盘。
实操建议：
- 用
mysql -N -s -e "SHOW SLAVE STATUS\G"获取无格式输出，避免列头干扰 - 用
awk '/Last_SQL_Error/{print $2}'提取错误内容（注意字段顺序可能因 MySQL 版本浮动，建议用awk '/^ *Last_SQL_Error:/{gsub(/^ *Last_SQL_Error: +/, ""); print}'更稳妥） - 判断条件优先级：先看
Slave_SQL_Running: No，再检查Last_SQL_Error是否非空，最后才看Seconds_Behind_Master > 600（即延迟超 10 分钟） - 避免用 root 用户执行脚本，创建专用账号并授予
REPLICATION CLIENT权限即可
如何对接短信/钉钉报警而不被误报刷屏
直接每分钟发告警等于自扰，必须加抑制逻辑。重点不是“有没有错”，而是“错是否持续存在且未恢复”。
实操建议：
- 把最近一次错误写入本地文件（如
/tmp/mysql_slave_last_error），每次巡检前比对当前错误与文件内容是否一致；仅当错误变更或首次出现时触发报警 - 钉钉机器人用
POST发送 JSON，关键字段必须包含：slave_host、error_timestamp、Last_SQL_Error截断到 120 字符以内（避免钉钉截断） - 不要在脚本里硬编码密码，改用
~/.my.cnf配置文件，并设权限chmod 600，否则mysql客户端会拒绝读取 - 若从库启用了 GTID，需额外检查
Retrieved_Gtid_Set和Executed_Gtid_Set是否追平，仅靠Seconds_Behind_Master不可靠
为什么不能只依赖 pt-heartbeat 或第三方工具
pt-heartbeat 测的是延迟，不是错误。它无法捕获 Duplicate entry 'xxx' for key 'PRIMARY' 这类 SQL 执行失败，因为心跳记录本身成功插入了，但从库的 SQL 线程早已停摆。
真正需要监控的是 SQL 线程状态本身。如果你已用 Prometheus + mysqld_exporter，注意它默认暴露的 mysql_slave_status_slave_sql_running 是布尔值，但不带错误详情——你仍需单独采集 Last_SQL_Error 并做字符串指标（例如用 mysql_slave_last_sql_error_hash 对错误内容做 fnv1a_64 哈希），否则报警时看不到具体错在哪条语句。
复杂点在于：MySQL 8.0.22+ 开始支持 replica_parallel_workers > 0，此时 Last_SQL_Error 可能来自任意一个 worker 线程，且错误清空后不会自动重置为 NULL，需手动 STOP SLAVE; START SLAVE; 才刷新——这个细节常被脚本忽略，导致误判“错误已恢复”。
