Heim >Datenbank >MySQL-Tutorial >深入理解MYSQL数据损坏的原因及修复方法
这篇文章主要介绍了MYSQL数据损坏的原因及修复方法,有一定的参考价值,感兴趣的小伙伴可以参考一下。
1.表损坏的原因分析
shell> mysql db_name mysql> SET AUTOCOMMIT=1; mysql> TRUNCATE TABLE tbl_name; mysql> quit
如果你的MySQL 版本没有TRUNCATE TABLE ,则使用DELETE FROM tbl_name 。
将老的数据文件拷贝到新创建的数据文件之中。(不要只是将老文件移回新文件之中;你要保留一个副本以防某些东西出错。)
回到阶段2 。现在myisamchk -r -q 应该工作了。(这不应该是一个无限循环)。
你还可以使用REPAIR TABLE tbl_name USE_FRM ,将自动执行整个程序。
阶段4 :非常困难的修复
只有.frm 描述文件也破坏了,你才应该到达这个阶段。这应该从未发生过,因为在表被创建以后,描述文件就不再改变了。
从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者,你应该用myisamchk -r 启动。
如果你没有进行备份但是确切地知道表是怎样创建的,在另一个数据库中创建表的一个拷贝。删除新的数据文件,然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件,但是让.MYD 数据文件独自留下来了。回到阶段2 并且尝试重建索引文件。
InnoDB 表可以采用下面的方法修复:
如果数据库页被破坏,你可能想要用SELECT INTO OUTFILE 从从数据库转储你的表,通常以这种方法获取的大多数数据是完好的。即使这样,损坏可能导致SELECT * FROM tbl_name 或者InnoDB 后台操作崩溃或断言,或者甚至使得InnoDB 前滚恢复崩溃。 尽管如此,你可以用它来强制InnoDB 存储引擎启动同时阻止后台操作运行,以便你能转储你的表。例如:你可以在重启服务器之前,在选项文件的[mysqld] 节添加如下的行:
[mysqld]innodb_force_recovery = 4innodb_force_recovery 被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4 的选项值来转储你的表,那么你是比较安全的,只有一些在损坏的单独页面上的数据会丢失。一个为6 的值更夸张,因为数据库页被留在一个陈旧的状态,这个状态反过来可以引发对B 树和其它数据库结构的更多破坏。
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)
也阻止插入缓冲合并操作。如果你可能会导致一个崩溃。最好不要做这些操作,不要计算表统计表。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志:InnoDB 把未完成的事务视为已提交的。
6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施,当innodb_force_recovery 被设置为大于0 的值时,InnoDB 阻止用户执行INSERT, UPDATE 或DELETE 操作.
即使强制恢复被使用,你也可以DROP 或CREATE 表。如果你知道一个给定的表正在导致回滚崩溃,你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE 导致的失控回滚。你可以杀掉mysqld 进程,然后设置innodb_force_recovery 为3 ,使得数据库被挂起而不需要回滚,然后舍弃导致失控回滚的表。
【相关教程推荐】
1. mysql数据库图文教程
3. bootstrap教程