Forçando a recuperação

Se ocorre o corrompimento de uma página do banco de dados, você pode desejar fazer um dump de suas tabelas no banco de dados com SELECT INTO OUTFILE, e normalmente a maioria dos dados estará intacto e correto. Mas o corrompimento pode fazer com que SELECT * FROM table, ou operações de background do InnoDB falhe ou apresentem avisos, ou até mesmo a recuperação roll-forward do InnoDB falhe. A partir do InnoDB 3.23.44, existe uma opção do my.cnf com a qual você pode forçar o InnoDB a inicializar, e você também pode prevenir que operações de background sejam executadas, e assim você poderá fazer um dump de suas tabelas. Por exemplo, você pode configurar

set-variable = innodb_force_recovery = 4

no my.cnf.

As alternativas para innodb_force_recovery estão listadas abaixo. O banco de dados não deve ser usado com estas opções! Como medida de segurança o InnoDB previne um usuário de fazer um INSERT, UPDATE, ou DELETE quando esta opção é > 0.

A partir da versão 3.23.53 e 4.0.4, você tem permissão de se fazer um DROP ou CREATE de uma tabela mesmo se a recuperação forçada está sendo usada. Se você sabe que determinada tabela está causando uma falha no rollback, você pode deletá-la. Você pode usar isto também para para um rollback em execução causado por uma falha importanta ou ALTER TABLE. Você pode matar o processo mysqld e usar a opção do my.cnf innodb_force_recovery=3 para trazer o seu banco de dados sem o rollback. Apague então a tabela que está causando o rollback.

Um número maior abaixo significa que todas as precauções de números menores estão incluídas. Se você puder fazer um dump de todas as suas tabelas com uma opção de no máximo 4, então você está relativamente seguro que apenas alguns dados em paginas individuais corrompidas são perdidos. A opção 6 é mais dramática, porque páginas de bancos de dados são deixadas e um estado obsoleto, que podem introduzir mais corrompimento em árvores-B e outras estruturas de banco de dados.

• 1 (SRV_FORCE_IGNORE_CORRUPT) deixa o servidor executar mesmo se ele detectar uma página corrompida; tenta fazer SELECT * FROM table saltar os índices corrompidos e páginas, o que ajuda ao fazer dump de tabelas;
• 2 (SRV_FORCE_NO_BACKGROUND) evita que a thread principal seja executada: se uma falha ocorresse na remoção, isto seria evitado.
• 3 (SRV_FORCE_NO_TRX_UNDO) não executa rollback de transações depois da recuperação;
• 4 (SRV_FORCE_NO_IBUF_MERGE) também previne operações merge no buffer de inserções: se eles causassem falhar, melhor não fazê-los; não calcula as estatísticas da tabelas;
• 5 (SRV_FORCE_NO_UNDO_LOG_SCAN) não procura por undo logs quando iniciar o banco de dados: InnoDB tratará mesmo transações incompletas como comitadas;
• 6 (SRV_FORCE_NO_LOG_REDO) não faça o roll-forward no log em em conexão com recuperação.

Retornar