一：查看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
总控，可以找到日志，看出是哪一张表被操作，如果是删除操作还是需要备份该表进行还原
