![我应该停止 MySQL 修复吗?](https://linux22.com/image/486916/%E6%88%91%E5%BA%94%E8%AF%A5%E5%81%9C%E6%AD%A2%20MySQL%20%E4%BF%AE%E5%A4%8D%E5%90%97%EF%BC%9F.png)
MySQL 数据库(20 GB 的表和索引)损坏。我使用 MySQL-admin 图形界面启动了修复选项,现在它已经运行了 24 小时。当我检查 MyISAM 选项(缓冲区、线程等)时,我意识到它们的性能极低:1 个修复线程,8 Mb 排序缓冲区...
我的问题是哪种方法更好:停止修复过程并以更好的配置重新启动,还是继续运行并等待。有没有办法知道修复过程正在进行或需要多长时间?
答案1
您可以通过查看数据目录的内容来跟踪修复进度;您将看到名称以 # 开头的表,这些表在修复期间使用。
您还可以检查 SHOW PROCESSLIST 以确保它没有执行“使用密钥缓存修复”,因为这比“按排序修复”要糟糕得多
修复大型表非常慢;您可能应该避免使用 MyISAM 的大型表,尤其是带有大量索引的表。最好对它们进行分区以减少修复时间。这可能需要对您的应用程序代码进行重大更改。
答案2
基本上发生了停电并且数据库损坏了。
我没有停止修复过程,但似乎需要很长时间。我希望它能够正确恢复。无论如何,我已经遵循了一些未来的指示:
1.- 在 my.conf 文件中添加以下内容
[mysqld]
myisam-recover=backup,force
这样,每次 myisam 引擎损坏时,mysql 都会强制恢复。
2.- 增加修复线程的数量和排序缓冲区的大小。
3.- 不要使用图形化的 mysql-admin 界面,而要使用命令行。主要是因为命令行 mysqlcheck 有一个详细选项。
当然要备份:-)
答案3
我强烈建议不要停止该过程。
您在进程列表中看到的 1 个线程是 MySQL 的工作方式,如果您在中途停止它,可能会损坏现有数据库。
也许您可以提供更多有关数据库损坏原因的信息?
答案4
我的修复花了很长时间,因为磁盘里装满了临时文件。我没有注意到。mysql 目录中的 servername.err 文件包含如下行......
101104 5:43:24 [错误] /usr/sbin/mysqld:写入“/tmp/STiktcbP”时磁盘已满(错误代码:28)。正在等待某人释放空间... 60 秒后重试