mysql notee_【转载】MySQL5.6.27 Release Note解读（innodb及复制模块）

问题描述：

当一个表被驱逐并重新导入时，如果表的内容是空的(例如先插入大量数据，再一次全删除时，auto_increment不为0)，就会导致AUTO_INCREMENT的值被重置。(Bug #21454472, Bug #77743)

这是因为每次打开表时，总是通过计算表上记录最大自增列值的方式来重新设置，当表被打开时，如果没有数据，AUTO_INCREMENT就会被重置成最小值。

解决：

在驱逐表时，将这个表的AUTO_INCREMENT值存储在内存中(dict_sys->autoinc_map)，当表重新读入时，再恢复其AUTO_INCREMENT值。

这个Fix并不算一个完整的修复，当实例重启时，AUTO_INCREMENT依然会被重置(参阅bug#199)， RDS MYSQ已经Fix了这个bug，能够持久化自增列到物理文件中，在重启后不会丢失。

补丁：

问题描述：

Memcached的一段开启事务的代码在assert中调用，而根据assert的文档定义(

)，他的行为是未知的，受NDEBUG控制，可能assert会被定义成空函数，导致assert中的函数调用被忽略掉。这个bug在某些平台下可能极易触发。使用memcached的同学需要注意下。 (Bug #21239299, Bug #75199)

解决：

将函数调用从assert中移出来，只assert函数返回值。

补丁：

问题描述：

在ARM64平台上, GCC的内建的TAS操作函数__sync_lock_test_and_set

可能不准确，这和平台内存模型有关，锁的行为错误，导致进一步的数据损坏。(Bug #21102971, Bug #76135)

解决：

如果定义了__atomic_test_and_set(ptr, __ATOMIC_ACQUIRE)/ __atomic_clear(ptr, __ATOMIC_RELEASE)操作，则优先使用该函数进行变量设置，否则如果是X86平台，使用__sync_lock_test_and_set ，其他情况，在编译阶段报错。

补丁：

问题描述：

InnoDB shutdown时需要调用三次trx_purge操作，每次处理300个undo log page，最终处理900个undo log page，但是shutdown需要等待purge线程退出，，这可能需要耗费比较长的时间，shutdown会更耗时。(Bug #21040050)

解决：

1. 在每loop TRX_SYS_N_RSEGS个回滚段时，只调用一次trx_purge，之前的逻辑会调用两次

2. 在shutdown时一次处理的batch size临时调整到最多20,

补丁：

问题描述：

在READ COMMITED隔离级别下，并发replace into操作可能导致唯一二级索引损坏，唯一键约束失效。这主要是锁继承逻辑错误导致，具体的见之前的一篇月报分析http://mysql.taobao.org/monthly/2015/06/02/

解决：

调整锁继承逻辑，如果是类似REPLACE INTO这样的操作，需要进行锁继承。之前月报有详细分析。

补丁：

问题描述：

IBUF_BITMAP_FREE的值表示一个page可用的空闲空间数据范围, 这个值比实际的空闲空间值要大些，当INSERT操作是通过更新一个已存在但被标记删除的记录来完成时，InnoDB没有更新对应page在IBUF BITMAP中的IBUF_BITMAP_FREE值。

解决：更新bitmap

补丁：

问题描述：

当innodb_force_recovery大于3时，innodb在redo 被apply之前被设置成read only模式，导致无法恢复。另外从当前版本开始，当force recovery 大于3时，支持drop table，这可以协助将损坏的表清理掉，避免重复crash。

解决：

在代码中，增加了一个新的变量high_level_read_only，当srv_read_only_mode开启或者force recovery 大于3时，将该变量设置为true. 在除了DROP TABLE之外的DDL和DML执行时，会做检查。也就是说，force recovery 大于3时，drop table是唯一可以做的操作； innodb_read_only模式下，依然不允许所有变更操作。