随着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`值。