新功能

 
问题描述(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)

转载于:https://www.cnblogs.com/conanwang/p/5848064.html

【转载】MySQL5.6.27 Release Note解读(innodb及复制模块)相关推荐

  1. MySQL 5.6.26 Release Note解读

    最近上游发布了MySQL 5.6.26版本,从release note来看,MySQL5.6版本已经相当成熟,fix的bug数越来越少了.本文主要分析releae note上fix的相关bug,去除p ...

  2. K8s 1.14 发布了,Release Note 该怎么读?

    本文由张磊.心贵.临石.徙远.衷源.浔鸣等同学联合撰写. Kubernetes 1.14.0 Release 已经于 3 月 25 日正式发布.相信你也已经注意到,相比于1.13 和 1.12 版本, ...

  3. Mysql下载安装(附mysql5.5.27免费下载安装)

    Mysql下载安装 (记录mysql下载安装,以便日后使用) 关于maven中加载mysql问题直接点这里(正在更新) 安装版安装请看这里 mysql5.5.27下载地址64位 mysql5.5.27 ...

  4. Paddle Release Note

    Paddle Release Note 重要更新 飞桨paddle框架2.0.0版本有如下重要更新: • 编程范式:默认开启动态图模式进行模型开发和训练,通过动转静的方式进行模型部署和训练加速.如果需 ...

  5. mysql5.6.27_Centos上安装Mysql5.6.27多实例

    CentOs 6.4 Mysql5.6.27 CentOs6.4 Mysql5.6.27 卸载系统mysql: rpm -qa|grep -i mysql rpm -e --nodeps xxx # ...

  6. linux mysql5.6.27源码安装和错误解决

    centos mysql5.6.27 1编译安装 先进入到文件放置的路径下 创建一个个文件 #mkdir–p /data/mysql/mysql #mkdir–p /data/mysql/mysqld ...

  7. mysql2.1.4安装_安装Apache2.2.4+Mysql5.0.27+php5.2.1详细安装说明

    安装Apache2.2.4+Mysql5.0.27+php5.2.1详细安装说明 安装系统: 红帽子企业服务器Redhat Linux5(不安装任何服务) 也可以安装完整版,然后将Apache,mys ...

  8. MySQL5.5.27使用Restore From SQL Dump功能导入数据库表中出现Row size too large

    问题描述:MySQL数据库版本为MySQL5.5.27,在使用其Restore From SQL Dump功能导入数据库表时出现以下错误提示 Row size too large. The maxim ...

  9. mysql5.6.27安装_mysql-5.6.27源码安装及错误解决办法

    环境:centos6.5.x86_64yum install -y cmake  当然也可以自己下载源码包安装,为方便就Yum安装了 useradd -s /sbin/nologin mysql ta ...

  10. mysql myisam 主从_MySQL的主从复制Replication之MyIsam和InnoDB数据复制发布

    MyIsam发布相对简单,把库下面所有文件拷过去就好了.复制Innodb的做法和MyIsam类似,只不过Innodb引擎下的表的数据内容不再是存在同一的数据库目录下(MyIsam就是这么做的),Inn ...

最新文章

  1. Sqlite3支持的数据类型 日期函数以及相关 函数
  2. 科学家发现鱼会数学,5以内的加减法难不倒它,网友:要多吃鱼了
  3. 【风控场景】互利网上数字金融典型场景: 网络支付
  4. ensp小实验走起来(路由下发、MSTP、VRRP、DHCP、DHCP中继、NAT、链路聚合)之配置
  5. python解释器下安装z3_再次:在Windows上安装Z3 Python
  6. linux时间跳变影响,MONGO 集群 修改linux主机时间后的影响
  7. eclipse中启动tomcat的项目路径
  8. 基于JAVA+SpringMVC+Mybatis+MYSQL的学校教务查询系统
  9. 第二百零一天 how can I坚持
  10. 生产者-消费者习题的运用
  11. 多图片文件上传实现并通过 PostMan 测试
  12. nginx php访问阻塞,php-cgi和php-fpm,Windows环境下解决Nginx+php并发访问阻塞问题。
  13. linux类似everything的软件,安装linux下强大的文件工具fsearch,与windows下Everything类似...
  14. 米思齐Mixly图形化编程---呼吸灯与可调档位灯
  15. 一. Scala安装与环境配置
  16. 计算机电脑使用基础知识!
  17. “此工作站和主域间的信任关系失败”之解决
  18. 不可不知,专业名词解释
  19. 网站吊唁效果(黑白)
  20. c语言中用age表示年龄的词语,age和aged表示年龄的区别

热门文章

  1. Apache+tomcat集群
  2. 让Node.js在Azure上运行-3
  3. 让 list-style-image 图片垂直居中
  4. SQL查询语句中参数带有中文查询不到结果
  5. TCL语言笔记:TCL过程控制练习
  6. iOS 之项目中遇到的问题总结
  7. LayoutInflater(二)
  8. Github readme语法-- markdown
  9. ubuntu无法连接网络
  10. Docker使用小结(二)Docker仓库 Docker数据管理 端口映射与容器互联