mysql数据库文件修复

  1. 云栖社区>
  2. 博客>
  3. 正文

mysql数据库文件修复

余二五 2017-11-16 16:03:00 浏览601
展开阅读全文

多数情况下,数据库被破坏只是指索引文件受到了破坏,真正的数据被破坏掉的情况非常少。大多数形式的数据库破坏的的修复相当简单。

和前面的校验一样,修复的方式也有三种。

下面讲的方法只对MyISAM格式的表有效。其他类型的损坏需要从备份中恢复。


1,REPAIR TABLE SQL statement(mysql服务必须处于运行状态)。


2,命令mysqlcheck(mysql服务可以处于运行状态)。


3,命令myisamchk(必须停掉mysql服务,或者所操作的表处于不活动状态)。


在修复表的时候,最好先作一下备份。所以你需要两倍于原始表大小的硬盘空间。请确保在进行修复前你的硬盘空间还没有用完。


1>用”repair table”方式修复

语法:repair table 表名 [选项]

选项如下:

QUICK 用在数据表还没被修改的情况下,速度最快

EXTENDED 试图去恢复每个数据行,会产生一些垃圾数据行,万般无奈的情况下用

USE_FRM 用在.MYI文件丢失或者头部受到破坏的情况下。利用.frm的定义来重建索引


多数情况下,简单得用”repair table tablename”不加选项就可以搞定问题。但是当.MYI文件丢失或者头部受到破坏时,这样的方式不管用,例如:

mysql> REPAIR TABLE mytable;

+————————-+——–+———-+———————————————+

| Table | Op | Msg_type | Msg_text |

+————————-+——–+———-+———————————————+

| sports_results.mytable | repair | error | Can’t find file: ‘mytable.MYI’ (errno: 2) |

+————————-+——–+———-+———————————————+修复失败的原因时索引文件丢失或者其头部遭到了破坏,为了利用相关定义文件来修复,需要用USE_FRM选项。例如:

mysql> REPAIR TABLE mytable USE_FRM;

+————————-+——–+———-+————————————+

| Table | Op | Msg_type | Msg_text |

+————————-+——–+———-+————————————+

| sports_results.mytable | repair | warning | Number of rows changed from 0 to 2 |

| sports_results.mytable | repair | status | OK |

+————————-+——–+———-+————————————+

我们可以看到Msg_test表项的输出信息”ok”,表名已经成功修复受损表。


2>用mysql内建命令mysqlcheck来修复

当mysql服务在运行时,也可以用mysql内建命令mysqlcheck来修复


语法:mysqlcheck -r 数据库名 表名 -uuser -ppass


%mysqlcheck -r sports_results mytable -uuser -ppass


sports_results.mytable OK利用mysqlcheck可以一次性修复多个表。只要在数据库名后列出相应表名即可(用空格隔开)。或者数据库名后不加表名,将会修复数据库中的所有表,例如:


%mysqlcheck -r sports_results mytable events -uuser -ppass

sports_results.mytable OK

sports_results.events OK


%mysqlcheck -r sports_results -uuser -ppass

sports_results.mytable OK

sports_results.events OK

3>用myisamchk修复

用这种方式时,mysql服务必须停掉,或者所操作的表处于不活动状态(选项skip-external-locking没被使用)。记着一定要在相关.MYI文件的路径下或者自己定义其路径。

语法:myisamchk [选项] [表名]

下面是其选项和描述

–backup, -B 在进行修复前作相关表得备份

–correct-checksum 纠正校验和

–data-file-length=#, -D # 重建表时,指定数据文件得最大长度

–extend-check, -e 试图去恢复每个数据行,会产生一些垃圾数据行,万般无奈的情况下用

–force, -f 当遇到文件名相同的.TMD文件时,将其覆盖掉。

keys-used=#, -k # 指定所用的keys可加快处理速度,每个二进制位代表一个key.第一个key为0

–recover, -r 最常用的选项,大多数破坏都可以通过它来修复。如果你的内存足够大,可以增大参数sort_buffer_size的值来加快恢复的速度。但是遇到唯一键由于破坏而不唯一 的表时,这种方式不管用。

–safe-recover -o 最彻底的修复方式,但是比-r方式慢,一般在-r修复失败后才使用。这种方式读出 所有的行,并以行为基础来重建索引。它的硬盘空间需求比-r方式稍微小一点,因 为它没创建分类缓存。你可以增加key_buffer_size的值来加快修复的速度。

–sort-recover, -n mysql用它类分类索引,尽管结果是临时文件会非常大

–character-sets-dir=… 包含字符集设置的目录

–set-character-set=name 为索引定义一个新的字符集

–tmpdir=path, -t 如果你不想用环境变量TMPDIR的值的话,可以自定义临时文件的存放位置

–quick, -q 最快的修复方式,当数据文件没有被修改时用,当存在多键时,第二个-q将会修改 数据文件

–unpack, -u 解开被myisampack打包的文件


myisamchk应用的一个例子

% myisamchk -r mytable

- recovering (with keycache) MyISAM-table ‘mytable.MYI’

Data records: 0







找到mysql的安装目录的bin/myisamchk工具,在命令行中输入:

myisamchk -c -r ../data/tablename/posts.MYI

然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql,问题就解决了。


当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。

 
这三种修复方法如下所示: 
% myisamchk --recover --quick /path/to/tblName 
% myisamchk --recover /path/to/tblName 
% myisamchk --safe-recover /path/to/tblName 

第一种是最快的,用来修复最普通的问题;而最后一种是最慢的,用来修复一些其它方法所不能修复的问题。

检查和修复MySQL数据文件 
如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧: 


如果你怀疑表的索引文件(*.MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上,使用下面的命令删除表的内容: 

mysql> DELETE FROM tblName; 

删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。
最后,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。

如果你的表的格式文件(tblName.frm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATETABLE语句来重新生成这张表,你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。

启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了,但是最好你还是执行一下标准的修复(上面的第二种方法)。


例如 
检查、优化、并修复所有的数据库用: 
# mysqlcheck -A -o -r -p 

修复指定的数据库用 
mysqlcheck -A -o -r Database_NAME -p 
即可 











本文转自 chengxuyonghu 51CTO博客,原文链接:http://blog.51cto.com/6226001001/1564006,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
余二五
+ 关注