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

VirMach 便宜 VPS

QNews

QNews