REPAIR TABLE的MySQL文档说明了这一点
最好在执行表修复操作之前备份表; 在某些情况下,操作可能会导致数据丢失.可能的原因包括但不限于文件系统错误.
我想知道除文件系统错误之外是否还有其他原因导致数据丢失.有没有人在野外看到过这种情况？如果没有文件系统错误,修复将丢失数据的可能性有多大？
我的具体情况如下.我有Sun T5120服务器运行Solaris 10(SPARC)并使用MySQL 5.1.30.我有一个使用MyISAM引擎的表,偶尔会损坏.该表已被破坏的一些时间是由于我们的开发系统没有UPS的意外停电造成的.我不确定所有腐败是由于停电造成的,所以可能还有其他一些原因导致这种情况发生.比如这里列出的原因.
我想设置一个自动修复解决方案,以防生产系统中出现这些可疑的"其他原因",或生产UPS出现故障.我可以mysqlcheck --auto-recover按照本答案中的建议设置一个cron作业,或者我可以修改插入该表的进程,以便REPAIR TABLE EXTENDED在检测到损坏时立即执行该命令.但是,这两种方法都使用REPAIR TABLE并因此容易受到数据丢失的影响.
正如文档所示,我可以在尝试修复之前备份表,但是表格相当大,我不确定我是否有可用于备份的空间.我已经做了一些搜索,但没有找到任何解释为什么REPAIR TABLE会导致数据丢失,除了文档中提到的.那么当你有一个健全的文件系统时,修复是否会丢失数据,或者文档是否只是谨慎？
MySQL 手册中列出的可能原因之一是软件中的错误。您应该阅读版本前移的发行说明/更改历史记录，以查看修复表代码中的任何错误是否已得到修复，并且还应阅读新版本发布时的发行说明。
出于兴趣，您插入数据的过程如何检测损坏？
您可以采取的防止数据丢失的另一项措施是进行备份并启用复制日志。如果发生故障，您可以从备份进行恢复，然后使用复制日志将数据库恢复到崩溃时的状态。
最终，如果这是一个生产系统，您确实需要挑选一个好的电源，并且还需要第二台机器作为复制品。