背景：

今天無意當(dāng)中看到參數(shù)slave_exec_mode，從手冊里的說明看出該參數(shù)和MySQL復(fù)制相關(guān)，是可以動(dòng)態(tài)修改的變量，默認(rèn)是STRICT模式(嚴(yán)格模式)，可選值有IDEMPOTENT模式(冪等模式)。設(shè)置成IDEMPOTENT模式可以讓從庫避免1032(從庫上不存在的鍵)和1062(重復(fù)鍵，需要存在主鍵或則唯一鍵)的錯(cuò)誤，該模式只有在ROW EVENT的binlog模式下生效，在STATEMENT EVENT的binlog模式下無效。IDEMPOTENT模式主要用于多主復(fù)制和NDB CLUSTER的情況下，其他情況不建議使用。從上面的介紹來看，這個(gè)參數(shù)的讓從庫跳過指定的錯(cuò)誤，那問題來了：

1：和sql_slave_skip_counter 比，有什么好處？

2：和 slave-skip-errors = N比，有什么好處？

帶著這2個(gè)問題，本文來進(jìn)行相關(guān)的測試和說明。

環(huán)境：

MySQL版本：Percona MySQL 5.7

復(fù)制模式：ROW，沒有開啟GTID

測試：

① 1062 錯(cuò)誤：Could not execute ... event on table db.x; Duplicate entry 'xx' for key 'PRIMARY', Error_code: 1062;

主從上的測試表結(jié)構(gòu)：

CREATE TABLE`x` (

`id`int(11) NOT NULLAUTO_INCREMENT,PRIMARY KEY(`id`)

) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8

主從上的表記錄：

M：

select * fromx;+----+

| id |

+----+

| 2 |

| 3 |

+----+

2 rows in set (0.01 sec)

S：

select * fromx;+----+

| id |

+----+

| 1 |

| 2 |

| 3 |

+----+

3 rows in set (0.00 sec)

主從上的表記錄本來就不一致了，主上缺少了id=1的記錄。

此時(shí)從上的slave_exec_mode為默認(rèn)的STRICT模式：

show variables like 'slave_exec_mode';+-----------------+--------+

| Variable_name | Value |

+-----------------+--------+

| slave_exec_mode | STRICT |

+-----------------+--------+

1 row in set (0.00 sec)

M上的binlog模式為：

show variables like 'binlog_format'; +---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW |

+---------------+-------+

1 row in set (0.00 sec)

在M上執(zhí)行：

insert into x values(1),(4),(5);

Query OK,3 rows affected (0.00sec)

Records:3 Duplicates: 0 Warnings: 0

因?yàn)閺纳弦呀?jīng)存在了id=1的記錄，此時(shí)從的復(fù)制就報(bào)了1062的錯(cuò)誤:

Last_SQL_Errno: 1062Last_SQL_Error: Couldnot execute Write_rows event on table dba_test.x; Duplicate entry '1' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin-3306.000006, end_log_pos 7124

出現(xiàn)這個(gè)錯(cuò)誤時(shí)，大家的一致做法就是執(zhí)行：sql_slave_skip_counter=N。關(guān)于該參數(shù)的說明可以看

1、set global sql_slave_skip_counter=N中的N是指跳過N個(gè)event2、最好記的是N被設(shè)置為1時(shí)，效果跳過下一個(gè)事務(wù)。3、跳過第N個(gè)event后，位置若剛好落在一個(gè)事務(wù)內(nèi)部，則會(huì)跳過這整個(gè)事務(wù)4、一個(gè)insert/update/delete不一定只對應(yīng)一個(gè)event，由引擎和日志格式?jīng)Q定

sql_slave_skip_counter的單位是“event”，很多人認(rèn)為該參數(shù)的單位是“事務(wù)”，其實(shí)是錯(cuò)誤的，因?yàn)橐粋€(gè)事務(wù)里包含了多個(gè)event，跳過N個(gè)可能還是在同一個(gè)事務(wù)當(dāng)中。對于上面出現(xiàn)1062的錯(cuò)誤，把N設(shè)置成1～4效果是一樣的，都是跳過一個(gè)事務(wù)。因?yàn)閳?zhí)行的SQL生成了4個(gè)event：

show binlog events in 'mysql-bin-3306.000006' from 6950;+-----------------------+------+------------+-----------+-------------+---------------------------------+

| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |

+-----------------------+------+------------+-----------+-------------+---------------------------------+

| mysql-bin-3306.000006 | 6950 | Query | 169 | 7026 | BEGIN |

| mysql-bin-3306.000006 | 7026 | Table_map | 169 | 7074 | table_id: 707 (dba_test.x) |

| mysql-bin-3306.000006 | 7074 | Write_rows | 169 | 7124 | table_id: 707 flags: STMT_END_F |

| mysql-bin-3306.000006 | 7124 | Xid | 169 | 7155 | COMMIT /*xid=74803*/ |

+-----------------------+------+------------+-----------+-------------+---------------------------------+

4 rows in set (0.00 sec)

所以處理該錯(cuò)誤的方法有：

1：skip_slavesql_slave_skip_counter

stop slave; Query OK, 0 rows affected (0.00sec)set global sql_slave_skip_counter=[1-4];

Query OK,0 rows affected (0.00sec)

start slave;

Query OK,0 rows affected (0.00 sec)

2：在配置文件里指定slave-skip-errors=1062(需要重啟)

這2種方法都能讓復(fù)制恢復(fù)正常，但是會(huì)讓主從數(shù)據(jù)不一致(謹(jǐn)慎使用)，讓從庫丟失了id=4和5的記錄。并且第2種方法還需要重啟數(shù)據(jù)庫，這時(shí)本文介紹的slave_exec_mode參數(shù)就派上用場了。在從庫上設(shè)置該參數(shù)：

set global slave_exec_mode='IDEMPOTENT';

Query OK,0 rows affected (0.00sec)

stop slave; Query OK,0 rows affected (0.00sec)

start slave;

Query OK,0 rows affected (0.00 sec)

同樣在主上執(zhí)行：

insert into x values(1),(4),(5);

可以驚喜的發(fā)現(xiàn)主從數(shù)據(jù)是同步的，沒有出現(xiàn)復(fù)制異常：

M：select * from x; +----+

| id |

+----+

| 1 |

| 2 |

| 3 |

| 4 |

| 5 |

+----+

5 rows in set (0.00sec)

S：select * from x; +----+

| id |

+----+

| 1 |

| 2 |

| 3 |

| 4 |

| 5 |

+----+

5 rows in set (0.01 sec)

上面的測試可以看到，參數(shù)設(shè)置成slave_exec_mode='IDEMPOTENT' 后，可以跳過出一個(gè)錯(cuò)誤的event。

② 1032錯(cuò)誤：Could not execute ... event on table db.x; Can't find record in 'x', Error_code: 1032;

這個(gè)錯(cuò)誤的出現(xiàn)是因?yàn)镽OW模式下的復(fù)制，對數(shù)據(jù)的一致性有了很嚴(yán)的要求，具體的可以看MySQL Binlog 【ROW】和【STATEMENT】選擇

主從上的測試表結(jié)構(gòu)：

CREATE TABLE`x` (

`id` int(11) NOT NULLAUTO_INCREMENT,

PRIMARY KEY(`id`)

) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8

主從上的表記錄：

M：

select * from x; +----+

| id |

+----+

| 1 |

| 2 |

| 3 |

+----+

3 rows in set (0.00 sec)

S：

select * fromx;

+----+

| id |

+----+

| 1 || 3 |

+----+

2rows in set (0.00 sec)

主從上的表記錄本來就不一致了，從上缺少了id=2的記錄。此時(shí)從上的slave_exec_mode為默認(rèn)的STRICT模式：

show variables like 'slave_exec_mode';

+-----------------+--------+

| Variable_name | Value |

+-----------------+--------+

| slave_exec_mode | STRICT |

+-----------------+--------+

1 row in set (0.00 sec)

M上的binlog模式為：

show variables like 'binlog_format'; +---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW |

+---------------+-------+

1 row in set (0.00 sec)

在M上執(zhí)行：

BEGIN;INSERT INTO x SELECT 4;DELETE FROM x WHERE id = 2;INSERT INTO x SELECT 5;COMMIT;

因?yàn)閺纳喜淮嬖诹薸d=2的記錄，此時(shí)從的復(fù)制就報(bào)了1032的錯(cuò)誤:

Last_SQL_Errno: 1032Last_SQL_Error: Couldnot execute Delete_rows event on table dba_test.x; Can't find record in'x', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin-3306.000006, end_log_pos 12102

同樣的，在上面測試中說明的2種方法可以讓復(fù)制正常，但是數(shù)據(jù)也一樣會(huì)丟失。丟失了id=4和5的記錄，繼續(xù)在從庫上設(shè)置該參數(shù)：

set global slave_exec_mode='IDEMPOTENT';

Query OK,0 rows affected (0.00sec)

stop slave; Query OK,0 rows affected (0.00sec)

start slave;

Query OK,0 rows affected (0.00 sec)

在M上執(zhí)行同樣的操作：

BEGIN;INSERT INTO x SELECT 4;DELETE FROM x WHERE id = 2;INSERT INTO x SELECT 5;COMMIT;

也可以驚喜的發(fā)現(xiàn)主從數(shù)據(jù)是同步的，沒有出現(xiàn)復(fù)制異常。

注意：

總結(jié)：

對于上面的測試總結(jié)，針對slave_exec_mode參數(shù)，它可以跳過1062和1032的錯(cuò)誤，并且不影響同一個(gè)事務(wù)中正常的數(shù)據(jù)執(zhí)行。如果是多個(gè)SQL組成的事務(wù)，則可以跳過有問題的event。

看著這個(gè)參數(shù)很不錯(cuò)，但手冊上說明不建議在普通的復(fù)制環(huán)境中開啟。對于NDB以外的存儲(chǔ)引擎，只有在確定可以安全地忽略重復(fù)鍵錯(cuò)誤和沒有鍵的錯(cuò)誤時(shí)，才應(yīng)使用IDEMPOTENT模式。這參數(shù)是專門針對NBD Cluster進(jìn)行設(shè)計(jì)的，NBD Cluster模式下，該參數(shù)只能設(shè)置成IDEMPOTENT模式。所以要根據(jù)自己的應(yīng)用場景來決定，正常情況下，主從是一致的，有任何錯(cuò)誤發(fā)生都要報(bào)錯(cuò)，不過在做特殊處理時(shí)，可以臨時(shí)開啟。

另外在GTID模式下的復(fù)制，sql_slave_skip_counter是不支持的，該模式下的復(fù)制可以自行測試。

總結(jié)

以上是生活随笔為你收集整理的mysql变量 exec_MySQL slave_exec_mode 参数说明的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。