Tabela MySQL não reparando

Question

Informações da tabela:

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

quando eu faço um mysqlcheck -r --all-databases ele fica pendurado naquela tabela mesmo que você deixe ele ficar todo o dia. Mesmo apenas um cheque fica pendurado no mesmo lugar.

Existe outra maneira de corrigir / reparar / recuperar essa tabela?

Devo usar o myisamchk? Eu vi algo como:

shell> myisamchk --recover City 

Você não pode nem mesmo acessar / visualizar o banco de dados a partir do phpMyAdmin ou até mesmo de "USE;" no mysql sem ele apenas pendurado.

Minha configuração em uma caixa de 16 GB

 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

É por causa de uma tabela com falha de fazer killall -9 mysqld porque ele não iria desligar e reiniciar?

EDITAR:

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

Isso significa que agora está corrigido? Se sim, como faço para voltar? (isso foi feito em um servidor diferente) Existe uma maneira de talvez colocar o MySQL no servidor principal e executar um comando para corrigir todos os arquivos?

    

Answer 1

O mysqlcheck executa diversas ações: verificar, reparar, analisar e otimizar. Você está pulando para "reparar" (-r), mas deve começar com "verificar" apenas para ver o que está acontecendo e ver se há alguma resposta:

mysqlcheck --check --quick user_motiva wp_options

Adicione "-p" se uma senha for necessária (por exemplo, não em um arquivo de configuração).

Se isso acontecer, tente sem o "--quick". Depois de identificar o problema (se houver), será mais fácil prosseguir.

A propósito, "myisamchk" é outra maneira de verificar tabelas. A principal diferença aqui é que ela é usada quando o banco de dados não está em execução. O que usar depende de você precisar ou não continuar executando em prol de outros dados.

    

Answer 2

Does this mean that it is now fixed?

Não, isso não acontece. Sua saída colada afirma claramente

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

E a razão para isso parece ser

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

Você pode verificar se o usuário que está executando o myisamchk possui as permissões necessárias para criar arquivos no diretório de dados, se o arquivo já não estiver presente com permissões "erradas" e se arquivos podem ser criados no sistema de arquivos ( isto é, não é montado somente para leitura, tem erros ou está cheio).

Observe que você está reparando os arquivos .MYI que contêm apenas informações índice (cópias de colunas de banco de dados indexadas armazenadas classificadas em uma determinada ordem para acelerar as pesquisas). Portanto, se for o arquivo de índice (.MYI) que está causando o problema ao reparar / montar o banco de dados, considere simplesmente removê-lo do diretório de dados, iniciando o daemon do MySQL e executando REPAIR TABLE wp_options para reconstruir as informações de índice a partir dos dados o arquivo de dados.

Se o próprio arquivo de dados (.MYD) for afetado pela corrupção, você deve executar myisamchk no arquivo .MYD sem usando a opção -e primeiro como o myisamchk docs indica explicitamente " [não] para usar essa opção, a menos que você esteja desesperado. "

    

Answer 3

Entrei exatamente no mesmo problema, ao executar o banco de dados mysqlrepair.

O problema 1 foi: ID de grupo incorreto no arquivo /etc/passwd do usuário mysql . Embora fosse diferente de groupid do grupo mysql no arquivo /etc/group Por favor, verifique e corrija se necessário antes de continuar para o próximo passo.

O problema 2 foi: durante a execução do reparo, os arquivos * .TMD são criados para cada tabela do banco de dados no diretório /var/lib/mysql/database . Isso é corrigido executando:

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

e, em seguida, executar com sucesso:

mysqlrepair -p database

onde -p para senha fornecida. Por favor, adicione também -uusername, se necessário.