一入职，就遇到 MySQL 这么大 Bug！差点背锅走人...

今年这种状况，有时候不找好下家还真不敢跳，这不，前段时间刚跳到新东家，刚办入职那天，就赶上事了，真的是吓出一身冷汗（老大一直盯着我，说要快速解决这个问题），差点被（背）开（锅）了....

状况如何？且听我下面慢慢道来！！！但愿对你们有所帮助与借鉴。

问题描述

线上有个重要Mysql客户的表在从5.6升级到5.7后，master上插入过程当中出现"Duplicate key"的错误，并且是在主备及RO实例上都出现。

以其中一个表为例，迁移前经过“show create table” 命令查看的auto increment id为1758609， 迁移后变成了1758598,实际对迁移生成的新表的自增列用max求最大值为1758609。

用户采用的是Innodb引擎，并且据运维同窗介绍，以前碰到过相似问题，重启便可恢复正常。

内核问题排查

因为用户反馈在5.6上访问正常，切换到5.7后就报错。所以，首先得怀疑是5.7内核出了问题，所以第一反应是从官方bug list中搜索一下是否有相似问题存在，避免重复造车。通过搜索，发现官方有1个相似的bug，这里简单介绍一下该bug。

背景知识1

Innodb引擎中的auto increment 相关参数及数据结构。

主要参数包括：innodb_autoinc_lock_mode用于控制获取自增值的加锁方式，auto_increment_increment， auto_increment_offset用于控制自增列的递增的间隔和起始偏移。

主要涉及的结构体包括：数据字典结构体，保存整个表的当前auto increment值以及保护锁；事务结构体，保存事务内部处理的行数；handler结构体，保存事务内部多行的循环迭代信息。

背景知识2

mysql及Innodb引擎中对autoincrement访问及修改的流程

• (1) 数据字典结构体(dict_table_t)换入换出时对autoincrement值的保存和恢复。换出时将autoincrement保存在全局的的映射表中，而后淘汰内存中的dict_table_t。换入时经过查找全局映射表恢复到dict_table_t结构体中。相关的函数为dict_table_add_to_cache及dict_table_remove_from_cache_low。
• (2) row_import, table truncate过程更新autoincrement。
• (3) handler首次open的时候，会查询当前表中最大自增列的值，并用最大列的值加1来初始化表的data_dict_t结构体中的autoinc的值。
• (4) insert流程。相关对autoinc修改的堆栈以下：

ha_innobase::write_row：write_row的第三步中调用handler句柄中的update_auto_increment函数更新auto increment的值。
handler::update_auto_increment: 调用Innodb接口获取一个自增值，并根据当前的auto_increment相关变量的值调整获取的自增值；同时设置当前handler要处理的下一个自增列的值。
ha_innobase::get_auto_increment:获取dict_tabel中的当前auto increment值，并根据全局参数更新下一个auto increment的值到数据字典中
ha_innobase::dict_table_autoinc_initialize:更新auto increment的值，若是指定的值比当前的值大，则更新。
handler::set_next_insert_id:设置当前事务中下一个要处理的行的自增列的值。

• (5) update_row。对于”INSERT INTO t (c1,c2) VALUES(x,y) ON DUPLICATE KEY UPDATE”语句，不管惟一索引列所指向的行是否存在，都须要推动auto increment的值。相关代码以下：

if (error == DB_SUCCESS
    && table->next_number_field
    && new_row == table->record[0]
    && thd_sql_command(m_user_thd) == SQLCOM_INSERT
    && trx->duplicates)  {
    ulonglong    auto_inc;
       ……
    auto_inc = table->next_number_field->val_int();
    auto_inc = innobase_next_autoinc(auto_inc, 1, increment, offset, col_max_value);
    error = innobase_set_max_autoinc(auto_inc);
       ……
}

从咱们的实际业务流程来看，咱们的错误只可能涉及insert及update流程。

BUG 76872 / 88321: "InnoDB AUTO_INCREMENT produces same value twice"

• (1) bug概述:当autoinc_lock_mode大于0，且auto_increment_increment大于1时，系统刚重启后多线程同时对表进行insert操做会产生“duplicate key”的错误。
• (2) 缘由分析：重启后innodb会把autoincrement的值设置为max(id) + 1。

此时，首次插入时，write_row流程会调用handler::update_auto_increment来设置autoinc相关的信息。首先经过ha_innobase::get_auto_increment获取当前的autoincrement的值(即max(id) + 1)，并根据autoincrement相关参数修改下一个autoincrement的值为next_id。

当auto_increment_increment大于1时，max(id) + 1 会不大于next_id。handler::update_auto_increment获取到引擎层返回的值后为了防止有可能某些引擎计算自增值时没有考虑到当前auto increment参数，会从新根据参数计算一遍当前行的自增值，因为Innodb内部是考虑了全局参数的，所以handle层对Innodb返回的自增id算出的自增值也为next_id，即将会插入一条自增id为next_id的行。

handler层会在write_row结束的时候根据当前行的值next_id设置下一个autoincrement值。若是在write_row还没有设置表的下一个autoincrement期间，有另一个线程也在进行插入流程，那么它获取到的自增值将也是next_id。这样就产生了重复。

• (3) 解决办法：引擎内部获取自增列时考虑全局autoincrement参数，这样重启后第一个插入线程获取的自增值就不是max(id) + 1，而是next_id，而后根据next_id设置下一个autoincrement的值。因为这个过程是加锁保护的，其余线程再获取autoincrement的时候就不会获取到重复的值。

经过上述分析，这个bug仅在autoinc_lock_mode > 0 而且auto_increment_increment > 1的状况下会发生。实际线上业务对这两个参数都设置为1，所以，能够排除这个bug形成线上问题的可能性。

现场分析及复现验证

既然官方bug未能解决咱们的问题，那就得自食其力，从错误现象开始分析了。

(1) 分析max id及autoincrement的规律 因为用户的表设置了ON UPDATE CURRENT_TIMESTAMP列，所以能够把全部的出错的表的max id、autoincrement及最近更新的几条记录抓取出来，看看是否有什么规律。抓取的信息以下：

乍看起来，这个错误仍是颇有规律的，update time这一列是最后插入或者修改的时间，结合auto increment及max id的值，现象很像是最后一批事务只更新了行的自增id，没有更新auto increment的值。

联想到【官方文档】中对auto increment用法的介绍，update操做是能够只更新自增id但不触发auto increment推动的。按照这个思路，我尝试复现了用户的现场。复现方法以下：

同时在binlog中，咱们也看到有update自增列的操做。如图：

不过，因为binlog是ROW格式，咱们也没法判断这是内核出问题致使了自增列的变化仍是用户本身更新所致。所以咱们联系了客户进行确认，结果用户很肯定没有进行更新自增列的操做。

那么这些自增列究竟是怎么来的呢？

(2) 分析用户的表及sql语句 继续分析，发现用户总共有三种类型的表

hz_notice_stat_sharding
hz_notice_group_stat_sharding
hz_freeze_balance_sharding

这三种表都有自增主键。

可是前面两种都出现了autoinc错误，惟独hz_freeze_balance_sharding表没有出错。难道是用户对这两种表的访问方式不同？抓取用户的sql语句，果真，前两种表用的都是replace into操做，最后一种表用的是update操做。难道是replace into语句致使的问题？搜索官方bug, 又发现了一个疑似bug。

bug #87861: “Replace into causes master/slave have different auto_increment offset values”

缘由：

• (1) Mysql对于replace into实际是经过delete + insert语句实现，可是在ROW binlog格式下，会向binlog记录update类型日志。Insert语句会同步更新autoincrement，update则不会。
• (2) replace into在Master上按照delete+insert方式操做， autoincrement就是正常的。基于ROW格式复制到slave后，slave机上按照update操做回放，只更新行中自增键的值，不会更新autoincrement。

所以在slave机上就会出现max(id)大于autoincrement的状况。此时在ROW模式下对于insert操做binlog记录了全部的列的值，在slave上回放时并不会从新分配自增id，所以不会报错。可是若是slave切master，遇到Insert操做就会出现”Duplicate key”的错误。

• (3) 因为用户是从5.6迁移到5.7，而后直接在5.7上进行插入操做，至关因而slave切主，所以会报错。

解决方案

业务侧的可能解决方案：

• (1) binlog改成mixed或者statement格式。
• (2) 用Insert on duplicate key update代替replace into。

内核侧可能解决方案：

• (1) 在ROW格式下若是遇到replace into语句，则记录statement格式的logevent，将原始语句记录到binlog。
• (2) 在ROW格式下将replace into语句的logevent记录为一个delete event和一个insert event。

心得

• (1) autoincrement的autoinc_lock_mode及auto_increment_increment这两个参数变化容易致使出现重复的key，使用过程当中要尽可能避免动态的去修改。
• (2) 在碰到线上的问题时，首先应该作好现场分析，明确故障发生的场景、用户的SQL语句、故障发生的范围等信息，同时要对涉及实例的配置信息、binlog甚至实例数据等作好备份以防过时丢失。

只有这样才能在找官方bug时精准的匹配场景，若是官方没有相关bug，也能经过已有线索独立分析。

做者：腾讯数据库技术
来源： http://r6e.cn/df8b