Início / dba / Perguntas / 67866
Accepted
Zafar Malik
Asked: 2014-06-10 04:05:33 +0800 CST

tabela temporária (#sql-7a87_230c32.ibd junto com seu .frm) ainda existe no escravo

  • 772

Eu executei algumas instruções de alteração no meu servidor mestre, que foram executadas com sucesso no mestre (agora não há tabela temporária no mestre) e todas as alterações também foram replicadas no servidor escravo com sucesso. Mas ainda estou obtendo tabela temporária no escravo (#sql-7a87_230c32.ibd e #sql-7a87_230c32.frm).

Agora preciso de ajuda para saber os pontos abaixo:

  1. Quando a alteração foi feita com sucesso, por que essa tabela temporária ainda existe e não foi excluída.

  2. Agora, como posso excluir esta tabela temporária e qual será seu impacto.

  3. Posso ler este arquivo temporário ou saber por qualquer comando para qual tabela esta tabela temporária foi criada.

Nota: Se eu excluí-lo de seu caminho de diretório, o mysql lançará uma mensagem de erro relacionada a ele e também não sei qual será seu impacto.

Ficarei muito grato por qualquer ajuda rápida.

2ª atualização

1.. Quando a alteração foi feita com sucesso, por que esta tabela temporária ainda existe e não foi excluída.

Depois de ler #sql-7a87_230c32.frm com a ajuda de seu post, agora está claro que foi minha primeira tabela alterada (alterei 6 tabelas uma a uma).

Abaixo estão alguns fatos que ajudarão a saber o motivo exato-

  1. O tempo de criação do arquivo sql-7a87_230c32.frm é "2014-06-09 01:49:00" e seu arquivo .ibd #sql-7a87_230c32.frm o tempo é "2014-06-09 03:34:00" e seu tamanho é 3,4 GB, enquanto o tamanho do arquivo principal é de 6,8 GB

  2. Depois de verificar os logs do servidor, descobri que o escravo estava sendo desligado em "2014-06-09 03:33:05" (tenho que verificar se isso foi feito pela equipe de administração do sistema, mesmo que eles estivessem cientes dessa atividade do banco de dados ou dele mesmo) e reiniciado quando alter estava executando no escravo.

  3. Esta hora de criação de tabela no escravo está mostrando como "2014-06-09 04:43:32".

Depois de analisar os fatos acima, parece que a primeira vez que a declaração de alteração nesta tabela foi executada perto de "2014-06-09 01:49:00", mas sem copiar completamente (como o tamanho da tabela .ibd temporária é menor que seu tamanho original), ela foi rolada de volta quando o servidor foi desligado perto de "2014-06-09 03:33:05", mas o sistema não removeu essas tabelas temporárias. Agora, novamente, quando o escravo subiu, foi iniciada a replicação novamente no mesmo ponto e agora a tabela alterada com sucesso, que foi concluída em "2014-06-09 04:43:32".

Mas, de acordo com meu entendimento, neste caso, as tabelas temporárias devem ser removidas junto com a reversão, mas neste caso isso não foi feito. Por favor, ajude-me a limpá-lo.

mysql replication

1 respostas

  1. Best Answer

    Espero poder responder adequadamente porque odeio tabelas temporárias que usam InnoDB. Aqui está o porquê

    Arquitetura InnoDB

    Neste diagrama, o dicionário de dados tem essa tabela temporária como entrada. Depois que a tabela temporária terminar de ser usada para ALTER TABLE, a entrada do dicionário de dados deve desaparecer.

    Aqui estão suas perguntas e minha resposta para elas ...

    1.. Quando a alteração foi feita com sucesso, por que esta tabela temporária ainda existe e não foi excluída.

    Em circunstâncias normais, quando uma conexão de banco de dados termina, todas as tabelas temporárias abertas devem ser descartadas. A única razão pela qual uma tabela temporária permanecerá após a conclusão de uma ALTER TABLEé se a conexão do banco de dados em execução for ALTER TABLEencerrada antes que a tabela temporária possa ser descartada. É possível que os segmentos de rollback (Ver Diagrama) tenham as informações originais da tabela antes da ALTER TABLEemissão.

    Como você mencionou que isso está acontecendo no Slave, o único suspeito (ou pessoa de interesse) para esse problema seria o thread SQL para MySQL Replication. Por quê? É o proprietário das tabelas temporárias que precisam concluir o SQL que está sendo executado a partir dos logs de retransmissão. Se você matar um thread SQL de uma maneira diferente STOP SLAVE;enquanto estiver executando um ALTER TABLE, ele pode não descartar tabelas temporárias de maneira ordenada . Assim, você terá uma tabela temporária persistente, independentemente do mecanismo de armazenamento.

    2. Agora, como posso excluir esta tabela temporária e qual será o impacto dela.

    Você pode prosseguir e excluir os arquivos .frme .ibd. Só digo isso porque é mesa temporária. A mesa deveria ter desaparecido. O impacto ? O dicionário de dados ainda terá a tabela temporária registrada. Apenas alguns bytes são desperdiçados.

    Não se preocupe com o nome da tabela temporária sendo usado novamente. Olha o nome da tabela temporária

    #sql-7a87_230c32.ibd

    Existem 10 dígitos hexadecimais. As chances de reutilizar esse nome de tabela temporária são de 1 em 16 10 ou 2 40 que 1,099,511,627,776. Eu acho que você vai ficar bem nisso.

    Não os exclua ainda. Olhe para a sua terceira pergunta ...

    3. Posso ler este arquivo temporário ou saber por qualquer comando para qual tabela esta tabela temporária foi criada.

    Entendo a necessidade desta pergunta. Evidentemente, você quer saber qual era a mesa que estava sendo ALTER TABLEfeita. Infelizmente, você não pode ler nenhuma tabela temporária por meio do SQL padrão.

    No entanto, você provavelmente poderia renomear .frme usar um utilitário para ler a estrutura da tabela.

    Aqui está um post antigo meu para fazer isso com um .frmno ambiente Windows: Como posso extrair o esquema da tabela apenas do arquivo .frm?

    EPÍLOGO

    Mesmo que a tabela temporária não tenha mais um propósito inútil neste ponto, excluir a tabela temporária do InnoDB é aquela chance de 1 em trilhão de que o InnoDB se comporte de forma irregular.

    Seu último recurso quando isso acontecer é executar uma limpeza completa do InnoDB. Veja meu post Howto: Limpar um mecanismo de armazenamento mysql InnoDB? no StackOverflow

    ATUALIZAÇÃO 2014-06-10 08:36 EDT

    Deve ficar evidente nos registros de data e hora do arquivo e no comentário em sua segunda atualização que um desligamento deve ter ocorrido no meio de um arquivo ALTER TABLE. Todas as informações transacionais para MVCC em relação à tabela InnoDB foram mantidas em um estado de animação suspensa em um dos seguintes locais:

    • Logs de transações (também conhecidos como Redo Logs, que são os arquivos ib_logfile0 e ib_logfile1),
    • Segmentos de reversão e espaço de desfazer (localizado no arquivo de tablespace do sistema ibdata1)
    • Double Write Buffer (localizado no arquivo de tablespace do sistema ibdata1)

    Quando você iniciou o backup do mysql, o MVCC para a tabela foi repetido para trazer a tabela original para um estado consistente. Isso pode resultar na reversão da tabela para o estado original anterior ALTER TABLEou, se tudo passou pelos Redo Logs, a tabela agora existe no novo design. O fato de o .ibdarquivo ter um registro de data e hora posterior mostra que o MVCC deve ter sido aplicado a ele na inicialização do mysql (que inclui a recuperação de falhas).

    Uma vez que o desligamento aconteceu, a tabela InnoDB perdeu sua identidade como uma tabela temporária e se tornou uma tabela regular aos olhos do mysqld. Portanto, você poderá excluir os arquivos temporários com impunidade.

    • 2

relate perguntas