MySQL主从复制状态查看与故障排查方法

一、最核心命令（在从库执行，Windows Navicat / CMD 都能用）

登录从库 MySQL 之后，直接执行这条命令即可快速查看复制状态：

SHOW SLAVE STATUS\G

注意结尾使用的是反斜杠加 G，而不是分号，这个细节很容易手误。

输出结果中，重点查看以下两行，同步是否正常全靠它们来判断：

Slave_IO_Running

• 如果显示 Yes：说明从库已成功连接主库，正在拉取二进制日志，复制链路一切正常。
• 如果显示 Connecting：大概率是网络不通、IP 或端口配置错误、防火墙拦截，或者复制账号密码有误。
• 如果显示 No：表示连接失败，需要进一步排查 IO 线程的具体报错信息。

Slave_SQL_Running

• 如果显示 Yes：说明中继日志正在正常执行，数据同步无异常。
• 如果显示 No：通常意味着数据冲突，例如主键重复、表结构不一致，这会导致同步中断。

二、几个关键状态字段解释

除了上面两个核心指标，以下字段在日常排查时也非常实用：

Last_IO_Error：IO 线程的报错信息就记录在此字段，当从库连不上主库时，来这里查找原因，直接明了。

Last_SQL_Error：SQL 线程的报错信息，当同步中断或发生主键冲突时，错误详情会写在这里，一眼就能定位问题。

Seconds_Behind_Master：这是主从延迟时间，单位是秒。理想情况下为 0，表示实时同步。如果该数值持续增大，说明从库处理速度跟不上主库的写入负载，需要关注。

Replicate_Wild_In_Table_List：如果你配置了只同步部分表的过滤规则，这个字段可以帮助确认过滤条件是否生效。

三、主库上查看状态（主库执行）

在主库上，可以使用以下命令查看当前二进制日志的位置信息：

SHOW MASTER STATUS;

输出结果会直接显示当前的 binlog 文件名和具体位置，方便后续与从库进行对照。

如果想确认复制账号是否存在，可以执行：

SELECT user,host FROM mysql.user WHERE user='repl';

四、Windows CMD 下查看完整日志（排查错误必备）

在 Windows 上操作也不复杂，打开 MySQL 命令行：

mysql -uroot -p

输入密码后，直接执行：

SHOW SLAVE STATUS\G

这和图形化工具的操作效果完全一致。

五、常用启停命令

以下命令在日常维护中会频繁用到：

停止同步：

STOP SLAVE;

启动同步：

START SLAVE;

重置主从（重新搭建主从环境时使用）：

RESET SLAVE ALL;

六、最简单的判断口诀

• 如果 IO=Connecting：基本就是网络、账号或防火墙的问题，排查优先级最高。
• 如果 IO=Yes，SQL=No：说明主从库对应的表数据不一致，最常见的原因是主键冲突，需要人工介入处理。
• 如果 两项都是 Yes：恭喜，主从同步正常运行，指定数据表会自动备份，无需过多担心。

把执行 SHOW SLAVE STATUS\G 的结果贴出来，根据以上指标就能快速定位问题所在。

七、知识扩展

说到 MySQL 主从同步状态，最核心的那条命令，在 MySQL 8.0.22 及之后的版本中已经改名为 SHOW REPLICA STATUS（老版本仍使用 SHOW SLAVE STATUS）。这条命令返回的数据非常丰富，学会解读这些字段，就能全面把握复制的健康状况。

记住，一定要在从库上执行，并且用 \G 垂直格式输出，这样长字段看起来才方便。

SHOW REPLICA STATUS\G

注意：如果你的 MySQL 版本低于 8.0.22，请把命令中的 REPLICA 换回 SLAVE。

需要重点关注的 6 个核心指标

在输出的一大堆字段中，下面这六个是判断同步是否正常的关键所在：

Slave_IO_Running（IO 线程）

• 负责从主库拉取二进制日志（binlog）。正常值为 Yes。
• 异常值为 No 或 Connecting。如果是 Connecting，通常由网络不通、主库连接失败或复制用户密码错误导致；如果是 No，可能是 IO 线程被手动停止，或遇到了致命错误。

Slave_SQL_Running（SQL 线程）

• 负责将中继日志中的 SQL 事件在从库上重放执行。正常值为 Yes。
• 异常值为 No，说明 SQL 语句执行失败，最常见的原因是主从库表结构不一致、数据冲突或主键重复。

Seconds_Behind_Master（同步延迟秒数）

• 表示从库落后主库的时间（秒）。理想值当然是 0。
• 如果该值持续增长或偏大，说明从库的处理速度跟不上主库的写入速度。如果显示 NULL，则表示复制线程未运行或 IO 线程未连接。

Last_IO_Error / Last_SQL_Error（最近的错误信息）

当上述两个线程状态不是 Yes 时，这两个字段会直接给出具体的报错原因，是排查问题的第一手资料，切勿忽略。

Master_Log_File 与 Read_Master_Log_Pos

这组值表示 IO 线程已经读取到的主库 binlog 文件名和位置。

Relay_Master_Log_File 与 Exec_Master_Log_Pos

• 这组值表示 SQL 线程已经执行到的主库 binlog 文件名和位置。
• 排查方法很简单：对比这两组值，如果第一组（已读取）始终大于第二组（已执行），说明存在延迟。延迟越大，Seconds_Behind_Master 的数值也会越高。

判断同步是否正常的流程

• 登录从库，执行 SHOW REPLICA STATUS\G。
• 检查 Slave_IO_Running 和 Slave_SQL_Running 是否都是 Yes。
• 检查 Last_IO_Error 和 Last_SQL_Error 是否为空。
• 检查 Seconds_Behind_Master 是否为 0，或者在可接受的延迟范围内（比如小于 10 秒）。

排查复制故障的常用命令

查看具体错误日志：

SHOW REPLICA STATUS\G

重点关注 Last_IO_Error 和 Last_SQL_Error 字段。

查看主库的同步状态（判断主库写入压力）：

SHOW MASTER STATUS;

确认主库当前的 binlog 文件名和位置，方便与 Master_Log_File 进行对比。

查看复制线程信息：

SHOW PROCESSLIST;

在输出中查找 system user 相关的复制线程，可以查看其当前工作状态。

其他常用的监控方式

如果你更喜欢结构化的数据，可以使用 performance_schema：

SELECT * FROM performance_schema.replication_connection_status\G
SELECT * FROM performance_schema.replication_applier_status\G

这些表提供的信息比 SHOW REPLICA STATUS 更清晰，适合集成到监控脚本中使用。

使用第三方工具：例如 pt-heartbeat（Percona Toolkit），这是生产环境中更精确的延迟监控方案，适合对延迟要求较高的场景。