![MySQL 表未修复](https://linux22.com/image/607393/MySQL%20%E8%A1%A8%E6%9C%AA%E4%BF%AE%E5%A4%8D.png)
表格信息:
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。