一：查看mysql的从库，发现sql进程状态 “no”.提示执行传输过来的binlog日志，执行失败，

二：查看主库对应的二进制日志的gtid地方。插入一些数据。

# mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001 |grep -A 100 "560d72ff-b057-11ee-84ba-5254005c1b84:8"

三：从日志来看是写入错了，

1：第一种办法：跳过重复执行gtid事务 560d72ff-b057-11ee-84ba-5254005c1b84:8

从库执行操作

mysql> stop slave;

mysql> set @@session.gtid_next='560d72ff-b057-11ee-84ba-5254005c1b84:8';

mysql> start slave;

mysql> show slave status\G;

恢复正常了，

第二种办法。如果要保证这张表数据一致性，如果是删除或者更新操作，这表就会存在数据不一致问题，可以先备份这张表，从主库

从库删除操作

mysql> delete from userinfo where name='Jack08';

gtid的主从复制，是跟进gtid来判断是否数据一致，但是当前删除的数据是从库执行过的gtid事务，因为主节点不会判断出，主从数据是否不一致。因此这种现象就得恢复表。

1：从主库备份单表db1下的userinfo表。

# mysqldump -uadmin  -p"hechunyang" -S /tmp/mysql_db01.sock db1 userinfo -R -E --triggers --set-gtid-purged=OFF --source-data=2 --single-transaction --max-allowed-packet=512M >  /tmp/db1_userinfo.sql

2：拷贝到从库

mysql> stop slave;   #停止主从复制

mysql> set sql_log_bin=0;  #停止写入binlog开关，防止恢复表，出现写入binlog日志。

mysql> use db1
mysql> source db1_userinfo.sql;

mysql> set sql_log_bin=1;  

mysql> start slave;

3.查看主节点的gtid

总控，可以找到日志，看出是哪一张表被操作，如果是删除操作还是需要备份该表进行还原