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

复制

本次版本更新修复了大量的复制bug
问题描述
如果一个事务在备库apply时需要等待行锁超时,并且repositories设置为table模式,重试时可能触发断言错误。 因为在确定重试时,事务状态依然是active的,再次调用global_init_info函数会去开启一个新的事务,触发断言(修复BUG16533802 引入的regression)
解决
在超时重试之前调用rli->cleanup_context(thd, 1),将当前事务完全回滚掉,恢复到非active状态。
补丁:
问题描述:
当使用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线程退出。
问题描述:
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。
补丁:
问题描述
当执行SHOW BINLOG EVENTS时,会持有Lock_log锁,进行binlog读取和释放;而事务提交时,也需要持有Lock_log将cache写到Binlog文件中。这会导致事务hang住,直到SHOW BINLOG EVENT操作完成。(Bug #76618, Bug #20928790)
解决
只在确认显示event的结尾位置时才加Lock_log保护,读取和发送都不加锁;这可能带来的问题是,例如另外一个线程做一次Purge,会产生warning。不过这是可以接受的。
补丁
问题描述
在rotate时若出现由于某些原因导致生成新文件名出错 (需要扫描目录找到最大binlog序号)或者无法创建新的binlog文件, binlog_error_action没有处理,binlog中记录了incident event,导致所有slave复制中断。 (Bug #76379, Bug #20805298)
解决
出现上述情况时,也让binlog_error_action进行处理。
补丁
问题描述
假设有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中。如果写入文件失败了,则从集合中移除。
补丁
问题描述
主要有两个问题:1. CREATE VIEW即时发生错误,也被记录到binlog中;2. (1)产生的日志在备库上,即时被设置了过滤,也会将他的错误码和当前错误码相对比,这属于设计逻辑错误。(Bug #76493, Bug #20797764)
解决
对于第一个问题,不记录binlog; 对于第二个问题,只有在event不被过滤的情况下,才和本地做对比。
补丁
问题描述
在master_info_repository 或者relay_log_info_repository为TABLE模式时,如果在一个开启的事务中修改并发线程数,就可能导致实例直接crash,具体参阅我们之前的月报分析:http://mysql.taobao.org/monthly/2015/10/05/
(Bug #74950, Bug #20074353)
解决
禁止在活跃事务中修改上述两个参数。
补丁
问题描述
在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事件。
补丁
问题描述
前提
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。
补丁
(Bug #68525, Bug #16418100)

原创文章,转载请注明: 转载自Simple Life

本文链接地址: MySQL5.6.27 Release Note解读(innodb及复制模块)

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *