MySQL [ERROR] [MY-013183]

[ERROR] [MY-013183] [InnoDB] Assertion failure，回顾记录一次因数据库（MySql 8.0）操作不当导致的生产事故顺便记录下正常重启发生的意外和解决方法（关于 [MY-013183] [InnoDB] 论坛描述，MY-013183只是断言抛出问题内存问题，应该是由于缓冲区落盘发生意外导致的，具体处理需要结合错误详细信息进行分析。如果文档中有不对的地方或有更好的方法建议，希望大家不吝赐教）

数据库重启，没启动成功

       业务正常一般不会去操作数据库，除非宕机。无奈数据库安装配置存在问题需要修改配置文件使其永久生效，数据生产较快当时已经有千万的量了，么办法只有当天晚上进行数据库调整，结果数据库丝毫不给面子直接抛出一个错误[ERROR] [MY-013183] 。

       好在通过错误详细分析问题可以通过数据库强制恢复，通过配置文件设置innodb_force_recover(官网描述可连接查看)从1到6成功启动（这个情况最多设置到4数据库就会恢复，如果你设置到6才启动上那就只有恭喜你了），再取消innodb_force_recover配置重启就可以收工了

数据库意外重启，抛异常连接不上

       数据库意外无法正常运行（那天业务系统走得很安详，我也走得很安详），上服务器一看根目录满了，这也是没谁了反手就是一个赞（数据库安装没有使用大存储卷），麻溜清理了磁盘，释放好空间开始重启数据库（以为可以正常启动，结果当头一棒 ）查看数据库服务状态是runing，高高兴兴的去连接好家伙连不上（连端口没监听）给我表里不一。

      发来的数据库错误信息 [ERROR] [MY-013183] [InnoDB] Assertion failure: fil0fil.cc:10754:initial_fsize == (file->size * phy_page_size) thread 140530362709760，当我看到这个断言的时候心都凉了半截，innodb_force_recover设置1-6设置了两遍，都设置到16了（6以上都是安6处理，一般都是1-6）也没恢复回来。现在分析下错误信息应该就是落盘idb文件分页有损坏导致断言过不了，当时不行啊没有分析的时间电话都打爆了，领导都插着手站背后看得我瑟瑟发抖，只有简单整理下打算放弃当前数据库实例，通过数据库源文件进行数据库还原（别问为什么不从备份中还原，问就是还没开始做备份我就只知道这些了）通过百度大法明确了处理流程（只有逐表恢复）

1. 1. 拷贝旧库data目录，处理事故首先确保拷贝，避免反向修复无法回头也是为了保护事故现场（此处省略，后面操作都是用拷贝的这部分文件）
   2. 创建同版本临时数据库实例（此处省略）
   3. 创建与原数据库一致的数据库及表，可以从测试环境导出结构调整与生产环境一致。如果这个没有那我只有鼓掌了但是也不要慌可通过 ibd2sdi — InnoDB 表空间 SDI 提取
2.        
   1.      ① 表名 
   2.      ② 列名和类型，列对象里面有类型对应的具体名称
   3.      ③ 长度

       

      4. 备份临时数据库data目录（此处省略）
   4. 5. 旧库ibd替换新的ibd文件，逐个修改替换表的ibd文件（如果是MyISAM引擎的表，此阶段应该就可以使用了）
   5.     .ibd文件包含tablespace id，需要修改恢复数据.ibd文件的tablespace id和临时表建立的相同标记处为修改处需保持一致
   6.    
   7.     vi模式下，输入 :%!xxd 进行16进制编辑，使用 :%!xxd -r 转换为二进制保存或者使用winHex(编辑16进制)
   8.     另一种ibd解绑和绑定方法是通过命令（这个应该是之前版本的，我尝试后失败了，仅供了解）
      1. 解除绑定：alter table user discard tablespace;（执行完sql后，表现为表的ibd文件被删除，但是千万不要自己手动删除 ）
      2. 绑定数据表.frm和数据.idb的关系:alter table user import tablespace;
   9.     注：拷贝后注意权限是正确，替换临时库ibd文件后无法正常启动可以清理或替换掉ib_logfile0、ib_logfile1，配置innodb_force_recover=6
   10. 6. 备份临时库还原至正式新数据库实例中
   11.     备份：mysqldump -h 主机名 -P 端口 -u 用户名 -p 数据库名 > 备份文件.sql 
   12.     还原：mysql> source 备份文件.sql
   13.     注：备份文件.sql会清理一次表然后再创建写入数据库
   14.  
   15.        以上6步操作数据逐步恢复，本以为万事大吉，可天有不测风云。ibd分页坏了，当读取到坏页位置时该出问题的时候还是得出问题，读取到损坏页时数据库会宕掉重启日志会输出多少页读取异常（当时忙着解决问题没存错误信息），只有找了个ibd操作工具Inno_space清理掉损坏页那一页的数据就丢了（有几页坏了丢了两三百条数据），好在损坏页数据可以不用完全恢复。
       

       最后

   16. 虽然数据大部分恢复了，但是页坏了的那部分数据没恢复，如果这部份数据是比较重要，损失就相当严重了。
   17. 希望大家服务器一定要做好相关监控（cpu、内存、网络、磁盘等）、数据库按照相关备份方案做好备份
   18. 也希望大家永远也不需要参考这篇文章，都是教训呀。
   19. 欢迎大家留言讨论

       参考引用

   20. 关于 [MY-013183] [InnoDB] CD Tavares 论坛描述：https://forums.mysql.com/read.php?22,672274,672274
   21. 官网强制恢复InnoDB：https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
   22. 官网ibd2sdi — InnoDB 表空间 SDI 提取实用程序：https://dev.mysql.com/doc/refman/8.0/en/ibd2sdi.html
   23. HuaLingPiaoXue MYSQL8.0 根据IBD文件查看表结构：https://blog.csdn.net/HuaLingPiaoXue/article/details/104953594
   24. 巴老板 mysql frm ibd 恢复工具_MySQL innodb引擎下根据.frm和.ibd文件恢复表结构和数据：https://blog.csdn.net/weixin_36275231/article/details/113253297
   25. Inno_space工具：https://github.com/baotiao/inno_space
   26.