zoukankan      html  css  js  c++  java

  • 【转载】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)
  • 相关阅读:
    玩转Visual Studio Editor篇
    .Net2.0的集合操作 What i know?
    Log文件压缩
    [转]比较高效地实现从两个不同数组中提取相同部分组成新的数组(只支持Int类型) [C#]
    Stream 和 Byte[]互操作
    net 2.0 中如何在线程引发的事件中控制forms controls
    C# 操作Word文档(转)
    利用Lucene.net搜索引擎进行多条件搜索的做法
    c# 添加图片水印，可以指定水印位置+生成缩略图
    SDN第一次作业
  • 原文地址：https://www.cnblogs.com/conanwang/p/5848064.html
Copyright © 2011-2022 走看看