主頁(yè) > 知識(shí)庫(kù) > MySQL中slave_exec_mode參數(shù)詳解

MySQL中slave_exec_mode參數(shù)詳解

熱門標(biāo)簽:甘孜電話機(jī)器人廠家 哈爾濱crm外呼系統(tǒng)價(jià)格 凱立德科技館地圖標(biāo)注 做地圖標(biāo)注都需要什么工具 西安400電話在哪里辦理 銀川電銷外呼系統(tǒng)定制 中科嘉智人工智能電銷機(jī)器人 電銷機(jī)器人好品牌門薩維l 上海智能外呼系統(tǒng)需要多少錢

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

1:和 sql_slave_skip_counter 比,有什么好處?

2:和 slave-skip-errors = N比,有什么好處?

帶著這2個(gè)問(wèn)題,本文來(lái)進(jìn)行相關(guān)的測(cè)試和說(shuō)明。 

環(huán)境:

MySQL版本:Percona MySQL 5.7

復(fù)制模式:ROW,沒(méi)有開啟GTID

測(cè)試:

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

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

CREATE TABLE `x` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8

主從上的表記錄:

M:

select * from x;
+----+
| id |
+----+
| 2 |
| 3 |
+----+
2 rows in set (0.01 sec)

S:

select * from x;
+----+
| id |
+----+
| 1 |
| 2 |
| 3 |
+----+
3 rows in set (0.00 sec)

主從上的表記錄本來(lái)就不一致了,主上缺少了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.00 sec)
Records: 3 Duplicates: 0 Warnings: 0

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

Last_SQL_Errno: 1062
Last_SQL_Error: Could not 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。

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

sql_slave_skip_counter的單位是“event”,很多人認(rèn)為該參數(shù)的單位是“事務(wù)”,其實(shí)是錯(cuò)誤的,因?yàn)橐粋€(gè)事務(wù)里包含了多個(gè)event,跳過(guò)N個(gè)可能還是在同一個(gè)事務(wù)當(dāng)中。對(duì)于上面出現(xiàn)1062的錯(cuò)誤,把N設(shè)置成1~4效果是一樣的,都是跳過(guò)一個(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.00 sec)
set global sql_slave_skip_counter=[1-4];
Query OK, 0 rows affected (0.00 sec)
start slave;
Query OK, 0 rows affected (0.00 sec)

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

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

set global slave_exec_mode='IDEMPOTENT';
Query OK, 0 rows affected (0.00 sec)
stop slave;                                                                   Query OK, 0 rows affected (0.00 sec)
start slave;
Query OK, 0 rows affected (0.00 sec)

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

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

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

M:
select * from x;                                                                +----+
| id |
+----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+----+
5 rows in set (0.00 sec)

S:
select * from x;                                                                +----+
| id |
+----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+----+
5 rows in set (0.01 sec)

上面的測(cè)試可以看到,參數(shù)設(shè)置成slave_exec_mode='IDEMPOTENT' 后,可以跳過(guò)出一個(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ù)制,對(duì)數(shù)據(jù)的一致性有了很嚴(yán)的要求

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

CREATE TABLE `x` (
 `id` int(11) NOT NULL AUTO_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 * from x;
+----+
| id |
+----+
| 1 |
| 3 |
+----+
2 rows in set (0.00 sec)

主從上的表記錄本來(lái)就不一致了,從上缺少了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: 1032
Last_SQL_Error: Could not 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

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

set global slave_exec_mode='IDEMPOTENT';
Query OK, 0 rows affected (0.00 sec)
stop slave;                                                                   Query OK, 0 rows affected (0.00 sec)
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ù)是同步的,沒(méi)有出現(xiàn)復(fù)制異常。

注意:slave_exec_mode='IDEMPOTENT'不能對(duì)DDL操作冪等,并且也不能對(duì)字段長(zhǎng)度不同導(dǎo)致的錯(cuò)誤進(jìn)行冪等,如把例子中的從庫(kù)表的id字段類型int改成bigint。并且只能在binlog_format為ROW的模式下使用,而且只能對(duì)1032和1062進(jìn)行冪等模式。

總結(jié):

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

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

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

您可能感興趣的文章:
  • mysql同步問(wèn)題之Slave延遲很大優(yōu)化方法
  • 解決MySQL中的Slave延遲問(wèn)題的基本教程
  • MySQL中slave監(jiān)控的延遲情況分析
  • mysql 主從數(shù)據(jù)不一致,提示: Slave_SQL_Running: No 的解決方法
  • 記一次MySQL Slave庫(kù)恢復(fù)實(shí)戰(zhàn)記錄
  • Mysql主從數(shù)據(jù)庫(kù)(Master/Slave)同步配置與常見錯(cuò)誤
  • MySQL5.6 數(shù)據(jù)庫(kù)主從同步安裝與配置詳解(Master/Slave)
  • MySQL Slave 觸發(fā) oom-killer解決方法
  • MySQL slave 延遲一列 外鍵檢查和自增加鎖

標(biāo)簽:浙江 平頂山 四川 濮陽(yáng) 安康 安徽 山南 那曲

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《MySQL中slave_exec_mode參數(shù)詳解》,本文關(guān)鍵詞  MySQL,中,slave,exec,mode,參數(shù),;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《MySQL中slave_exec_mode參數(shù)詳解》相關(guān)的同類信息!
  • 本頁(yè)收集關(guān)于MySQL中slave_exec_mode參數(shù)詳解的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章