Para tabelas ARCHIVE, a única maneira que encontrei para corrigir foi substituir os arquivos da tabela, de um dos servidores escravos. Mas por favor pessoal, se alguém como uma solução para isso, por favor nos ajude, para evitar futuros desastres
Eu tenho uma tabela ARCHIVE
que simplesmente não consigo reparar, eu já tentei remover o particionamento mas ainda assim recebi este erro:
alter table promo_tool_view_44 REMOVE PARTITIONING;
ERROR 1034 (HY000): Incorrect key file for table 'promo_tool_view_44'; try to repair it
Eu já tentei consertar a mesa, mas recebo esta resposta: tabela de reparos promo_tool_view_1;
+-----------------------------+--------+----------+-----------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------------------+--------+----------+-----------------------------+
| vad_stats.promo_tool_view_1 | repair | error | Partition p1 returned error |
| vad_stats.promo_tool_view_1 | repair | error | Corrupt |
+-----------------------------+--------+----------+-----------------------------+
2 rows in set (0.21 sec)
Como posso resolver isso?
Obrigado,
Pedro
Para tabelas ARCHIVE, a única maneira que encontrei para corrigir foi substituir os arquivos da tabela, de um dos servidores escravos. Mas por favor pessoal, se alguém como uma solução para isso, por favor nos ajude, para evitar futuros desastres
Se você ainda não fez isso: Encerre seu banco de dados e faça backup dele. As operações de reparo são perigosas.
É triste dizer que recomendo uma fita de backup. Algo está obviamente quebrado na partição p1. Mas há alguns truques que podem recuperar seus dados.
myisamchk implementa muitas coisas não encontradas no cli. Experimente
myisamchk --safe-recover
myisamchk --recover
nessa ordem e veja se você tem mais sorte. Existem muitas bandeiras que podem ajudá-lo. A documentação completa pode ser encontrada em
A documentação completa para reparo no cli pode ser encontrada no link
Uma vez que você tenha terminado de consertar, você deve descobrir por que você está com o banco de dados corrompido em primeiro lugar. Isso não é normal para bancos de dados MySQL.
Tags mysql disaster-recovery