网站更改指定字段,app开发公司都有哪些部门,专注合肥网站建设,网页设计与制作参考文献服务器突然断电导致数据文件损坏。强制关机#xff0c;没有先关闭 MySQL 服务等。
表损坏的原因分析
以下原因是导致 mysql 表毁坏的常见原因#xff1a;
1、 服务器突然断电导致数据文件损坏。 2、 强制关机#xff0c;没有先关闭 mysql 服务。 3、 mysqld 进程在写表时…服务器突然断电导致数据文件损坏。强制关机没有先关闭 MySQL 服务等。
表损坏的原因分析
以下原因是导致 mysql 表毁坏的常见原因
1、 服务器突然断电导致数据文件损坏。 2、 强制关机没有先关闭 mysql 服务。 3、 mysqld 进程在写表时被杀掉。 4、 使用 myisamchk 的同时mysqld 也在操作表。 5、 磁盘故障。 6、 服务器死机。 7、 mysql 本身的 bug 。
表损坏的症状
一个损坏的表的典型症状如下
1 、当在从表中选择数据之时你得到如下错误
Incorrect key file for table: ‘…’. Try to repair it 2 、查询不能在表中找到行或返回不完全的数据。 3 、 Error: Table ‘p’ is marked as crashed and should be repaired 。 4 、打开表失败 Can’t open file: ‘×××.MYI’ (errno: 145) 。
预防 MySQL 表损坏
可以采用以下手段预防 mysql 表损坏
1 、定期使用 myisamchk 检查 MyISAM 表注意要关闭mysqld 推荐使用 check table 来检查表不用关闭 mysqld 。 2 、在做过大量的更新或删除操作后推荐使用 OPTIMIZE TABLE 来优化表这样既减少了文件碎片又减少了表损坏的概率。 3 、关闭服务器前先关闭 mysqld 正常关闭服务不要使用 kill -9 来杀进程。 4 、使用 ups 电源避免出现突然断电的情况。 5 、使用最新的稳定发布版 mysql 减少 mysql 本身的 bug 导致表损坏。 6 、对于InnoDB 引擎你可以使用 innodb_tablespace_monitor 来检查表空间文件内文件空间管理的完整性。 7 、对磁盘做raid 减少磁盘出错并提高性能。 8 、数据库服务器最好只跑 mysqld 和必要的其他服务不要跑其他业务服务这样减少死机导致表损坏的可能。 9 、不怕万一只怕意外平时做好备份是预防表损坏的有效手段。
MySQL 表损坏的修复
MyISAM 表可以采用以下步骤进行修复
1、 使用 reapair table 或 myisamchk 来修复。 2、 如果上面的方法修复无效采用备份恢复表。
具体可以参考如下做法
阶段1 检查你的表
如果你有很多时间运行 myisamchk *.MYI 或 myisamchk -e *.MYI 。使用 -s 沉默选项禁止不必要的信息。
如果 mysqld 服务器处于宕机状态应使用 --update-state 选项来告诉 myisamchk 将表标记为检查过的。
你必须只修复那些 myisamchk 报告有错误的表。对这样的表继续到阶段2 。
如果在检查时你得到奇怪的错误( 例如 out of memory 错误) 或如果 myisamchk 崩溃到阶段3 。
阶段2 简单安全的修复
注释如果想更快地进行修复当运行myisamchk 时你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。
首先试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接这应该管用并且表可被修复。开始修复下一张表。否则执行下列过程
在继续前对数据文件进行备份。
使用 myisamchk -r tbl_name -r 意味着 恢复模式 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
如果前面的步骤失败使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法处理常规恢复模式不行的少数情况( 但是更慢) 。
如果在修复时你得到奇怪的错误( 例如out of memory 错误) 或如果myisamchk 崩溃到阶段3 。
阶段3 困难的修复
只有在索引文件的第一个16K 块被破坏或包含不正确的信息或如果索引文件丢失你才应该到这个阶段。在这种情况下需要创建一个新的索引文件。按如下步骤操做
把数据文件移到安全的地方。
使用表描述文件创建新的( 空) 数据文件和索引文件
shell mysql db_name mysql SET AUTOCOMMIT1; 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 4 innodb_force_recovery 被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是 4 的选项值来转储你的表那么你是比较安全的只有一些在损坏的单独页面上的数据会丢失。一个为 6 的值更夸张因为数据库页被留在一个陈旧的状态这个状态反过来可以引发对B 树和其它数据库结构的更多破坏。
innodb_force_recovery
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 使得数据库被挂起而不需要回滚然后舍弃导致失控回滚的表。
