Eu tenho mysql DB no servidor S1 (mysql versão 5.1.41-3ubuntu12.7-log).
Eu criei master-slave para este banco de dados no servidor S2 (mysql versão 5.1.54-1ubuntu4-log).
O banco de dados em S1 estava usando um arquivo de dados (ibdata).
Depois de despejar o banco de dados no S2, defino innodb_file_per_table=1. Isso fez com que cada tabela tivesse seu próprio arquivo ibd. agora tudo correu bem e sem problemas.
Depois de reiniciar o mysql no S2, enfrentei um problema ao receber este erro:
Error 'Unknown table engine 'InnoDB'' on query. Default database: MyDB
e quando tento mostrar os mecanismos, recebo o seguinte:
mostrar motores; +------------+---------+---------------------- --------------------------------------+----------- ---+------+------------+ | Motor | Suporte | Comentário | Transações | XA | Pontos de Salvamento | +------------+---------+---------------------- --------------------------------------+----------- ---+------+------------+ | MyISAM | PADRÃO | Mecanismo padrão a partir do MySQL 3.23 com ótimo desempenho | NÃO | NÃO | NÃO | | MRG_MYISAM | SIM | Coleção de tabelas MyISAM idênticas | NÃO | NÃO | NÃO | | BURACO NEGRO | SIM | /dev/null mecanismo de armazenamento (qualquer coisa que você escreve desaparece) | NÃO | NÃO | NÃO | | CSV | SIM | mecanismo de armazenamento CSV | NÃO | NÃO | NÃO | | MEMÓRIA | SIM | Baseado em hash, armazenado na memória, útil para tabelas temporárias | NÃO | NÃO | NÃO | | FEDERADO | NÃO | Mecanismo de armazenamento MySQL federado | NULO | NULO | NULO | | ARQUIVO | SIM | Mecanismo de armazenamento de arquivo | NÃO | NÃO | NÃO | +------------+---------+---------------------- --------------------------------------+----------- ---+------+------------+
InnoDB não está listado.
No log de erros, posso ver isso:
InnoDB: O banco de dados grava fisicamente o arquivo completo: aguarde... InnoDB: Não é possível inicializar os arquivos de log criados porque InnoDB: os arquivos de dados estão corrompidos ou novos arquivos de dados foram InnoDB: criado quando o banco de dados foi iniciado anteriormente InnoDB: tempo, mas o banco de dados não foi encerrado InnoDB: normalmente depois disso. 111016 8:24:11 [ERRO] A função init do plug-in 'InnoDB' retornou um erro. 111016 8:24:11 [ERRO] Falha no registro do plug-in 'InnoDB' como STORAGE ENGINE. 111016 8:24:11 [Aviso] Nem --relay-log nem --relay-log-index foram usados; então a replicação pode quebrar quando este servidor MySQL agir como um escravo e tiver seu nome de host alterado!! Use '--relay-log=S2-relay-bin' para evitar esse problema.
Eu tentei excluir ib_logfiles, mas isso também não funcionou. se eu excluir ib_logfiles e arquivo ibdata, innodb retornará normalmente, mas não consigo acessar minhas tabelas innodb, ou seja. depois de deletar ibdata1 e reiniciar o mysql
artigo desc; ERRO 1146 (42S02): Tabela 'MyDb.article' não existe
Minha configuração innodb em my.cnf é a seguinte:
innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size = 384M
innodb_log_file_size=5M
innodb_lock_wait_timeout = 18000
embora a mesa esteja lá!!
Alguém já enfrentou esse problema antes?
Qualquer ideia é muito apreciada
Obrigado
Tenho más notícias para você.
Você não deveria ter excluído o arquivo ibdata1. Aqui está o porquê:
ibdata1 contém quatro tipos de informações:
Cada tabela InnoDB criada tem um id numérico atribuído a ela por meio de algum recurso de metadados de incremento automático para cada arquivo ibd. Esse id de espaço de tabela interno (ITSID) está embutido no arquivo .ibd. Esse número é verificado em relação à lista de ITSIDs mantida, adivinhe onde, ... ibdata1.
Eu também tenho boas notícias para você, juntamente com algumas más notícias.
É possível reconstruir ibdata1 para ter os ITSIDs corretos, mas dá trabalho fazer isso. Embora eu pessoalmente não tenha feito o procedimento sozinho, ajudei um cliente na hospedagem na web do meu empregador a fazer isso. Descobrimos isso juntos, mas como o cliente manobrou ibdata1, deixei que ele fizesse a maior parte do trabalho (30 tabelas InnoDB).
Enfim, aqui um post passado que fiz no DBA StackExchange. Respondi a outra pergunta cuja causa raiz era a mistura de ITSIDs.
Para ir direto ao ponto, aqui está o artigo explicando o que fazer com referência ao ITSID e como massagear ibdata1 para reconhecer a presença do ITSID contido no arquivo .ibd .
Lamento não haver um método rápido e sujo para recuperar o arquivo .ibd além de jogar com ITSIDs.
ATUALIZAÇÃO 2011-10-17 06:19 EDT
Aqui está sua configuração innodb original da sua pergunta:
Observe que innodb_log_file_size está lá duas vezes. Olhe com cuidado...
A última configuração de innodb_log_file_size tem precedência. Espera-se que o MySQL inicialize com os arquivos de log sendo 5M. Seu ib_logfile0 e ib_logfile1 eram 1G quando você tentou iniciar o mysqld. Ele viu um conflito de tamanho e escolheu o caminho de menor resistência, que foi desabilitar o InnoDB. É por isso que o InnoDB estava ausente do
show engines;. Mistério resolvido !!!ATUALIZAÇÃO 2011-10-17 11:07 EDT
A mensagem de erro era enganosa porque innodb_log_file_size era menor que os arquivos de log (ib_logfile0 e ib_logfile1), que eram 1G na época. O que é interessante é o seguinte: a corrupção foi relatada porque o arquivo deveria ter 5M e os arquivos eram maiores. Se a situação fosse inversa e os arquivos de log do innodb fossem menores que o tamanho declarado em my.cnf, você deveria obter algo como isto no log de erro:
Neste exemplo, os arquivos de log já existiam como 5M e a configuração para innodb_log_file_size era maior (neste caso, 32M).
Para esta questão em particular, culpo o MySQL (eh Oracle [ainda odeio dizer isso]) pelo protocolo de mensagem de erro inconsistente.
O log de erros indica que você tem alguns dados corrompidos. Quando isso acontece, o InnoDB não fica disponível em
SHOW ENGINES. Você pode tentar forçar a recuperação executando as seguintes etapas:innodb_force_recovery=1ao seu arquivo my.cnfEspero que esteja lá e você possa rediscutir seus dados e recarregá-los no S2.
No meu caso, usar
innodb_force_recovery=1não funcionou. Então descobri que havia uma segunda instância do mysql em execução que não aceitaria nenhuma conexão e matar com-1não funcionou, então optei por reiniciar o servidor.Depois que reiniciei, corri
start slavee tudo voltou ao normal por conta própria.