一：查看mysql的從庫，發(fā)現(xiàn)sql進(jìn)程狀態(tài) “no”.提示執(zhí)行傳輸過來的binlog日志，執(zhí)行失敗，
二：查看主庫對(duì)應(yīng)的二進(jìn)制日志的gtid地方。插入一些數(shù)據(jù)。
# mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001 |grep -A 100 "560d72ff-b057-11ee-84ba-5254005c1b84:8"
三：從日志來看是寫入錯(cuò)了，
1：第一種辦法：跳過重復(fù)執(zhí)行g(shù)tid事務(wù) 560d72ff-b057-11ee-84ba-5254005c1b84:8
從庫執(zhí)行操作
mysql> stop slave;
mysql> set @@session.gtid_next='560d72ff-b057-11ee-84ba-5254005c1b84:8';
mysql> start slave;
mysql> show slave status\G;
恢復(fù)正常了，
第二種辦法。如果要保證這張表數(shù)據(jù)一致性，如果是刪除或者更新操作，這表就會(huì)存在數(shù)據(jù)不一致問題，可以先備份這張表，從主庫
從庫刪除操作
mysql> delete from userinfo where name='Jack08';
gtid的主從復(fù)制，是跟進(jìn)gtid來判斷是否數(shù)據(jù)一致，但是當(dāng)前刪除的數(shù)據(jù)是從庫執(zhí)行過的gtid事務(wù)，因?yàn)橹鞴?jié)點(diǎn)不會(huì)判斷出，主從數(shù)據(jù)是否不一致。因此這種現(xiàn)象就得恢復(fù)表。
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;? ?#停止主從復(fù)制
mysql> set sql_log_bin=0;? #停止寫入binlog開關(guān)，防止恢復(fù)表，出現(xiàn)寫入binlog日志。
mysql> use db1
mysql> source db1_userinfo.sql;
mysql> set sql_log_bin=1;??
mysql> start slave;
3.查看主節(jié)點(diǎn)的gtid
文章來源：http://www.zghlxwxcb.cn/news/detail-782875.html
總控，可以找到日志，看出是哪一張表被操作，如果是刪除操作還是需要備份該表進(jìn)行還原文章來源地址http://www.zghlxwxcb.cn/news/detail-782875.html
到了這里，關(guān)于mysql的gtid主從復(fù)制，從庫誤操作更新操作，的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
