主从同步停止时Seconds_Behind_Master为NULL且Slave_SQL_Running为No，表明SQL线程卡在某条语句上，需先查看Last_SQL_Error定位具体错误，再结合Relay_Master_Log_File、Exec_Master_Log_Pos等字段分析原因，不可盲目跳过或重启。
主从同步停了，SHOW SLAVE STATUS\G 显示 Seconds_Behind_Master: NULL 且 Slave_SQL_Running: No
这通常不是网络断了，而是 SQL 线程卡在某条语句上，最常见的是主库写了从库不存在的表、触发器或函数，或者主从时区/SQL mode 不一致导致解析失败。先别急着重启，得看具体错在哪条语句。
执行 SHOW SLAVE STATUS\G，重点盯住三处：Relay_Master_Log_File（主库 binlog 文件名）、Exec_Master_Log_Pos（已执行到的位置）、Last_SQL_Error（最后报错信息）。如果 Last_SQL_Error 提示 “Table doesn’t exist” 或 “Unknown column”，说明 DDL/DML 兼容性出了问题，不是位置偏移问题。
- 不要直接
SET GLOBAL sql_slave_skip_counter = 1跳过——跳过一条可能跳进下一条坑 - 确认从库是否开启
skip_slave_start=1（宝塔默认不启用，但手动改过配置文件可能残留） - 检查主库
binlog_format是否为ROW：如果是MIXED或STATEMENT，某些函数（如NOW()、UUID()）在从库重放时行为不一致
校验 Master_Log_File 和 Read_Master_Log_Pos 是否与主库当前 binlog 位置一致
从库 IO 线程是否还在正常拉日志，要看它“以为自己该读哪”和主库“实际写到哪”是否对得上。宝塔界面里看不到实时 binlog 位置，得登录主库查。
在主库执行：SHOW MASTER STATUS;，拿到 File 和 Position；再在从库执行 SHOW SLAVE STATUS\G，对比 Master_Log_File 和 Read_Master_Log_Pos。两者完全一致才说明 IO 线程没丢日志。
- 若
Master_Log_File相同但Read_Master_Log_Pos明显落后（比如差几万字节），大概率是网络抖动或主库 binlog 写得快、从库 IO 线程来不及消费 - 若
Master_Log_File已变成mysql-bin.000005，但从库还卡在mysql-bin.000003，说明 IO 线程已中断，Slave_IO_Running: No，这时候先看从库错误日志：/www/server/data/*.err - 宝塔自带的 MySQL 错误日志路径固定，但部分版本会把 relay log 错误混在主日志里，建议用
tail -n 50 /www/server/data/*.err | grep -i "io thread\|relay"快速过滤
测试主从之间 3306 端口是否真通，且账号有 REPLICATION SLAVE 权限
宝塔默认关闭外网访问，主从如果跨服务器，从库连不上主库 3306 是最常见原因。别只 ping IP，要测端口 + 用户权限 + SSL 配置三件套。
从库服务器上执行：telnet 主库IP 3306（若无 telnet，用 nc -zv 主库IP 3306）。通了不代表能同步——还得验证账号权限。用从库上配置的复制账号（比如 repl@'%' ）手动连一次：mysql -h 主库IP -u repl -p，成功后执行 SHOW GRANTS;，确认输出包含 REPLICATION SLAVE ON *.*。
- 宝塔新建的复制用户默认绑定
localhost，跨服务器必须手动改成%或具体从库 IP，并刷新权限：FLUSH PRIVILEGES; - 主库若开启强制 SSL（
require_secure_transport=ON），而从库连接串没加ssl-mode=REQUIRED，IO 线程会静默失败，SHOW SLAVE STATUS里只显示Connecting状态 - 阿里云/腾讯云安全组、宝塔防火墙、系统 firewalld 三层都得放行 3306，缺一不可
从库 relay log 损坏或位置错乱，需要人工重置同步点
当 Relay_Master_Log_File 和 Exec_Master_Log_Pos 明显滞后，且 Last_IO_Error 提示 “Could not parse relay log event entry”，基本可判定 relay log 文件损坏。这不是数据丢失，只是从库本地缓存的日志出错了，可以安全重建。
操作分四步：停同步 → 清 relay log → 查主库当前位点 → 重新 CHANGE MASTER。关键不是跳过，而是让从库“从主库此刻真实位置开始追”。
- 在从库执行：
STOP SLAVE;，然后删掉/www/server/data/relay-log*文件（注意别删错成 binlog） - 主库执行：
SHOW MASTER STATUS;，记下File和Position - 从库执行：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=123456789;（填你刚查到的值） - 再
START SLAVE;，立刻查SHOW SLAVE STATUS\G，确认两个Running都是Yes
重置前务必确认主库 binlog 没被 purge —— 宝塔默认保留 7 天，但如果主库流量大或手工执行过 PURGE BINARY LOGS，旧位置可能已不存在。这时只能重做全量同步。
