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

新功能

 

问题描述(Bug #18871046, Bug #72811)：

主要为了解决一个比较“古老”的MySQL在NUMA架构下的“swap insanity”问题，其表现为尽管为InnoDB buffer pool分配了足够多的内存，但依然会产生swap。而swap对数据库系统性能而言是比较致命的。

当我们配置的buffer pool超过单个node的内存时，例如总共64GB内存，每个节点32GB，分配buffer pool为40GB，默认情况下，会先用满node 0，再在node1上分配8GB内存。如果绑定到node 0上的线程需要申请新的内存时，不是从node1上申请（还有24GB空余），而是swap node0的内存，再做申请。

这个问题在社区讨论了很久，大神Jeremy Cole 对该问题有写博客做过详细的介绍（http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/）

解决：

增加了一个只读的新参数innodb_numa_interleave选项，当开启该选项，可以允许在NUMA架构下采取交叉分配内存的方式。

在启动MySQL时，采用MPOL_INTERLEAVE方式分配内存，如上例，在启动时每个node上分配20GB内存，保证每个node依然有空闲内存可用；在完成InnoDB buffer pool内存分配后，再将内存分配策略设置为MPOL_DEFAULT，之后的线程申请内存，都在各自的节点完成。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

补丁：

 

 

 

 

 

 

 

https://github.com/mysql/mysql-server/commit/242fa2c92de304637e794e531df1f1b86b8d1dee

 

 

 

 

 

 

 

https://github.com/mysql/mysql-server/commit/d2578b57ba7d90a00281ae124a1cd6c83193f62a

 

 

 

 

 

 

 

 

InnoDB bugfix

问题描述：

 

当一个表被驱逐并重新导入时，如果表的内容是空的（例如先插入大量数据，再一次全删除时，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，能够持久化自增列到物理文件中，在重启后不会丢失。

补丁：

https://github.com/mysql/mysql-server/commit/d404923aad4693dc152d02461f858d7ef218c336

 

问题描述：

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

http://man7.org/linux/man-pages/man3/assert.3.html

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

 

 

 

 

 

 

 

解决：

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

补丁：

https://github.com/mysql/mysql-server/commit/db5dc6fd3abe855685a554bc3c555b1b63914b60

问题描述：

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

 

 

 

 

 

 

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

 

 

 

 

 

 

 

该bug最初从MariaDB爆出，参考MDEV-6615 https://mariadb.atlassian.net/browse/MDEV-6615

 

解决：

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

补丁：

https://github.com/mysql/mysql-server/commit/f59d68eeae37338d7b25f2571407e763fa897e15

 

问题描述：

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,

 

补丁：

https://github.com/mysql/mysql-server/commit/3e8202ff443909e93231d453a3f1560b5a5ce3cb

 

问题描述：

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

解决：

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

补丁：

https://github.com/mysql/mysql-server/commit/608efca4c4e4afa1ffea251abda675fcc06efc69

 

 

问题描述：

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

 

解决：更新bitmap

补丁：

https://github.com/mysql/mysql-server/commit/641ab6f36813516255738ba25d3c6b721189832e

 

问题描述：

当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模式下，依然不允许所有变更操作。

 

补丁：

https://github.com/mysql/mysql-server/commit/e5cb1d5adaa603a88277f03fe37cb729d77e8ff6

 

复制

 

本次版本更新修复了大量的复制bug

 

问题描述：

如果一个事务在备库apply时需要等待行锁超时，并且repositories设置为table模式，重试时可能触发断言错误。 因为在确定重试时，事务状态依然是active的，再次调用global_init_info函数会去开启一个新的事务，触发断言（修复BUG16533802 引入的regression）

 

解决：

在超时重试之前调用rli->cleanup_context(thd, 1)，将当前事务完全回滚掉，恢复到非active状态。

 

补丁:

 https://github.com/mysql/mysql-server/commit/52db41e94ec7fdd1a01344285b9701c20715a92a

 

 

问题描述：

当使用STATEMENT模式时，单条SQL更新多个表时，一个事务可能被错误的记录到binlog中。

如下所示：

CREATE TABLE t1(c1 int) ENGINE=InnoDB;
CREATE TABLE t2(c1 int) ENGINE=InnoDB;set session binlog_format=’STATEMENT';START TRANSACTION;
UPDATE t1,t2 SET t1.c1 = 0;
SAVEPOINT sp1;

UPDATE t1,t2 SET t1.c1 = 0;
SAVEPOINT sp2;

​COMMIT;

 

binlog中的记录为：

| master-bin.000001 |  229 | Query       |         1 |         340 | use `test`; CREATE TABLE t1(c1 int) ENGINE=InnoDB |
| master-bin.000001 |  340 | Query       |         1 |         451 | use `test`; CREATE TABLE t2(c1 int) ENGINE=InnoDB |
| master-bin.000001 |  451 | Query       |         1 |         539 | BEGIN                                             |
| master-bin.000001 |  539 | Query       |         1 |         648 | use `test`; UPDATE t1,t2 SET t1.c1 = 0            |
| master-bin.000001 |  648 | Query       |         1 |         737 | COMMIT                                            |
| master-bin.000001 |  737 | Query       |         1 |         825 | BEGIN                                             |
| master-bin.000001 |  825 | Query       |         1 |         934 | use `test`; UPDATE t1,t2 SET t1.c1 = 0            |
| master-bin.000001 |  934 | Query       |         1 |        1023 | COMMIT                                            |
| master-bin.000001 | 1023 | Query       |         1 |        1095 | BEGIN                                             |
| master-bin.000001 | 1095 | Query       |         1 |        1177 | SAVEPOINT `sp1`                                   |
| master-bin.000001 | 1177 | Query       |         1 |        1259 | SAVEPOINT `sp2`                                   |
| master-bin.000001 | 1259 | Query       |         1 |        1332 | COMMIT                                            |
+——————-+——+————-+———–+————-+—————————————————+

 

这是因为在决定写binlog cache时，错误的写到stmt_cache中(即时更新的都是事务表)，因此在执行两条update时都单独写入到Binlog中。并最后写入了两个savepoint语句。

 

(Bug #16621582, Bug #21349028)

 

 

解决：

如果是事务表，写到trx_cache中

 

补丁：

https://github.com/mysql/mysql-server/commit/507051d967b134d7f29be759742d132423da601f

 

 

问题描述：

当dump线程在dump一个非活跃的binlog时被kill掉时，

本该退出这个日志中的某些事件可能被忽略掉，导致备库的数据丢失。这是修复Bug#19975697时引入的退化，影响5.6.24之后的版本

 

在发送Binlog时，有两个循环：1.内循环遍历单个binlog文件；2.外循环在文件间进行切换。内循环发现被kill掉后，进入外循环的逻辑，没有检查thd的kill标记，而是继续下面的工作，可能导致当前文件中剩余的log被忽略

 

(Bug #78337, Bug #21816399)

 

解决：

在退出内循环后，立刻检查kill标记，如果线程被Kill了，则dump线程退出。

 

补丁：

https://github.com/mysql/mysql-server/commit/0911fe2e28da2778d5385a8c7f93307f64bd807b

 

 

问题描述:

trigger中存在savepoint和rollback to savepoint可能触发断言失败(debug版本)，或者错误日志中报如下错误，复制中断：

[ERROR] Slave SQL for channel ”: Could not execute Write_rows event on table test.t3; Unknown error, Error_code: 1105; handler error HA_ERR_GENERIC; the event’s master log master-bin.000001, end_log_pos 1553, Error_code: 1105

 

我们执行bug#76727中提供的case，从binlog记录的序列如下

BEGIN

Table_map

Write_rows

Xid

 

BEGIN

Table_map

Table_map

Table_map

Write_rows

SAVEPOINT `event_logging`

Write_rows

Xid

 

由于这里SAVEPOINT `event_logging`是一个query event，他会去把已有的table map event做清理。导致后面的Write_rows无法解析。

 

另外一种场景是，即时SAVEPOINT后面没有DMlL， 由于在执行SAVEPOINT时会调用mysql_bin_log.write_event，将binlog flush 到IO CACHE，并且不带STMT_END_F标记。如果之后没有任何DML，没有做合适的清理。这导致之后的一次DML不生成自己的TABLEMAP而是使用之前生成的，触发备库的解析错误。

 

 

解决：

1. 当在trigger/存储过程中执行ROLLBACK TO SAVEPOINT时，在函数binlog_savepoint_rollback中会清理table map标记（thd->clear_binlog_table_maps()）。2. 对于trigger/存储过程中执行的SAVEPOINT操作，在调用函数MYSQL_BIN_LOG::write_event时，加上STMT_END_F标记，并重置TABLE MAP。

 

补丁:

https://github.com/mysql/mysql-server/commit/69d4e72cb397d3e27a76458e989f440fba049f4f

 

 

问题描述：

当执行SHOW BINLOG EVENTS时，会持有Lock_log锁，进行binlog读取和释放；而事务提交时，也需要持有Lock_log将cache写到Binlog文件中。这会导致事务hang住，直到SHOW BINLOG EVENT操作完成。(Bug #76618, Bug #20928790)

 

解决：

只在确认显示event的结尾位置时才加Lock_log保护，读取和发送都不加锁；这可能带来的问题是，例如另外一个线程做一次Purge，会产生warning。不过这是可以接受的。

 

补丁：

https://github.com/mysql/mysql-server/commit/739ac25439176f309cd2132ce16fe49d918127c7

 

问题描述：

在rotate时若出现由于某些原因导致生成新文件名出错 （需要扫描目录找到最大binlog序号）或者无法创建新的binlog文件， binlog_error_action没有处理，binlog中记录了incident event，导致所有slave复制中断。 (Bug #76379, Bug #20805298)

 

解决：

出现上述情况时，也让binlog_error_action进行处理。

 

补丁：

https://github.com/mysql/mysql-server/commit/ffa4a65978901bc6fa9b41692e81a5f7d89342d3

 

 

问题描述：

假设有gtid 1-3 已经写入relay log，我们正准备写入第4个Gtid event，在之前的逻辑中，先写relay log文件，再将Gtid加入到Retrieved_Gtid_Set中，如果这时在写完Gtid 4 （但还没加入到Retrieved集合）的事件到relay log，发生rotate，这时候Previous_Gtid的值为(1-3)，这时候如果发生重启，假设4之后还有别的GTID EVENT，重启后的Retrieved_Gtid_set可能类似1-3:5-6，中间产生Gap。

 

解决：

先加入到Retrieved_Gtid_Set，再写Gtid Event到relay log中。如果写入文件失败了，则从集合中移除。

 

补丁：

https://github.com/mysql/mysql-server/commit/a2b4259f24b76bc5032d9dbfe6f4452cc9dafc70

https://github.com/mysql/mysql-server/commit/25c85fdfe5e0233c29d9b6014eb4d0b9cf3247ac

 

 

问题描述：

主要有两个问题：1. CREATE VIEW即时发生错误，也被记录到binlog中；2. (1)产生的日志在备库上，即时被设置了过滤，也会将他的错误码和当前错误码相对比，这属于设计逻辑错误。(Bug #76493, Bug #20797764)

 

解决：

对于第一个问题，不记录binlog; 对于第二个问题，只有在event不被过滤的情况下，才和本地做对比。

 

补丁：

https://github.com/mysql/mysql-server/commit/b127c273f4f66a69761089043db3c1d6a49e2d36

 

 

问题描述：

在master_info_repository 或者relay_log_info_repository为TABLE模式时，如果在一个开启的事务中修改并发线程数，就可能导致实例直接crash，具体参阅我们之前的月报分析：http://mysql.taobao.org/monthly/2015/10/05/

 

(Bug #74950, Bug #20074353)

 

解决：

禁止在活跃事务中修改上述两个参数。

 

补丁：

https://github.com/mysql/mysql-server/commit/5639195ee2988ef80eda3537638dca2d752841be

 

 

问题描述：

在GTID开启的情况下，当master上 –binlog_checksum=none  ， slave上配置为binlog_checksum=crc32， 重启Slave的SQL线程会报Event crc check错误。

 

一个relay log头通常的序列如下：

Format_desc (of slave)

Previous-GTIDs (of slave)

Rotate (of master)

Format_desc (of master)

 

在SQL线程重启时，调用Relay_log_info::init_relay_log_pos，需要找到从master上传过来的FD事件，也就是第四个事件，然而，目前的逻辑认为序列是这样的：

Format_desc (of slave)

Rotate (of master)

Format_desc (of master)

 

按照上述序列，由于逻辑上的错误，导致无法找到正确的FD。(Bug #73806, Bug #20644100, Bug #76746, Bug #20909880)

 

解决：

需要忽略Previous-GTID和Rotate，找到正确的FD事件。

 

补丁：

https://github.com/mysql/mysql-server/commit/8a070d30fa66ac5f7099c9972ff7dc92955f979f

 

 

问题描述：

前提：

1. relay-log-info-repository设置为table模式

2. 打开GTID

3. 一个使用非事务引擎（例如MYISAM）的事务，被记录到多个relay log时（在io线程写relay log时，做个flush log操作）

 

在执行完上一个relay log时，前一个relay log被Purge，调用rli->flush_info(TRUE)，会做一次隐式提交，导致gtid被消费，切换到下一个relay log，就会因为没有gtid报错。(Bug #68525, Bug #16418100)

 

解决：

当处于一个active的事务组时，不调用rli->flush_info。

 

补丁：

https://github.com/mysql/mysql-server/commit/9b0e016889c73b8d9db1837f97e03f8ee20fbf19

 

(Bug #68525, Bug #16418100)