Otimizar recuperação de banco MySQL corrompido no AlmaLinux 9

17 min de leitura  ·  Guia técnico

Recuperar banco MySQL corrompido é o processo de diagnosticar e restaurar tabelas ou tablespaces danificados no MySQL, permitindo que o banco de dados volte a operar normalmente. Para recuperar um banco MySQL corrompido no AlmaLinux 9, siga estes passos:

1. Identifique as tabelas corrompidas verificando o log de erros e executando CHECK TABLE.
2. Faça um dump de segurança de todos os dados ainda acessíveis antes de qualquer intervenção.
3. Para tabelas MyISAM, execute REPAIR TABLE ou use mysqlcheck via linha de comando.
4. Para tabelas InnoDB, configure innodb_force_recovery no /etc/my.cnf e reinicie o serviço.
5. Exporte os dados recuperados com mysqldump, recrie o banco limpo e importe o dump.
6. Remova o parâmetro innodb_force_recovery, reinicie o MySQL em modo normal e valide a integridade.

Pré-requisitos para recuperar banco MySQL corrompido no AlmaLinux 9

• Acesso root ou sudo ao servidor AlmaLinux 9 via SSH.
• MySQL 8.0 instalado e com o serviço mysqld presente (mesmo que parado ou com falhas).
• Espaço em disco suficiente para armazenar um dump completo do banco — verifique com df -h.
• Credenciais do usuário root do MySQL ou de um usuário com privilégios SUPER e RELOAD.
• Acesso de leitura ao diretório de dados do MySQL, geralmente em /var/lib/mysql/.
• Conhecimento básico de linha de comando Linux; se precisar de referência, consulte Acessando servidores VPS Linux da AviraHost.

Como identificar corrupção em banco de dados MySQL no AlmaLinux 9

O primeiro passo para recuperar banco MySQL corrompido é confirmar que a corrupção realmente existe e mapear quais objetos estão afetados. Agir sem diagnóstico preciso pode agravar o problema.

Verifique o log de erros do MySQL para mensagens de corrupção:

sudo tail -n 100 /var/log/mysql/error.log

Procure por mensagens como Table './banco/tabela' is marked as crashed, InnoDB: Database page corruption ou Got error 126 when reading table. Essas mensagens indicam o tipo e a localização do dano.

Em seguida, conecte-se ao MySQL e execute o comando de verificação de integridade:

mysql -u root -p

CHECK TABLE nome_do_banco.nome_da_tabela EXTENDED;

Output esperado (tabela saudável):
+---------------------------+-------+----------+----------+
| Table                     | Op    | Msg_type | Msg_text |
+---------------------------+-------+----------+----------+
| nome_do_banco.nome_tabela | check | status   | OK       |
+---------------------------+-------+----------+----------+

Output esperado (tabela corrompida):
+---------------------------+-------+----------+---------------------------------------------------+
| Table                     | Op    | Msg_type | Msg_text                                          |
+---------------------------+-------+----------+---------------------------------------------------+
| nome_do_banco.nome_tabela | check | error    | Table is marked as crashed and should be repaired |
+---------------------------+-------+----------+---------------------------------------------------+

Para verificar todas as tabelas de um banco de uma só vez sem entrar no cliente MySQL, use o mysqlcheck:

mysqlcheck -u root -p --all-databases --check

Output esperado:
banco_producao.usuarios                            OK
banco_producao.pedidos                             Table is marked as crashed
banco_producao.produtos                            OK

Anote todos os bancos e tabelas com status diferente de OK antes de prosseguir.

Fazer backup de segurança antes de qualquer recuperação

Antes de executar qualquer comando de reparo, é obrigatório tentar extrair os dados ainda legíveis. Mesmo que o banco esteja parcialmente corrompido, o mysqldump pode conseguir exportar a maioria das tabelas íntegras.

Atenção: Nunca execute comandos de reparo sem antes tentar um dump de segurança. Algumas operações de recuperação são irreversíveis e podem agravar a perda de dados.

Tente exportar o banco completo ignorando erros:

mysqldump -u root -p \
  --single-transaction \
  --quick \
  --lock-tables=false \
  --force \
  nome_do_banco > /root/backup_emergencia_$(date +%Y%m%d_%H%M%S).sql

Se o mysqldump travar em uma tabela específica, exporte tabela por tabela, pulando as corrompidas:

mysqldump -u root -p nome_do_banco tabela_saudavel1 tabela_saudavel2 \
  > /root/backup_tabelas_ok.sql

Copie também o diretório de dados brutos como contingência:

sudo cp -a /var/lib/mysql/ /root/mysql_backup_raw_$(date +%Y%m%d)/

Recuperar tabelas MyISAM corrompidas com REPAIR TABLE e mysqlcheck

Tabelas MyISAM são mais suscetíveis à corrupção de índices após quedas abruptas. A recuperação de tabelas MyISAM danificadas é geralmente mais direta do que em InnoDB.

Dentro do cliente MySQL, execute o reparo direto:

REPAIR TABLE nome_do_banco.nome_da_tabela;

Output esperado:
+---------------------------+--------+----------+----------+
| Table                     | Op     | Msg_type | Msg_text |
+---------------------------+--------+----------+----------+
| nome_do_banco.nome_tabela | repair | status   | OK       |
+---------------------------+--------+----------+----------+

Se o reparo simples falhar, tente com a opção USE_FRM, que reconstrói o índice a partir do arquivo .frm:

REPAIR TABLE nome_do_banco.nome_da_tabela USE_FRM;

Para reparar todas as tabelas MyISAM de todos os bancos via linha de comando (sem entrar no cliente MySQL), use o mysqlcheck com a flag de reparo:

mysqlcheck -u root -p --auto-repair --all-databases

Output esperado:
banco_producao.pedidos
error    : Table is marked as crashed
status   : OK  (após reparo automático)

Você também pode usar a ferramenta myisamchk diretamente nos arquivos, mas para isso o MySQL deve estar parado:

sudo systemctl stop mysqld
sudo myisamchk -r /var/lib/mysql/nome_do_banco/nome_da_tabela.MYI
sudo systemctl start mysqld

Recuperar tabelas InnoDB corrompidas com innodb_force_recovery no AlmaLinux 9

A recuperação de banco InnoDB corrompido exige uma abordagem diferente, pois o mecanismo transacional do InnoDB não permite reparo direto via SQL. O parâmetro innodb_force_recovery força o MySQL a iniciar mesmo com o tablespace danificado, permitindo exportar os dados.

Atenção: Níveis de innodb_force_recovery acima de 4 podem ignorar páginas corrompidas e causar perda parcial de dados. Sempre comece pelo nível mais baixo e aumente progressivamente apenas se necessário.

Edite o arquivo de configuração do MySQL:

sudo nano /etc/my.cnf

Adicione dentro da seção [mysqld]:

[mysqld]
innodb_force_recovery = 1

Reinicie o MySQL e verifique se o serviço sobe:

sudo systemctl restart mysqld
sudo systemctl status mysqld

Output esperado:
● mysqld.service - MySQL 8.0 Database Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
   Active: active (running) since ...

Se o MySQL não subir com nível 1, aumente progressivamente para 2, 3, 4 (nunca vá além de 4 sem entender as implicações). Com o serviço ativo, exporte imediatamente todos os dados:

mysqldump -u root -p \
  --single-transaction \
  --all-databases \
  --force \
  > /root/dump_recuperacao_innodb.sql

Após o dump bem-sucedido, pare o MySQL, remova o parâmetro de força, apague o diretório de dados corrompido e recrie o banco:

sudo systemctl stop mysqld

Atenção: O comando abaixo apaga permanentemente todos os dados do diretório MySQL. Execute apenas se você já tiver o dump completo e validado.

sudo rm -rf /var/lib/mysql/*
sudo mysqld --initialize --user=mysql
sudo systemctl start mysqld

Recupere a senha temporária gerada na inicialização:

sudo grep 'temporary password' /var/log/mysql/error.log

Defina uma nova senha root e importe o dump:

mysql -u root -p --connect-expired-password -e "ALTER USER 'root'@'localhost' IDENTIFIED BY 'NovaSenhaForte123!';"
mysql -u root -p < /root/dump_recuperacao_innodb.sql

Para referência sobre boas práticas de otimização do MySQL após a recuperação, veja também as Dicas de Otimização de Servidores Linux.

Validar integridade do banco após a recuperação

Após concluir o processo de recuperação de banco de dados MySQL, é essencial validar que todos os objetos estão íntegros antes de colocar a aplicação de volta em produção.

Execute uma verificação completa em todos os bancos:

mysqlcheck -u root -p --all-databases --check --extended

Output esperado (banco saudável):
banco_producao.usuarios    OK
banco_producao.pedidos     OK
banco_producao.produtos    OK

Verifique se as tabelas InnoDB estão com o status correto dentro do MySQL:

SELECT table_schema, table_name, engine, table_rows, data_length
FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema', 'performance_schema', 'mysql', 'sys')
ORDER BY table_schema, table_name;

Teste consultas reais nas tabelas mais críticas da aplicação para confirmar que os dados estão acessíveis e consistentes. Verifique também o log de erros por alguns minutos após reiniciar em modo normal:

sudo tail -f /var/log/mysql/error.log

Se nenhuma mensagem de corrupção aparecer nos primeiros minutos de operação normal, a recuperação foi bem-sucedida.

Configurar prevenção de corrupção MySQL no AlmaLinux 9

Prevenir a corrupção futura de tabelas MySQL é tão importante quanto saber recuperá-las. As configurações de durabilidade do InnoDB são o principal mecanismo de proteção contra danos causados por quedas de energia ou reinicializações abruptas.

Edite o /etc/my.cnf e adicione ou confirme os seguintes parâmetros na seção [mysqld]:

[mysqld]
# Durabilidade máxima — garante que cada transação seja gravada no disco
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

# Tamanho do buffer pool — ajuste conforme a RAM disponível (ex: 70% da RAM)
innodb_buffer_pool_size = 1G

# Formato de arquivo moderno (padrão no MySQL 8.0)
innodb_file_per_table = ON

# Log de erros detalhado
log_error = /var/log/mysql/error.log
log_error_verbosity = 3

Aplique as configurações reiniciando o serviço:

sudo systemctl restart mysqld

Configure backups automáticos com mysqldump via cron para garantir que você sempre tenha um ponto de restauração recente. Adicione ao crontab do root:

sudo crontab -e

# Backup diário às 2h da manhã
0 2 * * * mysqldump -u root -pSuaSenha --all-databases --single-transaction \
  > /backups/mysql/dump_$(date +\%Y\%m\%d).sql 2>> /var/log/mysql_backup.log

Monitore o log de erros regularmente para detectar sinais precoces de corrupção antes que se tornem críticos:

sudo grep -i "corrupt\|crashed\|error\|warning" /var/log/mysql/error.log | tail -50

Problemas comuns e como resolver

Sintoma: MySQL não inicia mesmo com innodb_force_recovery = 1

Causa: O nível 1 de recuperação não é suficiente para contornar a corrupção presente no tablespace principal (ibdata1) ou nos redo logs (ib_logfile*).
Solução: Aumente progressivamente o nível de innodb_force_recovery no /etc/my.cnf, testando os valores 2, 3 e 4 em sequência. Após cada alteração, execute sudo systemctl restart mysqld e verifique o status. Se o nível 4 ainda não funcionar, tente remover os redo logs corrompidos (com o MySQL parado): sudo rm /var/lib/mysql/ib_logfile* e reinicie com nível 1 novamente.

Sintoma: mysqldump falha com "Got error: 2006: MySQL server has gone away"

Causa: O servidor MySQL está encerrando a conexão durante o dump, geralmente por timeout ou por encontrar uma página corrompida que causa crash interno.
Solução: Aumente os timeouts no /etc/my.cnf adicionando wait_timeout = 28800 e net_read_timeout = 3600. Em seguida, exporte banco por banco e tabela por tabela, identificando qual objeto específico causa o crash. Use a flag --force no mysqldump para continuar mesmo após erros em tabelas individuais.

Sintoma: REPAIR TABLE retorna "Table is full" ou "Disk full"

Causa: O processo de reparo cria arquivos temporários que podem exceder o espaço disponível em disco, especialmente em tabelas grandes.
Solução: Verifique o espaço disponível com df -h /var/lib/mysql. Libere espaço removendo logs antigos (sudo journalctl --vacuum-time=7d) ou dumps desnecessários. Configure o diretório temporário do MySQL para uma partição com mais espaço adicionando tmpdir = /tmp ou outro caminho com espaço suficiente no /etc/my.cnf.

Sintoma: Após recuperação, aplicação reporta "Table doesn't exist" para tabelas que existem

Causa: O dicionário de dados do InnoDB (armazenado no ibdata1) pode estar dessincronizado com os arquivos .ibd individuais após a recuperação, especialmente quando se usa innodb_file_per_table.
Solução: Execute FLUSH TABLES; dentro do MySQL e verifique se as tabelas aparecem em SHOW TABLES;. Se o problema persistir, descarte e reimporte a tabela específica a partir do dump de recuperação usando DROP TABLE IF EXISTS nome_tabela; seguido de mysql -u root -p banco < dump_tabela.sql.

Perguntas frequentes sobre recuperação de banco MySQL corrompido

Como saber se um banco de dados MySQL está corrompido?

Os sinais mais comuns são erros como Table is marked as crashed, falhas ao executar SELECT ou INSERT, e o daemon mysqld reiniciando sozinho. Execute CHECK TABLE nome_tabela; no MySQL para confirmar a corrupção. O log de erros em /var/log/mysql/error.log também registra mensagens detalhadas sobre tabelas danificadas.

Qual a diferença entre REPAIR TABLE e mysqlcheck para recuperar tabelas corrompidas?

REPAIR TABLE é um comando SQL executado dentro do cliente MySQL e funciona apenas para tabelas MyISAM e ARCHIVE. O mysqlcheck é uma ferramenta de linha de comando que pode verificar e reparar tabelas MyISAM em múltiplos bancos de uma só vez, sem precisar entrar no cliente MySQL. Para tabelas InnoDB, nenhum dos dois repara diretamente — é necessário usar o modo de recuperação innodb_force_recovery no my.cnf.

O innodb_force_recovery apaga dados do banco MySQL?

O innodb_force_recovery em si não apaga dados, mas níveis acima de 4 podem ignorar páginas corrompidas e resultar em perda parcial de registros. Sempre faça um dump completo do banco antes de usar qualquer nível de force_recovery. Após a recuperação, remova o parâmetro do my.cnf e reinicie o MySQL em modo normal para evitar degradação de performance.

Como prevenir corrupção de tabelas MySQL no futuro?

Use exclusivamente o mecanismo InnoDB para novas tabelas, pois ele possui journaling transacional que reduz drasticamente o risco de corrupção em quedas de energia ou reinicializações abruptas. Configure innodb_flush_log_at_trx_commit=1 e sync_binlog=1 para garantir durabilidade. Implemente backups automáticos com mysqldump ou Percona XtraBackup e monitore o log de erros regularmente.

É possível recuperar banco MySQL corrompido sem backup?

Sim, em muitos casos é possível usando o modo innodb_force_recovery para extrair os dados ainda legíveis e recriando as tabelas afetadas. O sucesso depende do nível de corrupção: corrupções superficiais (índices danificados) têm alta taxa de recuperação, enquanto corrupções no tablespace principal (ibdata1) podem resultar em perda parcial de dados. Por isso, backups regulares são indispensáveis.

Conclusão

• Diagnostique antes de agir: sempre verifique o /var/log/mysql/error.log e execute CHECK TABLE ou mysqlcheck para mapear exatamente quais tabelas estão corrompidas antes de qualquer intervenção.
• Dump de segurança é obrigatório: mesmo com o banco parcialmente corrompido, tente exportar os dados acessíveis com mysqldump --force antes de executar qualquer reparo ou recriar o ambiente.
• Previna com InnoDB e backups automáticos: configure innodb_flush_log_at_trx_commit=1, use innodb_file_per_table=ON e implemente dumps automáticos via cron para garantir que uma recuperação futura seja rápida e sem perda de dados.

Leia também

• Otimizar tabelas MySQL para melhorar performance do zero em 15 min
• Migrar banco de dados MySQL entre servidores Linux sem perda
• Guia: Laravel não conecta ao MySQL no Debian 12

Precisa de ajuda com recuperação de banco MySQL?

Lidar com banco de dados corrompido em produção é uma situação de alta pressão. Um ambiente de hospedagem bem configurado, com snapshots automáticos e suporte técnico especializado, pode reduzir significativamente o tempo de inatividade nesses cenários.

Conheça os planos de hospedagem da AviraHost com suporte a MySQL e backups automáticos