slave_sql_running为no时，必须先执行show slave status\g查看last_sql_error定位错误码（如1032、1062），再结合mysqlbinlog解析relay log确认真实sql；1062和1032优先手动修复数据而非跳过，跳过仅限sbr且单次偶发，严禁slave_skip_errors=all。
Slave_SQL_Running: No 且 Last_SQL_Error 含 “Table doesn’t exist” 或 “Duplicate entry”
这类报错说明 SQL 线程卡在某条语句上，直接导致后续所有变更都无法执行，从库数据就此停滞。常见于主库做了 DDL（比如 ALTER TABLE），但从库表结构没同步更新；或主库插入时忽略重复键（INSERT IGNORE），从库却因唯一索引冲突报错。
- 先执行
SHOW SLAVE STATUS\G，确认Slave_SQL_Running是No，并记下Last_SQL_Error全文 - 检查报错中的表是否存在：
SHOW TABLES LIKE 'xxx';，字段名、索引是否一致：SHOW CREATE TABLE xxx; - 若从库缺表，不能直接
CREATE TABLE—— 可能缺失触发器、分区定义或字符集差异；应从主库导出建表语句再执行 - 若报主键/唯一键冲突，先查该记录在主库是否存在：
SELECT * FROM tb WHERE id = ?;；如果存在，大概率是人为往从库写入过数据
Seconds_Behind_Master = 0 但数据实际不一致
这是最危险的情况：复制线程显示“正常”，但数据早已静默偏离。典型诱因是 max_allowed_packet 主从不一致、sql_mode 差异、或 RBR 模式下无主键表被并行写入后回放失败却未中断。
- 立刻比对主从变量：
SHOW VARIABLES LIKE 'max_allowed_packet';和SHOW VARIABLES LIKE 'sql_mode';，二者必须完全一致 - 对关键业务表运行一致性校验：
pt-table-checksum --nocheck-replication-filters --replicate=test.checksums h=主库IP,u=checksum_user,p=xxx - 若发现某张表
DIFF非 0，不要直接跑pt-table-sync—— 先用--print查看它打算执行什么 SQL，特别注意是否含DELETE（可能删掉从库合法数据） - 无主键表务必加主键：
ALTER TABLE tb ADD id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST;，否则并行复制 + RBR 下必然丢行
从库被人工写入导致主从分叉
只要从库开启了 read_only = OFF 或账号有写权限，就可能被应用、脚本、DBA 直接写入。此时 pt-table-sync 默认按“主库为真理源”修复，会把从库多出的数据删掉——而这些数据可能是双写架构里本该保留的。
- 检查从库是否开放写：
SELECT @@read_only;应为ON；查复制账号权限：SHOW GRANTS FOR 'repl'@'%';不应含INSERT/UPDATE/DELETE - 若已发生写入，先停业务写入，再人工比对几条差异记录：
SELECT * FROM tb WHERE id IN (1,2,3) ORDER BY id;主从分别执行 - 确认从库数据合法后，用
pt-table-sync --sync-to-master反向同步，而非默认方向 - 修复后立即加固：
SET GLOBAL read_only = ON;，并确保 MySQL 启动参数含read_only=1
IO 线程正常但 Relay Log 停滞在旧位置
Slave_IO_Running: Yes 只代表日志在拉，不代表 SQL 线程在消费。常见于 Relay Log 文件损坏、磁盘满、或 relay_log_purge = OFF 导致旧中继日志堆积阻塞新日志写入。
- 查 Relay Log 状态：
SHOW SLAVE STATUS\G中看Relay_Master_Log_File和Exec_Master_Log_Pos是否长期不变 - 检查磁盘空间：
df -h /var/lib/mysql，特别是relay-log所在分区 - 手动清理旧 Relay Log：
RESET SLAVE;（慎用！需先记下Master_Log_File和Master_Log_Pos）或设置relay_log_purge = ON - 若怀疑 Relay Log 损坏，可尝试跳过当前文件：
STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=12345; START SLAVE;
真正难处理的不是报错中断，而是那些不报错、不延迟、却悄悄错位的数据——它们往往藏在无主键表、max_allowed_packet 边界、或被忽略的 sql_mode 差异里。修复前必须确认“谁才是事实源”，而不是默认主库永远正确。
