隨著RDS MySQL用戶越來越多，隱藏很久很深的bug也逐漸被挖出來了，下面分享一下最近遇到的三例bug，都是官方版本存在的。 ## trigger/function中drop temporary table導致slave中斷 只有5.6受到影響。 復現步驟 ~~~ 打開gtid_mode=ON create function `test_func_1` () returns varchar(30) charset utf8 begin drop temporary table if exists test_func_1; drop temporary table if exists test_func_2; return "hello"; end; select test_func_1(); ~~~ 原因分析 function/trigger和procedure不同，不能單獨執行，必須依賴statement才能存在，這樣就決定了 function/trigger 的事務邊界必須由statement來定義，所以`create function/trigger`的時候，會進行檢測body中是否有事務邊界定義。比如，如果有commit/rollback，或者會引起隱式提交的DDL語句，那么就會報以下錯誤： ~~~ 1422 - Explicit or implicit commit is not allowed in stored function or trigger. ~~~ MySQL 5.5為什么會成功？ 因為`drop temporary table`是一個比較特殊的語句，雖然是DDL語句，但不會隱式提交，所以進行了特殊處理，可以使用。 MySQL 5.6 為什么主庫會成功，備庫會失敗呢？ 在打開gtid_mode的情況下，gtid有一個特殊的限制，不能在事務的過程中進行`drop temporary table`。如果要使用，必須為`drop temporary table`獨立分配一個GTID。 復現方法中的function在主庫執行的時候，產生的binlog event如下： ~~~ | master-bin.000001 | 580 | Gtid | 1 | 628 | SET @@SESSION.GTID_NEXT= 'cfef3544-1327-11e5-8a6f-2c44fd7a5210:2' | | master-bin.000001 | 628 | Query | 1 | 779 | DROP TEMPORARY TABLE IF EXISTS `test`.`test_func_1` /* generated by server */ | | master-bin.000001 | 779 | Query | 1 | 930 | DROP TEMPORARY TABLE IF EXISTS `test`.`test_func_2` /* generated by server */ | ~~~ 而這樣的event在備庫slave線程執行的時候，不滿足gtid對于`drop temproary table`的要求，所以報錯。 修復方法 既然gtid_mode=on的時候，`drop temproary table`必須要分配一個gtid，那么也就意味著它雖然不會隱式提交，但還是定義了事務邊界。修復方法就是就在`gtid_pre_statement_checks`的時候，對于這樣的情況就拒絕執行。 ## drop帶有中文表名的語句在備庫執行失敗 5.1、5.5、5.6都受影響。 復現步驟 ~~~ use test; set names gbk; create table test.`t_測試_table`(id int); drop table test.`t_測試_table`; ~~~ 原因分析 首先環境設置: ~~~ set names gbk; create table test.`t_測試_table`(id int); ~~~ 牽涉到的字符集如下: ~~~ session環境: gbk query串: gbk 表名和文件名: system_charset query_event: gdk drop table test.`t_測試_table`： session環境: gbk query串: gbk 表名和文件名: system_charset query_event: system_charset ~~~ 因為`drop table`的query event是/* generated by server */，在主庫生成的時候使用的字符集為system_charset，而在備庫執行的時候，需要初始化session環境為主庫帶過來是gbk，而event本身是system_charset的，導致event和session環境的charset不一致，無法找到表而slave中斷。 修復方法 對于/* generated by server */的event，不沿用session的字符集，而是使用主庫產生event時用的字符集。 ## 帶有auto_increment字段的表轉成archive引擎報錯 5.1、5.5、5.6都受影響。 復現步驟 ~~~ create table test.t(id int primary key auto_increment, col1 int) engine=innodb; insert into test.t values(1, 2); insert into test.t values(2, 2); commit; alter table test.t engine= archive; ERROR 1022 (23000): Can't write; duplicate key in table '#sql-db11_2bfaa ~~~ 原因分析 archive是一個歸檔引擎，在寫入的時候，必須按照遞增順序，也就是不能寫入一個比當前pk小的記錄，引擎層做了硬編碼限制: ~~~ /* We don't support decremening auto_increment. They make the performance just cry. */ if (temp_auto <= share->archive_write.auto_increment && mkey->flags & HA_NOSAME) { rc= HA_ERR_FOUND_DUPP_KEY; goto error; } ~~~ 而alter的過程中，因為沒有指定`auto_increment`的值，所以`auto_increment`會從原表中繼承過來，也就是等于2，而在copy數據的時候，先插入pk=1的記錄，發現比當前`auto_increment`值小，就報了上面的錯誤。 修復方法 語句`alter table t engine=archive`，在轉換成archive引擎的時候，如果沒有指定`auto_increment`的值的時候，系統默認指定成0， 而不是沿用原表的當前`auto_increment`值。