MySQL8 1396错误处理

Last_SQL_Errno: 1396
               Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'c5d67684-fcd5-11f0-b41d-02420a4e7d02:7' at master log mysql-bin.000002, end_log_pos 3117452. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.

你现在明确看到了 Last_SQL_Errno: 1396 的错误，结合 GTID 主从复制的场景，这个 1396 错误码的核心含义是从库执行用户相关的操作（如创建 / 修改用户、授权）失败，导致对应 GTID 事务（c5d67684-fcd5-11f0-b41d-02420a4e7d02:7）无法应用，最终触发 Coordinator 停止。

先定位 1396 错误的具体原因

首先需要精准找到这个事务到底执行了什么用户操作导致失败，执行以下命令：

SELECT WORKER_ID, LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE, LAST_ERROR_TIMESTAMP FROM performance_schema.replication_applier_status_by_worker\G;

1396 错误的常见具体场景：

• 主库执行了 CREATE USER 'xxx'@'%'，但从库已存在同名用户；
• 主库执行了 ALTER USER 'xxx'@'%' IDENTIFIED BY 'xxx'，但从库该用户不存在 / 权限不足；
• 主库执行了 DROP USER 'xxx'@'%'，但从库无该用户；
• 从库的 root 用户权限不足，无法执行主库的用户操作。

针对 1396 错误的修复方案（GTID 模式）

如果确认该用户操作对从库无影响（比如主库误创建测试用户），可直接跳过该 GTID 事务：

-- 1. 停止复制
STOP SLAVE;

-- 2. 指定要跳过的 GTID 事务（替换为报错的 GTID）
SET GTID_NEXT = 'c5d67684-fcd5-11f0-b41d-02420a4e7d02:7';

-- 3. 执行空事务（让从库认为该 GTID 已执行）
BEGIN; COMMIT;

-- 4. 恢复 GTID 自动分配
SET GTID_NEXT = 'AUTOMATIC';

-- 5. 重启复制
START SLAVE;

-- 6. 检查修复结果（核心看 Slave_SQL_Running 是否为 Yes）
SHOW SLAVE STATUS\G;