解决MySQL数据库意外崩溃导致表数据⽂件损坏⽆法启
动的问题
问题故障：
MySQL数据库意外崩溃，⼀直⽆法启动数据库。
报错⽇志：
启动报错：service mysqld restart
ERROR! MySQL server PID file could not be found!
Starting MySQL. ERROR! The server quit without updating PID file (/www/wdlinux/mysql/var/iZ2358oz5deZ.pid).
数据库error⽇志:
200719 22:07:43 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .
InnoDB: Error: trying to add tablespace 840 of name './ob_wp/ob_termmeta.ibd'
InnoDB: to the tablespace memory cache, but tablespace
InnoDB: 840 of name './dev_nss/dg_queue.ibd' already exists in the tablespace
mysql下载starting the serverInnoDB: memory cache!
200719 22:07:43 mysqld_safe mysqld from pid file /www/wdlinux/mysql/var/iZ2358oz5deZ.pid ended
提⽰：数据库启动时读取表空间信息时，ob-wp库中的表ob_users.ibd表数据⽂件已存在于表空间中。
拓展：
存储引擎是myisam, 在数据库⽬录下会看到3类⽂件：.frm、.myi、.myd
(a) *.frm--表定义，是描述表结构的⽂件。
(b) *.MYD--"D"数据信息⽂件，是表的数据⽂件。
(c) *.MYI--"I"索引信息⽂件，是表数据⽂件中任何索引的数据树
存储引擎是InnoDB, 在data⽬录下会看到2类⽂件：.frm、.ibd
(a) *.frm--表结构的⽂件。
(b) *.ibd--表数据⽂件
⽅法⼀：
根据提⽰信息判定该InnoDB表损坏，于是尝试将dev_nss库⽬录中的表结构和表数据⽂件备份
mv ob_termmeta.ibd ob_termmeta.ibd,bak
mv ob_termmeta.frm ob_termmeta.frm.bak
然后重启了下mysql，发现还是⽆法启动，提⽰其他表数据⽂件已存在，连续3次将已损坏的⽂件备份，还是⽆法启动。故放弃此⽅法。
⽅法⼆：
1.查阅官⽹⽂档，在mysql配置⽂件中/etc/myf添加配置，成功启动
[mysqld]
innodb_force_recovery = 1
2.备份数据库
mysqldump -h172.168.2.100 -uroot -p -A > mysql_all_bak.sql
如遇报表不存在，mysqldump可以添加参数：--force ，跳过错误
3.删除数据库
drop database hxdb; 或者将数据库数据库⽬录 mv hxdb hxdb_bak （保险）
4.去掉参数 innodb_force_recovery
将之前设置的参数去掉后，重新启动数据库
5.导⼊数据
mysql -uroot -p < mysql_all_bak.sql
Warning: Using a password on the command line interface can be insecure.
ERROR 1050 (42S01) at line 25: Table '`hxdb`.`tb_info`' already exists
如果提⽰表已经存在，这是因为将innodb_force_recovery参数去掉后，数据库会进⾏回滚操作，会⽣成相应的ibd⽂件，所以需要将该⽂件删除掉，删除后重新导⼊
mysql -uroot -p < mysql_all_bak.sql
注：
innodb_force_recovery参数解释：崩溃恢复模式，通常只有在严重故障排除情况下才会改变。可以的值是从0到6。
只有在紧急情况下才将这个变量设置为⼤于0的值，这样你才能启动InnoDB并转储你的表。作为⼀种安全措施，当
innodb_force_recovery⼤于0时，InnoDB可以防⽌插⼊、更新或删除操作。
在5.6.15,innodb_force_recovery设置为4或更⼤，将InnoDB设置为只读模式。由于relay_log_info_repository=TABLE和master_info_repository=TABLE在InnoDB表中存储信息，这些限制可能导致复制管理命令失败并出现错误。
innodb_force_recovery默认情况下为0（正常启动⽽不强制恢复）。允许的⾮零值 innodb_force_recovery是1到6。较⼤的值包括较⼩值的功能。例如，值3包含值1和2的所有功能。
如果能够转储 innodb_force_recovery值为3或更⼩的表，则相对安全的是，仅丢失损坏的单个页⾯上的某些数据。4或更⼤的值被认为是危险的，因为数据⽂件可能会永久损坏。值6被认为是过分的，因为数据库页⾯处于过时状态，这反过来可能会使B树和其他数据库结构遭受更多破坏。
为了安全起见，请InnoDB防⽌ INSERT， UPDATE或 DELETE在innodb_force_recovery⼤于0 时进
⾏操作。从MySQL
5.6.15开始，在只读模式下innodb_force_recovery设置4个或更多位置InnoDB。
1 (SRV_FORCE_IGNORE_CORRUPT)
让服务器运⾏，即使它检测到⼀个损坏的页⾯。尝试让SELECT * FROM tbl_name跳过损坏的索引记录和页⾯，这有助于转储表。
2 (SRV_FORCE_NO_BACKGROUND)
阻⽌主线程和任何清除线程运⾏。如果在清除操作期间发⽣崩溃，则此恢复值将防⽌崩溃。
3 (SRV_FORCE_NO_TRX_UNDO)
在崩溃恢复后不运⾏事务回滚。
4 (SRV_FORCE_NO_IBUF_MERGE)
防⽌插⼊缓冲区合并操作。如果它们会导致崩溃，就不要做。不计算表统计信息。此值可能永久损坏数据⽂件。使⽤此值后，准备删除并重新创建所有⼆级索引。在MySQL 5.6.15中，将InnoDB设置为
只读。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库时不要查看撤销⽇志:InnoDB甚⾄会将未完成的事务视为已提交。此值可能永久损坏数据⽂件。在MySQL 5.6.15中，将InnoDB设置为只读。
6 (SRV_FORCE_NO_LOG_REDO)
在恢复时不执⾏重做⽇志前滚。此值可能永久损坏数据⽂件。使数据库页⾯处于过时状态，这反过来可能会给b -树和其他数据库结构带来更多损坏。在MySQL 5.6.15中，将InnoDB设置为只读。
希望能帮到你
到此这篇关于MySQL数据库意外崩溃导致表数据⽂件损坏⽆法启动的问题解决的⽂章就介绍到这了，更多相关MySQL数据库意外崩溃导致表数据⽂件损坏⽆法启动的问题解决内容请搜索以前的⽂章或继续浏览下⾯的相关⽂章希望⼤家以后多多⽀持！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。