一、问题现象当前这个从库的 SQL 线程已经断了原因是回放主库传来的这条语句时报错GRANT REPLICATION SLAVE ON *.* TO repl%报错Last_Errno: 1133Last_Error: Cant find any matching row in the user table说明从库的 mysql.user 里没有 repl% 这行用户记录所以 GRANT 无法生效。环境是 GTID 模式不能用 SET GLOBAL sql_slave_skip_counter需要用 GTID 空事务方式跳过。二、排查步骤1. 先确认从库确实没有这个用户在报错的从库上执行SELECT Host, User FROM mysql.user WHERE User repl;如果返回为空或者没有 % 这一行就确认了 1133 的原因。三、修复步骤2. 在从库补上 repl% 用户CREATE USER repl% IDENTIFIED BY 你的repl密码;FLUSH PRIVILEGES;密码要和主库上 repl 用户保持一致。补完后再执行START SLAVE;然后检查SHOW SLAVE STATUS\G如果 Slave_SQL_Running 变成 Yes问题就解决了。四、GTID 空事务跳过3. 如果补用户后仍然报错再用 GTID 空事务跳过先查出出错事务的 GTIDSHOW SLAVE STATUS\G看这两行Last_SQL_Error_Gtid: xxxxxx:NNNRetrieved_Gtid_Set: ...Executed_Gtid_Set: ...然后执行STOP SLAVE;SET GTID_NEXTxxxxxx:NNN;BEGIN;COMMIT;SET GTID_NEXTAUTOMATIC;START SLAVE;这里的 xxxxxx:NNN 必须替换成 Last_SQL_Error_Gtid 的实际值。五、状态确认4. 修复后确认主从状态SHOW SLAVE STATUS\G重点看Slave_IO_Running: YesSlave_SQL_Running: YesSeconds_Behind_Master: 0Last_SQL_Error 为空六、根因排查顺便排查根因这个错误通常不是复制本身坏了而是主库上对 repl 用户的创建/授权方式有问题或者主从 mysql.user 不一致。建议在主库也确认SELECT Host, User FROM mysql.user WHERE User repl;SHOW GRANTS FOR repl%;如果主库上 repl 用户的 Host 不是 %而是 localhost 或其他值那从库回放 GRANT ... TO repl% 时也会报 1133。最稳妥的做法是主从都使用 CREATE USER repl% ...再 GRANT REPLICATION SLAVE最后 FLUSH PRIVILEGES。