【MySQL】【復(fù)制】利用slave_exec_mode處理復(fù)制過(guò)程中出現(xiàn)的1062與1032錯(cuò)誤

【MySQL】【復(fù)制】利用slave_exec_mode參數(shù)處理復(fù)制過(guò)程中出現(xiàn)的1062與1032錯(cuò)誤

背景：

? 今天張師兄在群里問(wèn)了主從之間出現(xiàn)1032錯(cuò)誤后，使用pt-slave-restart跳過(guò)后又出現(xiàn)了1062錯(cuò)誤，該如何快速處理。

問(wèn)題解析：

? 1032錯(cuò)誤：主庫(kù)傳遞過(guò)來(lái)的binlog中包含了刪除某些數(shù)據(jù)的語(yǔ)句，但在從庫(kù)中部分?jǐn)?shù)據(jù)或者全部這些數(shù)據(jù)被提前手工刪除了，或者根本就不存在。

? 1062錯(cuò)誤：主庫(kù)傳遞過(guò)來(lái)的binlog中包含了更新（或插入）某些數(shù)據(jù)的語(yǔ)句，但在從庫(kù)中部分?jǐn)?shù)據(jù)已經(jīng)存在，或者被其他的數(shù)據(jù)占據(jù)了唯一性索引的入口。

? 問(wèn)題出在binlog重放時(shí)是以一個(gè)事務(wù)作為一個(gè)原子單位進(jìn)行重放。正如原子中是由三個(gè)夸克組成一樣，一個(gè)事務(wù)一般也會(huì)由若干個(gè)event組成。一個(gè)event視為一條語(yǔ)句。

? 若主庫(kù)傳過(guò)來(lái)一個(gè)包含刪除三行數(shù)據(jù)（r1,r2,r3)的事務(wù)，但在從庫(kù)中只有兩個(gè)個(gè)對(duì)應(yīng)的行(r1,r2)。

begin;
delete from t1 where row=r3; #假設(shè)row列為唯一性索引
delete from t1 where row=r2;
delete from t1 where row=r1;
commit;

? 那么當(dāng)執(zhí)行第一條的時(shí)候，從庫(kù)就會(huì)報(bào)1032 delete a not exist row錯(cuò)誤。使用Pt-slave-restart --error-numbers=1032 就會(huì)把這整個(gè)事務(wù)都跳過(guò)去，導(dǎo)致該。下一次若從主庫(kù)傳來(lái)

begin;
insert into t1(row) values(r1,r2)
commit;

? 那么從庫(kù)執(zhí)行插入的時(shí)候肯定會(huì)報(bào)1062 duplicate entry錯(cuò)誤。

問(wèn)題處理：

方法一：

? 使用Pt-table-sync進(jìn)行主從數(shù)據(jù)同步，但是在雙主條件或者主庫(kù)相關(guān)表不停的更新的狀況下，這種數(shù)據(jù)同步會(huì)導(dǎo)致比較致命的數(shù)據(jù)混亂。

方法二：

? 使用slave_exec_mode參數(shù)。

? 先看下官方手冊(cè)描述：

? Controls how a slave thread resolves conflicts and errors during replication. IDEMPOTENT mode
causes suppression of duplicate-key and no-key-found errors; STRICT means no such suppression
takes place.
IDEMPOTENT mode is intended for use in multi-master replication, circular replication, and some
other special replication scenarios for NDB Cluster Replication

? 此參數(shù)最初作為在NDB模式中被引進(jìn)，后來(lái)在多主和環(huán)形復(fù)制都有用武之地。主要的作用就是在slave_exec_mode=‘IDEMPOTENT時(shí)，slave會(huì)忽略在插入時(shí)的遇到重復(fù)的唯一性索引節(jié)點(diǎn)和刪除時(shí)的未發(fā)現(xiàn)對(duì)應(yīng)記錄的復(fù)制錯(cuò)誤即1062和1032。但是，當(dāng)從庫(kù)從 主庫(kù)接收到了一條嘗試update一條自己不存在的記錄時(shí)還是會(huì)報(bào)錯(cuò)1032。

? 問(wèn)題到此就很簡(jiǎn)單了，應(yīng)進(jìn)行如下步驟：

stop slave;
SET GLOBAL  slave_exec_mode = 'IDEMPOTENT'
start slave;

? 再次show slave status\G 應(yīng)該可以看到從庫(kù)的復(fù)制SQL線程已經(jīng)恢復(fù)正常。

? 但是這畢竟是非常規(guī)手段，在執(zhí)行完后且主從一致后，應(yīng)抽空進(jìn)行數(shù)據(jù)校驗(yàn)。且不推薦作為默認(rèn)參數(shù)直接打開(kāi)。

附：

5.7.0以后可以將idempotent作為mysqld啟動(dòng)參數(shù)調(diào)用，即：mysqld --defaults-file =my.cnf --indempotent& 當(dāng)然，也可以將其寫(xiě)入my.cnf中。

? --idempotent
Tell the MySQL Server to use idempotent mode while processing updates; this causes suppression
of any duplicate-key or key-not-found errors that the server encounters in the current session while
processing updates. This option may prove useful whenever it is desirable or necessary to replay
one or more binary logs to a MySQL Server which may not contain all of the data to which the logs
refer.
The scope of effect for this option includes the current mysqlbinlog client and session only.
The --idempotent option was introduced in MySQL 5.7.0.

5.7.1以后可以引入了此參數(shù)的會(huì)話級(jí)別版 rbr_exec_mode，只對(duì)當(dāng)前會(huì)話生效，且限制行復(fù)制模式。

? rbr_exec_mode
This variable switches the server between IDEMPOTENT mode and STRICT mode. IDEMPOTENT
mode causes suppression of duplicate-key and no-key-found errors. This mode is useful when
replaying a row-based binary log on a server that causes conflicts with existing data. mysqlbinlog
uses this mode when you set the --idempotent option by writing the following to the output:
SET SESSION RBR_EXEC_MODE=IDEMPOTENT;

pt_slave_restart和skip_slave_errors跳過(guò)的結(jié)果不一樣
skip_slave_errors跳過(guò)時(shí)只跳過(guò)有問(wèn)題的語(yǔ)句
而pt_slave_restart跳過(guò)整個(gè)事務(wù)