现象
本文也是一个生产案例，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.
解决方法
- 官方已经在 5.6.27 修复了该bug
InnoDB: The
IBUF_BITMAP_FREEbit 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以上的版本。 - 短期不能直接升级的，需要先使用 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 后,使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。
- 云上架构，请结合云技术支持人员的建议做对应操作。
