最近上游发布了MySQL 5.6.26版本,从Release Note来看,MySQL 5.6版本已经相当成熟,fix的bug数越来越少了。本文主要分析releae note上fix的相关bug,去除performance scheama、mac及windows平台、企业版、package相关内容。从本期开始,我们会在新版本发布时,在当月的月报上为大家做详细的版本Release Note分析。
InnoDB storage engine
问题描述
在类Unix平台上,当innodb_flush_method设置为O_DIRECT时,函数os_file_create_simple_no_error_handling_func
没有使用O_DIRECT方式打开数据文件。例如在函数fil_node_open_file
中,可能先以函数os_file_create_simple_no_error_handling_func
打开文件,确定文件的大小,然后关闭文件;再以os_file_create
打开数据文件,前者使用Buffered IO,后者使用DIRECT IO。这种混合使用可能引发性能问题。
根据man手册建议:
(Bug #21113036, Bug #76627)
解决
在函数os_file_create_simple_no_error_handling_func
中禁止OS Cache(函数os_file_set_nocache
)
补丁
b4daac21f52ced96c11632b83445111c0acede56
问题描述
在将一个脏页从非压缩page拷贝到压缩页后,在写page到文件时(buf_flush_write_block_low
),在设置压缩页的修改LSN之前先调用了函数page_zip_verify_checksum
,由于此时压缩页上的LSN为0,而计算出来的checksum也可能为0,此时page_zip_verify_checksum
认为要尝试写入一个空page,返回false,导致断言失败(Bug #21086723)。
解决
先设置LSN,再调用page_zip_verify_checksum
。
补丁
5b6041b2c7cbee8a1d917631d3a051122b8c4f8d
问题描述
当以如下序列执行时,实例会crash:
create database `b`;
use b;
create table `#mysql50#q.q` select 1;
drop database `b`;
在创建表时,发现非法的表名,表名被reset成一个空字符串,传递到引擎层就是”dbname/”, 而引擎层的数据词典定义中,是通过“dbname/tablename”这样的字符串来定位的,这就违反了数据词典的约定。 随后如果执行drop database, 会去遍历以db名作为前缀的数据词典项,触发crash。PS:即使重启实例,drop database,也无法执行清理操作,用户线程会不停的在drop db的逻辑里loop(Bug #19929435)。
解决
在引擎层拒绝创建空的表名。
补丁
8fd710e06024a890e08e35009da541194ca0e5a4
问题描述
在函数innobase_get_foreign_key_info
中,需要根据子表中存储的父表表名去打开父表,但子表上是根据系统字符集system_charset_info存储的,而innodb是使用my_charset_filename存储表名和库名,因此如果包含父表包含特殊字符,就会造成无法打开父表,导致报错。(Bug #21094069)
解决
将系统字符集的表名和库名转换成my_charset_filename格式(tablename_to_filename)。
补丁
1fae0d42c352908fed03e29db2b391a0d2969269
问题描述
* 当一个IO后台线程为了做ibuf merge,需要读入对应数据文件的bitmap page时(check 函数buf_page_io_complete
–> ibuf_merge_or_delete_for_page
),读取方式为同步读, space->n_pending_ops
递增;
* 另外一个用户线程准备删除对应的tablespace,因此将space->stop_new_ops
设置为true,并等待直到space->n_pending_ops
为0(fil_check_pending_operations
);
* 后台线程尝试读入ibuf bitmap page,但由于在fil_io
函数中,如果发现space->stop_new_ops
被设置,所有的读操作都被拒绝,直接返回DB_TABLESPACE_DELETED错误,但在函数ibuf_merge_or_delete_for_page
中总是认为ibuf bitmap page被成功读入内存,后面直接引用这个page(实际上是空指针),可能会导致实例crash。
解决
在进行fil_io时,如果表空间正在被删除(space->stop_new_ops
被设置为true),不允许异步读操作,但允许写操作和同步读操作。
补丁
3ba4563a757e07c3052c780b63e2626c78ca5c47
问题描述
当表上的索引存在前缀索引时(prefix index),对表进行export,再import tablespace可能会失败,并报Schema mismatch错误,错误码为ER_TABLE_SCHEMA_MISMATCH。test case见bug#76877 (Bug #20977779, Bug #76877)。原因是cfg文件和表的索引定义相匹配时逻辑错误,例如如下表:
CREATE TABLE t1 (c1 VARCHAR(128), PRIMARY KEY (c1(16))) ENGINE=InnoDB;
在索引对象中定义了4个列:(c1, prefix_len=16), (DB_TRX_ID), (DB_ROLL_PTR),(c1, prefix_len=0)。
cfg和表索引对象相比较时,其实两者是一样的,但cfg在取列时,如果存在相同列名的,总是取第一个,如上例,在比较第四个列的schema是否一致时,取的实际上是第一个,从而产生报错。
参考函数:row_import::match_index_columns
((Bug #20977779, Bug #76877))。
解决
一个列一个列的依次校验。
补丁:
db23392bac27ad3e84319229ee3db9921b734abd
问题描述
考虑如下场景:
- purge线程读取一个undo ,解析出对应的记录 (
row_purge
—>row_purge_parse_undo_rec
); - 先 purge 二级索引(
row_purge_remove_sec_if_poss
),再purge聚集索引(row_purge_remove_clust_if_poss
); - 当 purge 二级索引页时,需要检查二级索引记录是否可以被物理purge掉(
row_purge_remove_sec_if_poss_leaf
)。
参考函数:row_purge_poss_sec
can_delete = !row_purge_reposition_pcur(BTR_SEARCH_LEAF, node, &mtr)
|| !row_vers_old_has_index_entry(TRUE,
btr_pcur_get_rec(&node->pcur),
&mtr, index, entry,
node->roll_ptr, node->trx_id);
row_purge_reposition_pcur
定位到聚集索引上,node->found_clust
设置为true,定位到clust index上的cursor存储在node->pour上。
- 然后再检查二级索引记录是否被标记删除了,(
row_purge_remove_sec_if_poss_leaf
—>red_get_deleted_flag
),如果没有被标记删除,则报warning。
但是步骤3中,即时二级索引没有被标记删除,在函数row_purge_poss_sec
也返回了true,这是因为重新定位cursor的逻辑错误。
函数row_purge_reposition_pcur
:
if (node->found_clust) {
ibool found;
found = btr_pcur_restore_position(mode, &node->pcur, mtr);
return(found);
} else {
node->found_clust = row_search_on_row_ref(
&node->pcur, mode, node->table, node->ref, mtr);
if (node->found_clust) {
btr_pcur_store_position(&node->pcur, mtr);
}
}
return(node->found_clust);
考虑如下序列:
- purge Index1时,根据node->ref找到对应的聚集索引记录,node->found_clust设置为true,当前cursor存到node->pour中;
- 其他用户线程操作了聚集索引页,导致在purge index2时,restore position可能失败,因此返回false;
- 随后purge index2,发现node->found_clust为true,依旧用上次restore的position来作restore,依然失败;在函数
row_purge_reposition_pcur
返回false就认为对应的聚集索引不存在,然后就去尝试删除二级索引记录;但注意这次想purge的二级索引记录可能是一个新鲜插入的记录,并没有被delete mark,我们实际上需要根据node->ref重新定位。
解决
在函数row_purge_reposition_pcur
中,若是restore cursor失败,需要重置node->found_clust为false (Bug #19138298, Bug #70214, Bug #21126772, Bug #21065746)
补丁
982a157c71667040838def7a00d951ffc55eccbc
4b8304a9a41c8382d18e084608c33e5c27bec311
e59914034ab695035c3fe48f046a96bb98d53044
92b4683d59c066f099be1d283c7d61b00caeedb2
InnoDB 全文索引
问题描述
尝试为表上rebuild 全文索引,但表上已经有损坏的索引时,会触发assert。(Bug #20637494)
解决
抛出错误,提示用户先删掉损坏的索引。返回错误码为ER_INNODB_INDEX_CORRUPT。
补丁
4395ad1755c3ed86c4210f76001a76eb0a69b553
3bdb4573e9b25357eea2421647263216c36367cb
问题描述
构建full-text的表上存在隐藏的FTS_DOC_ID和唯一索引FTS_DOC_ID_INDEX(FTS_DOC_ID),当删除全文索引时,对应的隐藏列并没有删除,但在当前的逻辑中,如果存在FTS_DOC_ID,则不允许ONLINE DDL(Bug #20590013, Bug #76012)。
解决
当表上只有FTS_DOC_ID_INDEX和FTS_DOC_ID 但没有定义全文索引时,允许ONLINE DDL。这些隐藏列直到全表rebuild时才被删除。
补丁
5610e5354a8be6609b2fc2a37902961be26af3cf
InnoDB API/Memcached
问题描述ib_cursor_moveto
函数没有判断构建的tuple的列个数是否小于索引列个数,而是直接用索引列的个数来做遍历,可能导致段错误(Bug #21121197, Bug #77083)。
解决
加上对应的判断。
补丁:
d511b503353c1588e90907f59b947e31796c1fc1
问题描述ib_table_truncate
函数中,当truncate失败时,没有正确的释放事务对象,可能导致shutdown hang住。
解决:
总是释放事务对象。
补丁:
aeef8dc2c7af8be4f8ac91be6963e5252e8a9d3f
e0e1f02d97f54252c1e6ea386dc029560c9f7d08
问题描述ib_open_table_by_id
函数中,已经加了dict_sys->mutex
锁,但该函数中调用dict_table_open_on_id
传递的第二个参数为FALSE,认为没有持有mutex,属于基本的逻辑错误(Bug #21121084, Bug #77100)。
解决
调整传参。
补丁
a2353c5d7ff6430e853de435d007ac64d91fd17d
上面几个bug看起来都是非常“低级”的代码缺陷,这也侧面证明了InnoDB API接口在推出后社区用的人实在太少了,这三个Bug都是facebook的工程师提出的,很好奇他们会利用InnoDB API做些什么。
问题描述
InnoDB memcached plugin在处理unsigned NOT NULL类型时没有正确处理,导致返回的数据错误。
- 对于unsigned类型,对应的IB_COL_UNSIGNED = 2
- 对于NOT NULL类型,对应的IB_COL_NOT_NULL = 1
但是代码里很多地方都使用类似m_col->attr == IB_COL_UNSIGNED
,导致大量的逻辑错误(Bug #20535517, Bug #75864)。
解决
修改成m_col->attr & IB_COL_UNSIGNED
。
补丁:
6ff8d5d2940b9c9079e07641b2beb12e8dd84b38
复制
问题描述
当使用多线程复制时,执行STOP SLAVE需要等待所有的worker线程完成其各自的工作队列中的事务。如果Pending的事务很多,可能要等待很长时间才能完成STOP SLAVE,另外在STOP SLAVE的过程中,是无法SHOW SLAVE STATUS的,一种比较常见的场景就是大量的监控程序SQL堵塞堆积(Bug #75525, Bug #20369401)。
解决
解决方案是先找到任意worker线程中最新的commit的事务,确定一个上限位点,所有的worker线程执行到这个位置停止,剩下的事务暂时不执行。具体的:
- 执行STOP SLAVE,coordinator线程首先将所有worker线程的状态设置成STOP(
slave_stop_workers(rli, &mts_inited)
),并更新rli->max_updated_index
为最新的已经执行(或正在执行)的事务的group index(set_max_updated_index_on_stop
); - 所有worker的工作队列中索引序号小于等于
rli->max_updated_index
的事务都需要被执行完,否则worker状态设置为STOP_ACCEPTED,表示已经完成了max_updated_index 之前的事务,可以退出(set_max_updated_index_on_stop
); - coordinator线程等待所有worker线程退出,并做一次checkpoint(
slave_stop_workers
–>mts_checkpoint_routine
)。
但是上述方案并不能解决正在执行的大事务过慢的问题。
补丁
37f2e969bd36a7455e81ea2350685707bc859866
问题描述
MySQL使用InnoDB + binlog做XA的方式来进行crash recovery,但在之前的版本中如果写Binlog到磁盘发生了错误,group commit的逻辑并没有感知到这个错误,而是继续在引擎层提交事务,备库没有接收到对应的Binlog,导致主备数据不一致 (Bug #76795, Bug #20938915)。
解决
从MySQL 5.6.22版本开始,引入了一个新参数binlog_error_action (5.6.20及21版本叫做binlogging_impossible_mode),若设置为ABORT_SERVER,则在发生binlog写入错误时直接让实例退出,避免引发更大的错误;若设置为IGNORE_ERROR,则忽略本次写入失败,同时禁止Binlog记录,需要重启才能让binlog再次开启。
为了主备数据的强一致性,通常应该将binlog_error_action设置为ABORT_SERVER,这样在打开文件、rotate新文件、从IO Cache写binlog到文件出现磁盘错误时,都会退出实例。
补丁
3b6b4bf8c5d1bfada58678acebafdf6f813c2dfe
问题描述
relay_log_recovery参数打开时,备库在重启时就可以根据SQL线程执行到的位置重新拉binlog,这可以有效处理备库发生机器宕机导致relay log文件损坏的情况,无需人工去change master,在之前版本中,如果使用了多线程复制,是无法开启该特性的,在启动实例时会报如下错误:
实际上,如果开启了GTID,就无需关心各个worker线程之间的gap,通过备库的GTID集合充拉relay log即可(Bug #73397, Bug #19316063)。
解决
在重启recovery时检查是否开启了GTID。
补丁
fce558959bd0e5af1ae6aac3d8573db00c271dfd
问题描述
当两台备库错误的配置了相同的server_uuid,并指向同一个主库时,备库的IO线程会被频繁的断开并尝试重连。而在备库来看,并没有足够的信息提示产生重连的原因。
解决
这种场景下,主库会生产一个错误信息传递到备库,当备库接受到这样的错误信息时不再尝试重连。(Bug #72581, Bug #18731252)
补丁
751a3da76dfd66b92395f90f11fce6bd890c9db5
分区表
问题描述
bug被隐藏,无test case,对应release note:
解决
参考commit log.
补丁
6b0e6683416dc6f8274a460bd2512e7b037ec75f
优化器
小编对优化器模块代码理解不深,感兴趣的同学可以自行阅读对应的bug report及commit log,手动尝试复现bug。
问题描述
解决
补丁
bfba2338902a81927d116c30eaa1245eaea025c8
问题描述
解决
参考commit log.
补丁:
60c6920509516a1e05b855799479a59c27803191
b62c5daa646434290c9b2d1c9b162487cb8edf04
问题描述
解决
参考commit log.
补丁:
7a36c155ea3f484799c213a5be5a3deb464251dc
其他
问题描述
MySQL String库下的字符串处理问题,在cs_values
函数中,对字符串长度的处理存在缺陷,可能导致内存损坏(Bug #20359808)。
解决
调整长度判断。
补丁
1cdd3b832ae32d3c236869954f0c7a8a851ed94a
问题描述
当会话断开或者执行类似change user时,session status会merge到全局status中(add_to_status(&global_status_var, &status_var)
),但没有立刻对thd的status_var做reset,这时候另外一个session去查询global status时,会重复把这些session的status值加到全局。
解决
在THD::change_user
、THD::release_resources
函数中累加到全局status后,重置session的status。