作者：vivo 互聯網數據庫團隊 - Wei Haodong
本文介紹了 MySQL5.7 中常見的replace into 操作造成的主從auto_increment不一致現象，一旦觸發了主從切換，業務的正常插入操作會觸發主鍵衝突的報錯提示。
一、問題描述
1.1 問題現象
在 MySQL 5.7 版本中，REPLACE INTO 操作在表存在自增主鍵的情況下，可能會出現表的auto_increment值主從不一致現象，如果在此期間發生主從故障切換，當原來的slave節點變成了新的master節點，由於表的auto_increment值是小於原主庫的，當業務繼續寫入時，就會收到主鍵衝突的報錯提示。
相關報錯信息如下：
! 報錯提示
ERROR 1062 (23000): Duplicate entry 'XXX' for key 'PRIMARY'
1.2 影響評估
在業務邏輯中使用了Replace into,或者INSERT...ON DUPLICATE KEY UPDATE。
一旦出現了表的auto_increment值主從不一致現象，在出現MySQL主從故障切換後，業務的正常寫入會報主鍵衝突的錯誤，當auto_increment相差不多，或許在業務重試的時候會跳過報錯，但是auto_increment相差較多時，會超出業務重試的次數，這樣造成的影響會更大。
二、問題復現
2.1 環境搭建
這裏在測試環境中，搭建MySQL社區版 5.7 版本，一主一從的架構。
【OS】：CentOS Linux release 7.3
【MySQL】：社區版本 5.7
【主從架構】：一主一從
【庫表信息】：庫名：test2023
表名：test_autoincrement
表結構如下：
2.2 準備測試數據
正常情況下，插入一行數據，影響的行數是1。
此時查看主從節點表的autoincrement值，可以看到此時主從的AUTO_INCREMENT是一致的，都是4，即自增主鍵下一次申請的值是4。
2.3 問題復現模擬
2.3.1 模擬REPLACE INTO操作
MySQL [test2023]> REPLACE INTO test_autoincrement (name,uid) values('張三丰',1001);Query OK, 2 rows affected (0.01 sec)
這裏通過REPLACE INTO操作判斷，如果存在唯一ID爲1001的記錄，那麼將name字段的值更改爲"張三丰",可發現此時影響的行數是2。現在我們再次查看主從節點表的autoincrement值。
此時出現了主從節點表的AUTO_INCREMENT不一致現象。
2.3.2 模擬主從切換
由於是在測試環境，這裏就直接進行了主從關係的更改。
（1）停止當前slave節點的複製線程
MySQL [test2023]> stop slave;Query OK, 0 rows affected (0.08 sec)
（2）查看當前slave節點的Executed_Gtid_Set值
（3）重做主從關係
2.3.3 模擬業務正常寫入
MySQL [test2023]> insert into test_autoincrement(name,uid) select '趙六',1004;ERROR 1062 (23000): Duplicate entry '4' for key 'PRIMARY'
到這裏我們看到了預期的報錯現象，如果是正常業務系統，這裏的主從節點表的AUTO_INCREMENT可能會相差非常大，業務的正常插入就會持續報錯了。
意味着真實的操作是先做delete操作，然後再進行insert。
三、原因分析
3.1 爲什麼從庫節點的 autoincrement 沒有變化？
這裏可以看到REPLACE INTO操作對應的binlog日誌記錄其實是update操作，從庫節點在應用update操作時，發現命中數據時，對應的autoincrement是沒有變化的。
3.2 REPLACE INTO 操作的官方定義是什麼？
官方對於 REPLACE INTO 的定義如下：
摘選自
REPLACE works exactly like INSERT, except that if an old row in the table has the same value as a new row for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the new row is inserted. See Section 13.2.5, “INSERT Statement”.
REPLACE is a MySQL extension to the SQL standard. It either inserts, or deletes and inserts. For another MySQL extension to standard SQL—that either inserts or updates—see Section 13.2.5.2, “INSERT ... ON DUPLICATE KEY UPDATE Statement”.
這裏可以看到一張表包含主鍵或者唯一鍵的情況下，replace操作會判斷原有的數據行是否存在，如果存在的話，就先刪除舊的數據，然後進行insert操作，如果不存在的話，就和insert操作時一樣的。
第二段也提到了INSERT ... ON DUPLICATE KEY UPDATE Statement ，其實這個操作也會造成上面的主從autoincrement不一致現象，這裏就不展開討論了。
! Note
REPLACE makes sense only if a table has a PRIMARY KEY or UNIQUE index. Otherwise, it becomes equivalent to INSERT, because there is no index to be used to determine whether a new row duplicates another.
3.3 爲什麼REPLACE INTO操作在binlog日誌中記錄的是update操作？
這裏我們通過源碼文件sql_insert.cc和log_event.cc進行分析。
上述源碼中可以看到在主庫中replace 操作其實是insert 或者 delete + insert
The manual defines the REPLACE semantics that it is either an INSERT or DELETE(s) + INSERT;而 MySQL 在主從同步的binlog日誌中，將replace操作轉換爲update操作的條件爲：當發生衝突的鍵是最後一個唯一鍵，且沒有外鍵約束，且沒有觸發器，由於我們的測試表中是沒有外鍵約束，也沒有觸發器的，所以從庫接收到的binlog日誌中轉化爲update的條件即爲最後一個唯一鍵。
這裏，我們再進行測試一下（去掉表中的唯一索引uid）。
（1）創建新表
CREATE TABLE `test_autoincrement_2` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',`name` varchar(100) NOT NULL DEFAULT 'test' COMMENT '測試名字',PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4
（2）插入測試數據
（3）replace into 操作驗證主庫和從庫的AUTO_INCREMENT
MySQL [test2023]> REPLACE INTO test_autoincrement_2 (id,name) values(3,'鄭十');Query OK, 2 rows affected (0.08 sec)
這裏我們把id=3的這一行數據對應的name修改爲’鄭十’，可發現上述影響的行數是2。
再次驗證主庫和從庫的AUTO_INCREMENT，發現並沒有發生變化，還是4。
CREATE TABLE `test_autoincrement_2` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',`name` varchar(100) NOT NULL DEFAULT 'test' COMMENT '測試名字',PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4
（4）分析binlog日誌文件
總結：可發現binlog日誌記錄的同樣是update 操作。只是當表中除了主鍵外沒有額外的唯一鍵時，replace into的操作並不會觸發從庫的auto_increment的異常問題。比如上述的案例REPLACE INTO test_autoincrement_2 (id,name) values(3,'鄭十');，這裏僅更改了name字段，由‘吳九‘修改爲’鄭十’。但是主鍵id是沒有變化的，當然也就不需要再次使用auto_increment，這裏也可以看到主庫的auto_increment當然也沒有發現變化（當表中除了主鍵外含有額外的唯一鍵時，是會觸發申請auto_increment的），binlog接收的仍然是update操作，所以從庫的auto_increment也是沒有變化的，這樣就沒法造成auto_increment和主庫不一致的問題了。
四、解決方案
到這裏，我們是明白了replace into 會造成主從的auto_increment 不一致，但是怎麼去解決呢？
4.1 升級到 MySQL 8.0 版本
在 MySQL 8.0 版本中已將AUTO_INCREMENT值做了持久化，且在做更新操作時，會將表上的自增列被更新爲比auto_increment更大的值，auto_increment值也將被更新。
4.2 修改 AUTO_INCREMENT 值
線上環境可能已經有很多這種情況，在沒有觸發業務報錯的情況下，一般是很難發現這個隱患，如何在日常巡檢中找到這些問題纔是關鍵。
巡檢邏輯一：這裏可以通過巡檢判斷從庫的max(id) >= AUTO_INCREMENT的方式來找出已經存在問題的表信息。然後通過SQL語句：ALTER TABLE table_name AUTO_INCREMENT = new_value; 進行修改。
巡檢步驟可參考：
（1）僅檢測某從節點，包含auto_increment 屬性的表，過濾SQL如下：
select TABLE_SCHEMA,TABLE_NAME,AUTO_INCREMENT from information_schema.tables where table_schema not in ('information_schema','mysql','performance_schema','sys') AUTO_INCREMENTis not null \G（2）加鎖後讀表信息，語句如下：
① 給表加鎖
lock tables table_name write;②讀取數據和表auto_increment值進行比對
MAXID=select max(id) from table_name;AUTO_INCREMENT=select AUTO_INCREMENT from information_schema.tables where TABLE_NAME='t1' ;
③ 判斷條件
如果MAXID >= AUTO_INCREMENT , 判斷爲異常
巡檢邏輯二：可以在高可用切換的時候增加AUTO_INCREMENT值判斷，如果AUTO_INCREMENT值不一致，則不發生切換，不過這裏的slave節點AUTO_INCREMENT的值本身可能因爲延遲等問題，就會稍落後maste主節點，正常的巡檢還是有難度的，還有就是當MySQL主從切換觸發時，如果是因爲原主庫宕機了，不觸發切換也會有問題，所以還是需要提前儘快把這個隱患排除掉。
4.3 禁用 replace into 操作
業務側禁用replace into 或 insert ... on duplicate key update ,實現方式可以通過代碼邏輯來實現。
4.4 replace into操作的表不增加其他唯一索引
這裏其實實現還是有難度的，自增id是不可控的，業務一般是不會使用數據庫自帶的自增id。
五、問題總結
1. REPLACE INTO 操作在表存在自增主鍵且包含唯一索引的情況下，當出現數據衝突的時候，會觸發AUTO_INCREMENT在主從節點的不一致，一旦主從發生切換，就會造成業務的寫入報主鍵衝突的錯誤。解決建議：業務更改實現方式，避免使用replace into，或者使用MySQL8.0 及以上的版本來解決該問題。
2. 該問題是一個官方的BUG，不過並沒有在MySQL5.7的版本中得到修復 。
參考文獻：
END
猜你喜歡
本文分享自微信公衆號 - vivo互聯網技術（vivoVMIC）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。