通过show replica status命令查看某个实例的主从复制情况，发现复制报错，Replica_SQL_Running_State显示的报错信息如下：
Worker 1 failed executing transaction '230e8ddf-5bff-11f0-854d-0022a593688b:1' at source log mysql-bin.000002, end_log_pos 478; Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'caching_sha2_password' AS '$A$005sC1B? \n,(\n,#QQ~ZGKnyuIvm7GlOlsxtbDZaYZvA3uwQBq5OQ9VDIA9dx8''
报错信息的含义是： Error 'Operation ALTER USER failed for 'root'@'localhost'
说明主库执行了一个 ALTER USER
操作，试图更改 root@localhost
的认证方式或密码，但这个变更在从库 执行失败，导致复制停止。
可能的原因：
root@localhost 已存在且不允许更改（如权限不足、已被锁定） 从库的 root 账号被删掉或不同步（主从结构变更后未同步用户） 从库的 root@localhost
使用的是不同插件（比如mysql_native_password
）从库设置了权限控制插件或安全策略，禁止本地用户改密
目标： 跳过这个 ALTER USER 操作，但保留复制功能，不破坏数据一致性。
方法：跳过这个gtid事务
STOP REPLICA;
# 设置GTID_NEXT为报错的gtid
SET GTID_NEXT = '230e8ddf-5bff-11f0-854d-0022a593688b:1';
# 执行一个空事务，完成一次合法的事务提交，使指定的gtid被标记为已完成
BEGIN; COMMIT;
#恢复为默认行为（让 MySQL 自动分配 GTID）
SET GTID_NEXT = AUTOMATIC;
START REPLICA;
含义：告诉从库“我们已经执行了这个GTID”，虽然其实没真正执行，这样复制可以继续运行。
怎么理解？
gtid（global transaction identifier，全局事务id)是主从复制中唯一标识一条事务的机制。MySQL通过gtid让主从复制更可控、支持自动定位和故障恢复。
gtid的怎么工作的呢，举个例子：
主库执行了一个事务-->系统会分配一个gtid，比如gitid=230e8ddf-5bff-11f0-854d-0022a593688b:1。 然后系统会写入binlog，并同步给从库。 从库执行这个gtid时，会记录在自己的Executed_Gtid_Set中。这个集合代表从库已经成功执行过哪些事务。
回到这个例子，当某条gtid对应的事务执行失败，我们执行如下命令：
SET GTID_NEXT = '230e8ddf-xxxx:25';
BEGIN; COMMIT;
SET GTID_NEXT = AUTOMATIC;
相当于手动将接管从库的gtid设置，将gtid_next设置为'230e8ddf-xxxx:25';。 我们执行了SET GTID_NEXT = 'xxx:123'
后，mysql期待我们下一步执行一个属于这个gtid的事务，因为我们不想真正执行任务数据变更，就可以使用begin;commit;构造一个空事务，这样这个gtid就会被放到Executed_Gtid_Set中，复制可以继续，其后的SET GTID_NEXT = AUTOMATIC;表示恢复默认的复制行为，让mysql自动分配gtid。
生产环境要慎重执行这个命令，跳过事务意味着从库缺少一部分主库的写操作，可能影响业务一致性。建议只在明确知道事务无害的前提下使用。
点个“赞 or 在看” 你最好看！
👇👇👇 谢谢各位老板啦！！！
