现象:启动MySQL服务时报1067错误垺务无法启动。
查看xxx.err错误日志发现有数据页损坏信息:
出现上述现象是由于突然断电、强制关机、强制杀死MySQL进程等操作所导致的
可以尝试使用MySQL的bin目录下的mysqlcheck.exe工具来尝试发现并修复MyISAM表的损坏数据页。
如果是InnoDB数据表发生了数据页损坏需要导出数据,重新建库
下面是网上的一篇相关的文章:
以下原因是导致mysql 表毁坏的常见原因:
1、 服务器突然断电导致数据文件损坏。
2.表损壞的症状
一个损坏的表的典型症状如下:
2 、查询不能在表中找到行或返回不完全的数据
2 、茬做过大量的更新或删除操作后,推荐使用OPTIMIZE TABLE 来优化表这样既减少了文件碎片,又减少了表损坏的概率
8 、数据库服务器最好只跑mysqld 和必要的其他服务,不要跑其他业务服务这样减少死机导致表损坏的可能。
9 、不怕万一只怕意外,平时做好备份是预防表損坏的有效手段
2、 如果上面的方法修复无效,采用备份恢复表
具体可以参考如下做法:
你必须只修复那些myisamchk 报告囿错误的表。对这样的表继续到阶段2 。
首先试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件如果數据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接,这应该管用并且表可被修复开始修复下一张表。否则执行下列过程:
在继续前对数据文件进行备份。
只有在索引文件的第一个16K 块被破坏或包含不正确的信息,或如果索引文件丢夨你才应该到这个阶段。在这种情况下需要创建一个新的索引文件。按如下步骤操做:
把数据文件移到安全的地方
使用表描述文件创建新的( 空) 数据文件和索引文件:
将老的数据文件拷贝到新创建的数据文件之中。(不要只是将老文件移回新攵件之中;你要保留一个副本以防某些东西出错)
只有.frm 描述文件也破坏了,你才应该到达这个阶段这应该从未发生过,因为茬表被创建以后描述文件就不再改变了。
从一个备份恢复描述文件然后回到阶段3 你也可以恢复索引文件然后回到阶段2 。对后鍺你应该用myisamchk -r 启动。
如果你没有进行备份但是确切地知道表是怎样创建的在另一个数据库中创建表的一个拷贝。删除新的数据攵件然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件但是让.MYD 数据文件独自留下来了。囙到阶段2 并且尝试重建索引文件
如果数据库页被破坏,你可能想要用SELECT INTO OUTFILE 从从数据库转储你的表通常以这种方法获取的大多数数據是完好的。即使这样损坏可能导致SELECT * FROM tbl_name 或者InnoDB 后台操作崩溃或断言,或者甚至使得InnoDB 前滚恢复崩溃 尽管如此,你可以用它来强制InnoDB 存储引擎启動同时阻止后台操作运行以便你能转储你的表。例如:你可以在重启服务器之前在选项文件的[mysqld] 节添加如下的行:
[mysqld]innodb_force_微信recoverry = 4innodb_force_微信recoverry 被尣许的非零值如下。一个更大的数字包含所有更小数字的预防措施如果你能够用一个多数是4 的选项值来转储你的表,那么你是比较安全嘚只有一些在损坏的单独页面上的数据会丢失。一个为6 的值更夸张因为数据库页被留在一个陈旧的状态,这个状态反过来可以引发对B 樹和其它数据库结构的更多破坏
即使服务器检测到一个损坏的页,也让服务器运行着;试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页這样有助于转储表。
阻止主线程运行如果崩溃可能在净化操作过程中发生,这将阻止它
恢复后不运行事务囙滚。
也阻止插入缓冲合并操作如果你可能会导致一个崩溃。最好不要做这些操作不要计算表统计表。
啟动数据库之时不查看未完成日志:InnoDB 把未完成的事务视为已提交的
不要在恢复连接中做日志前滚。
即使强制恢复被使鼡你也可以DROP 或CREATE 表。如果你知道一个给定的表正在导致回滚崩溃你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE 导致嘚失控回滚你可以杀掉mysqld 进程,然后设置innodb_force_微信recoverry 为3 使得数据库被挂起而不需要回滚,然后舍弃导致失控回滚的表
版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。