直接登录从库MySQL执行SHOW SLAVE STATUS\G,重点检查Slave_IO_Running、Slave_SQL_Running和Seconds_Behind_Master三个字段:前两者须为Yes,后者应接近0;若异常则分别查Last_IO_Error和Last_SQL_Error定位问题。

直接登录从库的 MySQL 客户端,执行 SHOW SLAVE STATUS\G 即可查看主从复制状态。关键不是看全量输出,而是盯住几个核心字段——它们能快速告诉你复制是否健康、有无延迟或错误。
从库上执行 SHOW SLAVE STATUS\G 查状态
这是最标准、最直接的方式。注意必须在从库的 MySQL 命令行中执行,不能在 Linux shell 下直接敲(否则会报 bash: show: command not found)。执行后垂直显示更清晰,便于定位字段:
- 务必使用 \G 而非分号,避免信息挤成一行
- 如果提示权限不足,说明当前用户无 SUPER 或 REPLICATION CLIENT 权限,需用高权限账号(如 root)登录
- 输出为空或报错 “ERROR 1227 (42501)” 时,大概率是从库未启用复制或配置不完整
重点检查三个核心字段
不用通读全部 30+ 个字段,只关注这三个就能判断 90% 的问题:
-
Slave_IO_Running:应为 Yes。表示从库 IO 线程正在连接主库、拉取 binlog。若为 No,常见原因是网络不通、主库防火墙拦截、复制用户无权限或主库 binlog 关闭
-
Slave_SQL_Running:应为 Yes。表示 SQL 线程正在回放中继日志。若为 No,通常是执行 SQL 出错,比如主键冲突、表结构不一致、从库被误写
-
Seconds_Behind_Master:理想值是 0 或较小正整数(如 ≤ 1–2 秒)。若为 NULL,说明复制已中断;若持续大于 60,需查负载、大事务或慢查询阻塞
快速发现错误的两个字段
一旦复制异常,错误信息就藏在这两个地方,优先扫一眼:
-
Last_IO_Error:IO 层错误。例如 “error connecting to master”、“Access denied for user”,说明连不上主库,要查网络、端口、用户权限、主库 bind-address 配置
-
Last_SQL_Error:SQL 层错误。例如 “Duplicate entry for key 'PRIMARY'”、“Table doesn't exist”,说明中继日志里某条语句在从库无法执行,需人工干预或跳过(慎用)
辅助验证命令(按需使用)
当主从状态看起来正常但仍有疑虑时,可用这些命令交叉核对:
- 在主库执行 SHOW MASTER STATUS;,获取当前 binlog 文件名和 Position;再对比从库 Master_Log_File 和 Read_Master_Log_Pos 是否一致,确认拉取点没偏移
- 在从库执行 SHOW PROCESSLIST;,查找 User 为 system user 的两行:一行标 “I/O thread”,一行标 “SQL thread”,确认它们状态为 “Waiting for master to send event” 和 “Slave has read all relay log”
- 用 SHOW BINARY LOGS;(主库)或 SHOW RELAYLOG EVENTS;(从库)查看日志文件是否存在、是否滚动,排除磁盘满或日志被误删
以上就是mysql如何查看主从复制状态_mysql复制状态检查方法的详细内容,更多请关注php中文网其它相关文章!