【转载】MySQL5.6.27 Release Note解读(innodb及复制模块)
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了【转载】MySQL5.6.27 Release Note解读(innodb及复制模块),小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含13135字,纯文字阅读大概需要19分钟。
内容图文
![【转载】MySQL5.6.27 Release Note解读(innodb及复制模块)](/upload/InfoBanner/zyjiaocheng/469/7b12061f184e408da5b153471ccbe82b.jpg)
主要为了解决一个比较“古老”的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;binlog中的记录为:
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;
| master-bin.000001 | 229 | Query | 1 | 340 | use `test`; CREATE TABLE t1(c1 int) ENGINE=InnoDB |这是因为在决定写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版本),或者错误日志中报如下错误,复制中断:
| 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 |
+——————-+——+————-+———–+————-+—————————————————+
[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)
【转载】MySQL5.6.27 Release Note解读(innodb及复制模块)
标签:
本文系统来源:http://www.cnblogs.com/conanwang/p/5848064.html
内容总结
以上是互联网集市为您收集整理的【转载】MySQL5.6.27 Release Note解读(innodb及复制模块)全部内容,希望文章能够帮你解决【转载】MySQL5.6.27 Release Note解读(innodb及复制模块)所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。