☰

MySQL 表未修复

tag-icon • tag-icon linux mysql database database-administration myisam
MySQL 表未修复

表格信息：

Database name: user_motiva
Table name: wp_options.frm  wp_options.MYD  wp_options.MYI  wp_options.TMD

当我执行 mysqlcheck -r --all-databases 时，它会挂在该表上，即使你让它闲置一整天。即使只是一个检查也会挂在同一位置。

还有其他方法可以修复/修理/恢复该表吗？

我应该使用 myisamchk 吗？我看到了类似这样的内容：

shell> myisamchk --recover City

您甚至无法从 phpMyAdmin 访问/查看数据库，甚至无法在 mysql 中“USE ;” ，因为它会挂起。

我在 16GB 内存盒上的配置

 cat /etc/my.cnf
[mysqld]
default-storage-engine=MyISAM
local-infile=0
symbolic-links=0
skip-networking
max_connections = 500
max_user_connections = 20
key_buffer = 512M
myisam_sort_buffer_size = 64M
join_buffer_size = 64M
read_buffer_size = 12M
sort_buffer_size = 12M
read_rnd_buffer_size = 12M
table_cache = 2048
thread_cache_size = 16K
wait_timeout = 30
connect_timeout = 15
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 64M
query_cache_type = 1
low_priority_updates=1
concurrent_insert=ALWAYS
log-error=/var/log/mysql/error.log
tmpdir=/home/mysqltmp
myisam_repair_threads=4
[mysqld_safe]
open_files_limit = 8192
log-error=/var/log/mysql/error.log

[mysqldump]
quick
max_allowed_packet = 512M

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

这是因为执行 killall -9 mysqld 导致表崩溃，因为它无法关闭并重新启动吗？

编辑：

root@server [/var/lib/mysql/user_motiva]# myisamchk -e *.MYI
Checking MyISAM file: wp_options.MYI
Data records:    1827   Deleted blocks:       3
myisamchk: warning: 3 clients are using or haven't closed the table properly
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
- check data record references index: 2
- check records and index references
MyISAM-table 'wp_options.MYI' is usable but should be fixed
root@server [/var/lib/mysql/user_motiva]# myisamchk --safe-recover wp_options.MYI
- recovering (with keycache) MyISAM-table 'wp_options.MYI'
Data records: 1827
myisamchk: error: Can't create new tempfile: 'wp_options.TMD'
MyISAM-table 'wp_options.MYI' is not fixed because of errors
Try fixing it by using the --safe-recover (-o), the --force (-f) option or by not using the --quick (-q) flag
root@ns2 [/var/lib/mysql/user_motiva]# myisamchk -o -f wp_options.MYI
- recovering (with keycache) MyISAM-table 'wp_options.MYI'
Data records: 1827

这是否意味着它现在已经修复？如果是这样，我该如何将其移回？（这是在另一台服务器上完成的）有没有办法在主服务器上关闭 MySQL 并运行命令来修复所有文件？

答案1

mysqlcheck 运行一系列操作：检查、修复、分析和优化。您当前正在跳至“修复”(-r)，但实际上应该从“检查”开始，只是为了查看发生了什么，并查看是否有任何响应：

mysqlcheck --check --quick user_motiva wp_options

如果需要密码（例如，不在配置文件中），请添加“-p”。

如果通过了，请尝试不使用“--quick”。一旦您确定了问题（如果有），继续操作应该会更容易。

顺便说一句，“myisamchk”是检查表的另一种方法。这里的主要区别在于它是在数据库未运行时使用的。使用哪种方法取决于您是否需要为了其他数据而继续运行。

答案2

这是否意味着现在已经修复？

不，不是。您粘贴的输出清楚地表明

MyISAM-table 'wp_options.MYI' is not fixed because of errors

原因似乎是

myisamchk: error: Can't create new tempfile: 'wp_options.TMD'

您可以检查执行 myisamchk 的用户是否具有在数据目录中创建文件所需的权限，文件是否尚未具有“错误”的权限，以及是否可以在文件系统上创建文件（即它不是以只读方式安装的，有错误或已满）。

请注意，您正在修复仅包含指数信息（按给定顺序排序存储的索引数据库列的副本，以加快搜索速度）。因此，如果索引文件（.MYI）在修复/安装数据库时导致问题，请考虑将其从数据目录中删除，启动 MySQL 守护程序并运行REPAIR TABLE wp_options以从数据文件中的数据重建索引信息。

如果数据文件本身（.MYD）受到损坏，则应myisamchk在.MYD 文件上运行没有首先使用-e选项作为myisamchk 文档明确说明“除非你绝望，否则不要使用此选项。”

答案3

运行 mysqlrepair 数据库时，我遇到了完全相同的问题。

问题 1 是：/etc/passwd文件中用户的groupid 错误。它与文件中mysql组的 groupid 不同， 请检查并根据需要进行更正mysql/etc/group前继续下一步。

问题 2 是：在修复运行期间，通常会在目录下为每个数据库表创建文件 *.TMD /var/lib/mysql/database。可通过运行以下命令修复此问题：

rm /var/lib/mysql/*/*.TMD

然后成功运行：

mysqlrepair -p database

其中 -p 表示提供的密码。如果需要，还请添加 -uusername。

相关内容