服务器崩溃后(Ubuntu16.04),当我尝试使用innodb_force_recovery=0启动Mysql (MySQL5.7)时,它没有启动,error.log显示:
InnoDB: Checksum mismatch in datafile: ./panel_financiero_v2/kpis_analytics.ibd, Space ID:93, Flags: 33. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
InnoDB: Corrupted page [page id: space=93, page number=0] of datafile './panel_financiero_v2/kpis_analytics.ibd' could not be found in the doublewrite buffer.
InnoDB: Tablespace 93 was not found at ./panel_financiero_v2/kpis_analytics.ibd.
InnoDB: Set innodb_force_recovery=1 to ignore this and to permanently lose all changes to the tablespace.
InnoDB: Cannot continue operation.我可以使用innodb_force_recovery=6启动Mysql (我不能像错误消息建议的那样使用innodb_force_recovery=1启动Mysql )。问题表的.ibd和.frm文件位于正确的目录中(没有空文件);我甚至尝试(以防万一,没有真正的希望)删除这两个文件(将它们移到另一个目录),但两者都不起作用。
有什么方法可以修复或恢复表(请记住,innodb_force_recovery=6在只读模式下启动Mysql,我甚至不能创建一个新表)?至少,是否可以正常地(使用innodb_force_recovery=0)启动mysql,甚至丢失了该问题表的信息?
发布于 2018-03-26 17:17:24
https://dev.mysql.com/doc/refman/5.7/en/repair-table.html说:
修复表适用于MyISAM、归档和CSV表。
换句话说,修复表对InnoDB没有任何作用。InnoDB有自己的自动碰撞恢复,可以在启动时运行。
但是,InnoDB崩溃恢复只适用于崩溃时正在进行的丢失的更改。它使用重做日志和双写缓冲区来重建丢失的脏页。此过程无法重构在静止时损坏的数据。
错误消息实际上告诉您要做什么:
InnoDB:将innodb_force_recovery=1设置为忽略这一点,并永久丢失对表空间的所有更改。
在https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html上阅读更多详细信息:
1 (SRV_FORCE_IGNORE_CORRUPT)允许服务器运行,即使它检测到一个损坏的页面。尝试使SELECT * tbl_name跳过损坏的索引记录和页,这有助于转储表。
在将表空间文件移回它们所属的位置后,使用innodb_force_recovery=1启动服务器。
然后您可以使用mysqldump转储表,它应该读取它可以读取的页面,跳过损坏的页面。然后您可以创建一个要从转储导入的新表:
CREATE TABLE mytable_new LIKE mytable;
RENAME TABLE mytable TO mytable_bad, mytable_new TO mytable;然后重新导入你的转储数据。
我假设您在转储单个表和导入转储文件方面不需要帮助。
关于你的评论:
你似乎有更广泛的腐败。我建议采取以下步骤:
innodb_force_recovery=6服务器mysqldump转储所有数据。mysqldump创建的数据转储。发布于 2021-08-17 07:20:42
如果不需要损坏表中的数据,可以先尝试丢弃表空间。
https://dba.stackexchange.com/questions/202345
复制相似问题