mysql数据库受到破坏的修复

修复数据表

多数情况下,数据库被破坏只是指索引文件受到了破坏,真正的数据被破坏掉的情况非常少。大多数形式的数据库破坏的的修复相当简单。
和前面的校验一样,修复的方式也有三种。

下面讲的方法只对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 fixtures;
+————————-+——–+———-+———————————————+
| Table | Op | Msg_type | Msg_text |
+————————-+——–+———-+———————————————+
| sports_results.fixtures | repair | error | Can’t find file: ‘fixtures.MYI’ (errno: 2) |
+————————-+——–+———-+———————————————+

修复失败的原因时索引文件丢失或者其头部遭到了破坏,为了利用相关定义文件来修复,需要用USE_FRM选项。例如:
mysql> REPAIR TABLE fixtures USE_FRM;
+————————-+——–+———-+————————————+
| Table | Op | Msg_type | Msg_text |
+————————-+——–+———-+————————————+
| sports_results.fixtures | repair | warning | Number of rows changed from 0 to 2 |
| sports_results.fixtures | repair | status | OK |
+————————-+——–+———-+————————————+

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

2>用mysql内建命令mysqlcheck来修复
当mysql服务在运行时,也可以用mysql内建命令mysqlcheck来修复。
语法:mysqlcheck -r 数据库名 表名 -uuser -ppass
%mysqlcheck -r sports_results fixtures -uuser -ppass
sports_results.fixtures OK

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

%mysqlcheck -r sports_results fixtures events -uuser -ppass
sports_results.fixtures OK
sports_results.events OK

%mysqlcheck -r sports_results -uuser -ppass
sports_results.fixtures 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 fixtures
- recovering (with keycache) MyISAM-table ‘fixtures.MYI’
Data records: 0

 

------------------------------------------------------------------------------------------------------

假设有个myisam表:tbl,为了备份方便,直接把 frm 和 MYD 文件拷贝到其他目录。在还原时,就需要重新下创建索引,只需要执行以下命令:

mysql> REPAIR TABLE `tbl` USE_FRM;

即可根据 frm 和 MYD 文件,产生一个新的 MYI 索引文件。这在索引文件较大时备份还原比较有用。

---------------------------------------------------------------------------------------------------------

防止客户机的请求互相干扰或者服务器与维护程序相互干扰的方法主要有多种。如果你关闭数据库,就可以保证服务器和myisamchk和isamchk之间没有交互作用。但是停止服务器的运行并不是一个好注意,因为这样做会使得没有故障的数据库和表也不可用。本节主要讨论的过程,是避免服务器和myisamchk或isamchk之间的交互作用。实现这种功能的方法是对表进行锁定。

服务器由两种表的锁定方法:

1.内部锁定

内部锁定可以避免客户机的请求相互干扰——例如,避免客户机的SELECT查询被另一个客户机的UPDATE查询所干扰。也可以利用内部锁定机制防止服务器在利用myisamchk或isamchk检查或修复表时对表的访问。

语法:

锁定表:LOCK TABLES tbl_name {READ | WRITE},[ tbl_name {READ | WRITE},…]

解锁表:UNLOCK TABLES

LOCK TABLES为当前线程锁定表。UNLOCK TABLES释放被当前线程持有的任何锁。当线程发出另外一个LOCK TABLES时,或当服务器的连接被关闭时,当前线程锁定的所有表自动被解锁。

如果一个线程获得在一个表上的一个READ锁,该线程(和所有其他线程)只能从表中读。如果一个线程获得一个表上的一个WRITE锁,那么只有持锁的线程READ或WRITE表,其他线程被阻止。

每个线程等待(没有超时)直到它获得它请求的所有锁。

WRITE锁通常比READ锁有更高的优先级,以确保更改尽快被处理。这意味着,如果一个线程获得READ锁,并且然后另外一个线程请求一个WRITE锁, 随后的READ锁请求将等待直到WRITE线程得到了锁并且释放了它。

显然对于检查,你只需要获得读锁。再者钟情跨下,只能读取表,但不能修改它,因此他也允许其它客户机读取表。对于修复,你必须获得些所以防止任何客户机在你对表进行操作时修改它。

2.外部锁定

服务器还可以使用外部锁定(文件级锁)来防止其它程序在服务器使用表时修改文件。通常,在表的检查操作中服务器将外部锁定与myisamchk或isamchk作合使用。但是,外部锁定在某些系统中是禁用的,因为他不能可靠的进行工作。对运行myisamchk或isamchk所选择的过程取决于服务器是否能使用外部锁定。如果不使用,则必修使用内部锁定协议。
如果服务器用--skip-locking选项运行,则外部锁定禁用。该选项在某些系统中是缺省的,如Linux。可以通过运行mysqladmin variables命令确定服务器是否能够使用外部锁定。检查skip_locking变量的值并按以下方法进行:

◆ 如果skip_locking为off,则外部锁定有效您可以继续并运行人和一个实用程序来检查表。服务器和实用程序将合作对表进行访问。但是,运行任何一个实用程序之前,应该使用mysqladmin flush-tables。为了修复表,应该使用表的修复锁定协议。

◆ 如果skip_locaking为on,则禁用外部锁定,所以在myisamchk或isamchk检查修复表示服务器并不知道,最好关闭服务器。如果坚持是服务器保持开启状态,月确保在您使用此表示没有客户机来访问它。必须使用卡党的锁定协议告诉服务器是该表不被其他客户机访问。

检查表的锁定协议

本节只介绍如果使用表的内部锁定。对于检查表的锁定协议,此过程只针对表的检查,不针对表的修复。

1.调用mysql发布下列语句:

$mysql –u root –p db_namemysql>LOCK TABLE tbl_name READ;mysql>FLUSH TABLES;

该锁防止其它客户机在检查时写入该表和修改该表。FLUSH语句导致服务器关闭表的文件,它将刷新仍在告诉缓存中的任何为写入的改变。

2.执行检查过程

$myisamchk tbl_name$ isamchk tbl_name

3.释放表锁

mysql>UNLOCK TABLES;

如果myisamchk或isamchk指出发现该表的问题,将需要执行表的修复。

修复表的锁定协议

这里只介绍如果使用表的内部锁定。修复表的锁定过程类似于检查表的锁定过程,但有两个区别。第一,你必须得到写锁而非读锁。由于你需要修改表,因此根本不允许客户机对其进行访问。第二,必须在执行修复之后发布FLUSH TABLE语句,因为myisamchk和isamchk建立的新的索引文件,除非再次刷新改表的高速缓存,否则服务器不会注意到这个改变。本例同样适合优化表的过程。

1.调用mysql发布下列语句:

$mysql –u root –p db_namemysql>LOCK TABLE tbl_name WRITE;mysql>FLUSH TABLES;

2.做数据表的拷贝,然后运行myisamchk和isamchk:

$cp tbl_name.* /some/other/dir$myisamchk --recover tbl_name$ isamchk --recover tbl_name

--recover选项只是针对安装而设置的。这些特殊选项的选择将取决与你执行修复的类型。

3.再次刷新高速缓存,并释放表锁:

mysql>FLUSH TABLES;mysql>UNLOCK TABLES;

-----------------------------------------------------------------------------------------------

问题1: mysql 磁盘满

问题2: mysql repair 多个表

repair table: 需要按周以下步骤

1: lock table EE write ;

2: flush table EE ;

3: repair table EE ;

4: flush table EE ;

5: unlock table EE ;

// 在使用mysql过程中发现了一个奇怪的问题:

我的磁盘空间快要满了(%90),df du 看了一下, 是mysql 占用了大量的空间,于是我把mysql中每个表中的数据删除了一半,但是硬盘空间仍然被占用%90 。

我但是没有管, 但是过了半个月,磁盘仍然没有满,按理说很快就会超过%90 报警的 。

于是我想找出原因:

办法一: 怀疑是有进程在想里面些数据, 不能delete 。
./mysqladmin shutdown
./mysqld-safe

重启mysql , 没有任何效果

办法二: flush 每个表, 也不行

办法三: repair 其中一个表, 看来以下, 原来700M 的空间编程了200M左右。

但是问题又来了, 我有256个表, 我写了C++程序, 顺序repair 每一个表,但是会产生Commands out of sync; you can't run this command now 错误, 不能同步

后来, 我随便试了以下, repair table1 , table2, table3 ; 这样是可以的。

原来 repair 可以一次可以repair 多个表, 问题解决了。

此条目发表在article分类目录,贴了, 标签。将固定链接加入收藏夹。