Início / dba / Perguntas / 55495
Accepted
Tobia
Asked: 2013-12-24 04:47:07 +0800 CST

Dados perdidos no MySQL InnoDB após falha

  • 772

Encontrei uma reversão de 6 dias em uma instalação do servidor MySQL 5.6 community edition. Parece que alguns logs foram perdidos e não consigo entender o porquê.

2013-12-22 20:38:54 380 [Note] Plugin 'FEDERATED' is disabled.
2013-12-22 20:38:54 380 [Warning] option 'innodb-autoextend-increment': unsigned value 67108864 adjusted to 1000
2013-12-22 20:38:54 388 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2013-12-22 20:38:54 380 [Note] InnoDB: The InnoDB memory heap is disabled
2013-12-22 20:38:54 380 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2013-12-22 20:38:54 380 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-12-22 20:38:54 380 [Note] InnoDB: Not using CPU crc32 instructions
2013-12-22 20:38:54 380 [Note] InnoDB: Initializing buffer pool, size = 86.0M
2013-12-22 20:38:54 380 [Note] InnoDB: Completed initialization of buffer pool
2013-12-22 20:38:54 380 [Note] InnoDB: Highest supported file format is Barracuda.
2013-12-22 20:38:54 380 [Note] InnoDB: The log sequence numbers 5988825 and 5988825 in ibdata files do not match the log sequence number 6057379 in the ib_logfiles!
2013-12-22 20:38:54 380 [Note] InnoDB: Database was not shutdown normally!
2013-12-22 20:38:54 380 [Note] InnoDB: Starting crash recovery.
2013-12-22 20:38:54 380 [Note] InnoDB: Reading tablespace information from the .ibd files...
2013-12-22 20:38:57 380 [Note] InnoDB: Restoring possible half-written data pages 
2013-12-22 20:38:57 380 [Note] InnoDB: from the doublewrite buffer...
2013-12-22 20:39:07 380 [Note] InnoDB: 128 rollback segment(s) are active.
2013-12-22 20:39:07 380 [Note] InnoDB: Waiting for purge to start
2013-12-22 20:39:07 380 [Note] InnoDB: 5.6.13 started; log sequence number 6057379
2013-12-22 20:39:07 380 [Note] Server hostname (bind-address): '*'; port: 3306
2013-12-22 20:39:07 380 [Note] IPv6 is available.
2013-12-22 20:39:07 380 [Note]   - '::' resolves to '::';
2013-12-22 20:39:07 380 [Note] Server socket created on IP: '::'.
2013-12-22 20:39:12 380 [Note] Event Scheduler: Loaded 0 events
2013-12-22 20:39:12 380 [Note] C:/Program Files/MySQL/MySQL Server 5.6/bin\mysqld: ready for connections.

Você pode me dizer por que isso ocorre e como restaurar esses dados? É possível? Você acha que as tabelas MyISAM são mais seguras e um switch poderia resolver esse tipo de erro?

EDITAR

Mais informações sobre este puzzle.

  • Esta máquina possui um volume RAID-1.

  • O problema ocorreu após um desligamento em 22 de dezembro . Após esse desligamento, obtive o log anterior e meu banco de dados teve uma reversão de dados de muitos dias. Encontrei o banco de dados exatamente com dados de 14 de dezembro.

  • De 14 a 21 de dezembro , houve muitos desligamentos graciosos de servidores (todas as noites) e encontrei um backup completo para todos os dias de 14 a 21 de dezembro. O backup de 22 de dezembro tem o intervalo de dados de 8 dias.

Eu acho isso muito estranho. Eu posso entender a perda de dados após um poweroff, mas não consigo entender essa reversão tão grande (8 dias) porque durante esses 8 dias houve muitos desligamentos do servidor e o backup do mysqldump confirma que todos os dados foram armazenados corretamente. Eu suponho que havia um problema de liberação de log do innodb, mas por que tão grande?

Obrigado

innodb mysql-5.6

2 respostas

  1. Este log apenas indica que você não desligou corretamente, portanto, na inicialização, o InnoDB teve que fazer uma "recuperação de falha". Não é a recuperação de falha que teria perdido os dados - é o seu sistema operacional ou hardware. A recuperação de falhas é projetada, na verdade, para evitar a perda de dados devido a falhas (esse é todo o seu propósito).

    A mensagem de log indica um problema grave:

    The log sequence numbers 5988825 and 5988825 in ibdata files do not match the log sequence number 6057379 in the ib_logfiles!

    Isso provavelmente significa que os dados não estão chegando ao disco de forma eficaz devido a uma configuração incorreta no MySQL ou a uma configuração incorreta do seu sistema operacional ou hardware.

    Se você estiver executando com innodb_flush_log_at_trx_commitum valor diferente de 1, a culpa é sua, pois essa é uma configuração perigosa. Se você estiver executando com 1, isso implicaria que o InnoDB está solicitando que os dados sejam gravados no disco e confirmados, mas o sistema está mentindo para o InnoDB sobre a gravação, causando corrupção posteriormente.

    Não há como recuperar os dados. Se você precisar de dados perdidos, deverá restaurá-los a partir do backup.

    O MyISAM definitivamente não é mais seguro e, de fato, o MyISAM provavelmente teria sofrido corrupção extrema nas mesmas circunstâncias.

    • 2
  2. Best Answer

    O problema para mim foi o WINDOWS RESTORE automático após a falha ou desligamento do sistema operacional. Incrivelmente esse procedimento substitui arquivos IBD (índices de bancos de dados)! Resolvi desabilitar a restauração do Windows, não consegui encontrar nenhuma maneira de alterar as extensões dos arquivos de índice mysql ou ignorar os arquivos da restauração do Windows.

    Eu realmente fico bravo e preocupado por meses com esse problema, espero que isso possa ajudá-lo.

    • 2

relate perguntas