背景

你是否曾为Error on rename of './test/#sql-78fd_780371' to './test/t2' (errno: 150)这样的错误而不解,如stackoverflow上的这个问题

下面我们来复现下:

  1. drop table t2;
  2. drop table t1;
  3. create table t1(c1 int primary key, c2 int);
  4. create table t2(c1 int primary key, c2 int , constraint fk foreign key (c2) references t1(c1)) engine=innodb;
  5. //删外键所引用的列
  6. alter table t2 drop c2;
  7. //删不存在的外键
  8. alter table t2 drop foreign key idx1;

5.5的表现

  1. mysql> alter table t2 drop c2;
  2. ERROR 1025 (HY000): Error on rename of './test/#sql-78fd_780371' to './test/t2' (errno: 150)
  3. mysql> alter table t2 drop foreign key idx1;
  4. ERROR 1025 (HY000): Error on rename of './test/t2' to './test/#sql2-78fd-780371' (errno: 152)

5.6的表现

  1. mysql> alter table t2 drop c2;
  2. ERROR 1553 (HY000): Cannot drop index 'fk': needed in a foreign key constraint
  3. mysql> alter table t2 drop foreign key idx1;
  4. ERROR 1091 (42000): Can't DROP 'idx1'; check that column/key exists

很明显5.6的报错信息更精确些,5.5的报错太不人性化了,容易造成误解。

它们差别在于5.6的报错处理在语义分析阶段,精准的定位了错误信息。

  1. mysql_alter_table
  2. |=>mysql_inplace_alter_table
  3. |==>ha_innobase::prepare_inplace_alter_table
  4. |===>innobase_check_foreign_key_index

而5.5的报错处理在执行阶段。

我们先来看看5.5的执行流程:

  1. mysql_alter_table
  2. |=>mysql_create_table_no_lock //创建临时表tmp_table1,其结构和原表类似,但不包括外键信息
  3. |==>rea_create_table
  4. |=>copy_data_between_tables //将原表数据copy到tmp_table1
  5. |=>mysql_rename_table //将原表重命名tmp_table2,但不重命名外键涉及的表信息
  6. |==> row_rename_table_for_mysql //修改字典表
  7. |=>mysql_rename_table //将临时表tmp_table1重命名回原表
  8. |==>row_rename_table_for_mysql //修改字典表
  9. |===>dict_load_foreigns //这里通过从数据字段加载外键信息来检查外键索引是否存在,外键索引列是否一致.

dict_load_foreigns:这个函数由于承担的责任太多,只要发现错误,就笼统的抛出Error on rename of 'xxxx' to 'xxxx' (errno: xxx)的错误.

外键bug

我们来看一个外键相关的bug77467

  1. Alter table reply
  2. change blogId topicId int(11) NOT NULL,
  3. drop index userId,
  4. drop foreign key reply_ibfk_2;

bug中这个DDL虽然执行失败了,但实际上foreign key reply_ibfk_2被删除了。这个bug在单机环境下影响不大,但在主备环境下由于DDL执行失败并没有记binlog,从而导致主备表结构不一致。这个bug只出现在5.6以前的版本中,5.6是OK的

bug分析

我们来看看5.5的流程:

  1. mysql_alter_table
  2. |=>mysql_create_table_no_lock //创建临时表tmp_table1,其结构和原表类似,但不包括外键信息
  3. |==>rea_create_table
  4. |=>copy_data_between_tables //将原表数据copy到tmp_table1
  5. |=>mysql_rename_table //将原表重命名tmp_table2,但不重命名外键涉及的表信息,同时删除原表的外键reply_ibfk_2
  6. |==> row_rename_table_for_mysql //修改字典表
  7. |=>mysql_rename_table //将临时表tmp_table1重命名回原表
  8. |==>row_rename_table_for_mysql //修改字典表
  9. |===>dict_load_foreigns //这里通过从数据字段加载外键信息来检查外键索引是否存在,外键索引列是否一致.检查发现index userId不存在,出现错误
  10. |===>trx_rollback_to_savepoint //出现错误回滚之前的修改

出错回滚之前的修改,预期是回滚删除外键reply_ibfk_2,但是删除外键reply_ibfk_2操作在第一次mysql_rename_table中,属于一个事务,而回滚操作在第二次mysql_rename_table中,属于另一个事务,因此回滚没有成功。

那么5.6为什么没有出现这种错误呢?5.6在语义分析的时候就发现错误,还没来得及删外键就已经报错返回了。

bug修复

5.5修复方法,将删外键的操作放到第二次mysql_rename_table中进行,如果出现错误就可以顺利的回滚了。当然,还是5.6的做法比较好。