MySQL 5.6 change buffer bug导致crash

现象

本文也是一个生产案例，MySQL 5.6.18 版本 , 系统突然crash，HA 切换之后新的主库也遇到该bug crash 。MySQL 的error.log 报错如下:

2021-10-18 11:48:57 7f49a27fc700 InnoDB: Error: Insert buffer insert fails; page free 48, dtuple size 49 InnoDB: Cannot insert index record DATA TUPLE: 2 fields; 0: len 38; hex 35333339302020202020202020200202020202020; asc 53390 ;; 1: len 4; hex 80963b9e; asc ; ;;

排查

咨询内核研发，他们反馈这是官方已知bug：Insert buffer 内部标识长度的位图没有正确更新，导致问题；触发没有更新的范围太底层太广泛。

Bug #20796566   ERROR: INSERT BUFFER INSERT FAIL CANNOT
                            INSERT INDEX RECORD
Problem:
=======
IBUF_BITMAP_FREE bit in ibuf bitmap array is used to indicate the free
space available in leaf page. IBUF_BITMAP_FREE bit indicates free
space more than actual existing free space for the leaf page.

Solution:
=========
Ibuf_bitmap_array is not updated for the secondary index leaf page when
insert operation is done by updating a delete marked existing
record in the index.

解决方法

1. 官方已经在　5.6.27　修复了该bug InnoDB: The IBUF_BITMAP_FREE bit indicated that there was more free space in the leaf page than was actually available. (Bug #20796566) https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-27.html 如果MySQL 升级则需要升级MySQL系统到 5.6.27以上的版本。
2. 短期不能直接升级的，需要先使用 innodb_force_recovery=2 启动数据库。逻辑备份恢复到新的实例或者使用物理备份恢复到新实例。 要避免该bug，建议关闭 innodb_change_buffering (该操作对HDD 硬盘有性能影响，如果存储是SSD磁盘，影响比较小。请注意。)

innodb_force_recovery 可以设置为1-6,大的数字包含前面所有数字的影响。
1 (SRV_FORCE_IGNORE_CORRUPT):    忽略检查到的corrupt页。 
2 (SRV_FORCE_NO_BACKGROUND):     阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。 
3 (SRV_FORCE_NO_TRX_UNDO):         不执行事务回滚操作。 
4 (SRV_FORCE_NO_IBUF_MERGE):       不执行插入缓冲的合并操作。 
5 (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。 
6 (SRV_FORCE_NO_LOG_REDO):         不执行前滚的操作。 

当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。当然即使innodb_force_recovery>0 ，你也可以DROP或CREATE表。如果某个表正在回滚而导致数据库崩溃，设置innodb_force_recovery为3,重启db 后,使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。

1. 云上架构，请结合云技术支持人员的建议做对应操作。