MySQL表未修复

Question

表信息：

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

当我做一个mysqlcheck -r --所有的数据库--它会挂在桌子上，即使你让它整天坐着。即使是一张支票也会挂在同一个地方。

还有其他方法来修复/修复/恢复那个表吗？

我应该用myisamchk吗我看到了这样的东西：

shell> myisamchk --recover City 

您甚至不能从phpMyAdmin访问/查看数据库，甚至不能在mysql中“使用”而不挂起它。

我在一个16 on内存框上的配置

 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放到主服务器上并运行一个命令来修复所有文件？

Answer 1

mysqlcheck运行许多操作:检查、修复、分析和优化。您目前正在跳到“修复”(-r)，但是应该从“检查”开始，看看发生了什么，看看是否有任何响应：

mysqlcheck --check --quick user_motiva wp_options

如果需要密码，添加"-p“(例如，不在配置文件中)。

如果它通过了，不用“--快”就试一试。一旦发现了问题(如果有的话)，应该更容易处理。

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

Answer 2

这是否意味着它现在是固定的？

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

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

原因似乎是

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

您可以检查您正在执行myisamchk的用户是否具有在数据目录中创建文件的必要权限，如果该文件还没有“错误”权限，以及是否可以在文件系统上创建文件(也就是说，它不是只读的、错误的或已满的)。

请注意，您正在修复只包含索引信息的.MYI文件(按给定顺序存储的索引数据库列的副本，以加快搜索速度)。因此，如果在修复/挂载数据库时导致问题的是索引文件(.MYI)，请考虑将其从数据目录中删除，启动MySQL守护进程并运行REPAIR TABLE wp_options，以便从数据文件中的数据重新生成索引信息。

如果数据文件本身( .MYD )受到损坏的影响，您应该在.MYD文件上运行myisamchk，而不首先使用-e选项，因为myisamchk博士显式声明"不是为了使用此选项，除非您绝望“。

Answer 3

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

问题1是：/etc/passwd文件中对用户mysql的不满。虽然它不同于mysql组在文件/etc/group中的不满，但在继续下一步之前，如果需要，请进行检查和更正。

问题2是:在修复运行期间，为通常是*.TMD目录中的每个数据库表创建文件/var/lib/mysql/database。这是通过运行以下操作来修正的：

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

然后成功地跑了：

mysqlrepair -p database

其中-p提供了密码。如果需要，也请添加-uusername。