Corrigir o erro "DB Error: DB Failure / Corruption" nos logs da caixa de correio do Zimbra: Diagnóstico e recuperação seguros

A mensagem “Erro de banco de dados: Falha no banco de dados” em um log de caixa de correio do Zimbra é um sintoma, não um diagnóstico. Pode indicar um banco de dados parado, uma conexão com falha, espaço em disco esgotado, excesso de conexões ou corrupção real de tabelas ou do banco de dados InnoDB. A solução segura depende das linhas de log adjacentes e do servidor afetado. Comece com verificações somente leitura, proteja os dados e não execute um comando de reparo genérico apenas porque a palavra “corrupção” aparece.

Este guia utiliza caminhos e comandos comuns do Zimbra documentados no Centro Técnico do Zimbra. Algumas páginas wiki relacionadas estão marcadas como arquivadas ou incompletas, portanto, confirme cada comando e procedimento de recuperação com base na sua edição e versão exatas do Zimbra, utilizando o índice de documentação oficial do Zimbra . Os exemplos abaixo não pressupõem uma versão específica.

O que significa exatamente uma falha no banco de dados registrada no arquivo mailbox.log?

O banco de dados de caixas de correio do Zimbra armazena metadados das caixas de correio, como pastas, tags, estado das mensagens e ponteiros para arquivos de mensagens. Os índices de pesquisa são armazenados separadamente e o conteúdo das mensagens é armazenado no repositório de mensagens. Portanto, um erro no banco de dados não significa automaticamente que todos os arquivos de e-mail estejam corrompidos. Da mesma forma, um erro de índice por si só não comprova danos no banco de dados. O Zimbra descreve esses repositórios separados em sua referência de arquitetura de servidor .

A pista decisiva geralmente é o erro subjacente do banco de dados que aparece próximo à exceção da caixa de correio, especialmente em /opt/zimbra/log/mysql_error.log. As notas de solução de problemas do Zimbra identificam mailbox.loge mysql_error.logcomo pontos de partida úteis, com zmmailboxd.outfornecendo detalhes de inicialização do serviço de caixa de correio. Consulte a referência de solução de problemas de logs do Zimbra .

O que você deve fazer antes de tentar uma solução?

• Registre o horário da primeira ocorrência, o fuso horário, o nome do host do servidor, a(s) conta(s) afetada(s) e a exceção completa, incluindo as linhas adjacentes. Oculte senhas, conteúdo da mensagem e dados pessoais antes de compartilhar os registros.
• Determine o escopo: uma caixa de correio, várias caixas de correio em um mesmo repositório ou usuários em vários repositórios. Um sintoma em uma única conta não justifica a reinicialização do banco de dados em todo o cluster.
• Verifique se existe um backup recente e utilizável e identifique o procedimento de restauração específico da versão. Se os erros se repetirem ou se os usuários forem afetados ativamente, evite reinicializações e gravações repetidas até que o estado do banco de dados seja compreendido.
• Utilize uma janela de manutenção para verificações que examinam tabelas do banco de dados. Mesmo uma verificação de integridade pode adicionar operações de E/S e tornar o serviço de caixa de correio mais lento.

Como diagnosticar isso com segurança?

1. Verifique o estado do serviço.

No servidor de caixa de correio, acesse a conta Zimbra e verifique o status do serviço. Execute os comandos como a conta exibida em cada prompt; não copie e cole símbolos de prompt, como `\`, como $parte do comando.

su - zimbra
zmcontrol status

Verifique se a caixa de correio está em execução e se o problema relatado é local a um único servidor de caixa de correio. Um processo de caixa de correio interrompido não é suficiente para concluir que o banco de dados está corrompido. A página de solução de problemas de caixa de correio do Zimbra também lista o status do serviço e o login/configuração do banco de dados como verificações separadas; essa página está marcada como arquivada, portanto, use-a como referência e siga a documentação da sua versão.

2. Comparar simultaneamente os registros de caixa de correio e de banco de dados.

Leia o mesmo intervalo de tempo em ambos os registros. O primeiro erro na sequência costuma ser mais útil do que a linha final de "falha do sistema".

tail -n 100 /opt/zimbra/log/mailbox.log
tail -n 100 /opt/zimbra/log/mysql_error.log
tail -n 100 /opt/zimbra/log/zmmailboxd.out

Procure pela mensagem subjacente do banco de dados, nome do banco de dados ou grupo de caixas de correio, registros de data e hora repetidos, falhas na inicialização ou um erro correspondente do sistema operacional. Considere essas frases como pistas, não como soluções automáticas:

3. Verifique a capacidade do disco e erros do sistema operacional.

Volumes de dados ou de logs cheios, inodes esgotados ou falhas de armazenamento podem ser interpretados como uma falha de banco de dados. Execute verificações não destrutivas no host de armazenamento:

df -h /opt/zimbra
df -i /opt/zimbra

Verifique o diário do sistema operacional ou o log do sistema em busca de erros de E/S de disco, sistema de arquivos ou falta de memória no mesmo intervalo de tempo. Se um volume estiver cheio, libere ou adicione espaço usando seu procedimento normal de armazenamento. Não exclua arquivos de banco de dados, logs do InnoDB ou logs ativos do Zimbra para liberar espaço; isso pode dificultar a recuperação ou destruir evidências.

4. Execute uma verificação de integridade somente após analisar o impacto.

Se o serviço de banco de dados do Zimbra estiver acessível e os registros não indicarem claramente um problema de conexão ou armazenamento, o administrador pode considerar o relatório de integridade padrão durante uma janela de manutenção com baixo tráfego:

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

A documentação do relatório de integridade do Zimbra descreve isso como uma verificação de banco de dados e alerta que pode adicionar operações de E/S e aumentar a latência da caixa de correio. Também documenta uma -ropção para tentar o reparo automático da tabela. Não adicione -ressa opção como uma próxima etapa de rotina: a página está em desenvolvimento e a ação correta depende do mecanismo de banco de dados, do tipo de tabela, da versão do produto e do status do backup. Um relatório que menciona apenas uma mensagem conhecida de bloqueio de tabela de log inofensivo deve ser interpretado de acordo com a nota na página; não trate todos os cabeçalhos "Erros de banco de dados encontrados" como iguais.

Qual solução corresponde às evidências?

• O serviço de banco de dados foi interrompido, mas não há evidências de corrupção: primeiro, resolva o erro específico de inicialização, configuração, credenciais ou recursos. Após a correção, utilize o procedimento de recuperação de serviço para sua versão e topologia de implantação. Evite reinicializações repetidas sem solução.
• Excesso de conexões: investigue a carga, clientes travados e a capacidade do serviço. Não classifique o problema como corrupção do banco de dados nem copie uma recomendação antiga para aumentar os limites sem verificar as diretrizes de dimensionamento e versão atuais.
• Problema de disco ou sistema de arquivos: estabilize o armazenamento e confirme se o sistema de arquivos está íntegro. Se o banco de dados registrou falhas de gravação ou erros do InnoDB, trate isso como um possível incidente de integridade, mesmo após a restauração do espaço.
• O relatório de integridade sinaliza tabelas: salve a saída exata, os nomes das tabelas/bancos de dados, os registros de data e hora e os logs relevantes. Faça backup ou crie um snapshot do volume do banco de dados usando um método compatível antes de qualquer operação de gravação. Solicite a um administrador que siga o procedimento de reparo ou restauração fornecido pelo fornecedor para a versão do Zimbra instalada.
• Uma conta permanece afetada enquanto o mecanismo de banco de dados estiver íntegro: investigue separadamente os metadados da caixa de correio, o armazenamento de mensagens ou o índice dessa conta. Evite editar manualmente linhas SQL ou excluir arquivos para "reconstruir" a conta.

Em casos de suspeita de corrupção do InnoDB, a solução mais segura geralmente é uma recuperação específica da versão a partir de um backup verificado ou uma recuperação guiada pelo suporte, e não uma REPAIR TABLEreinicialização genérica do banco de dados ou uma sequência de comandos copiada. Alguns artigos antigos da wiki do Zimbra sobre recuperação incluem etapas destrutivas e foram explicitamente arquivados; não os aplique a um sistema atual sem a confirmação direta do Suporte do Zimbra e um backup testado.

Como você pode confirmar que o problema foi resolvido?

Após a ação corretiva aprovada, confirme se os serviços de banco de dados e caixa de correio permanecem ativos, se as novas entradas não apresentam mais o mesmo erro subjacente no banco de dados e se a conta afetada consegue executar operações normais de e-mail. Execute novamente o relatório de integridade padrão somente se apropriado para sua janela de carga e versão. Confirme se o trabalho de backup foi concluído e preserve os logs e o registro de reparo. Se o problema retornar, informe a versão/compilação exata do Zimbra, o layout de servidor único ou multi-servidor, o escopo da caixa de correio, o horário da primeira falha, trechos relevantes dos logs, o status do disco, a saída do relatório de integridade e o carimbo de data/hora do backup ao seu administrador ou ao canal de suporte do Zimbra.

Ponto-chave: diagnostique o erro de banco de dados por trás da exceção da caixa de correio antes de alterar os dados. A mensagem "Falha no banco de dados" por si só não informa se a correção envolve uma alteração de credenciais, uma alteração de capacidade, um reparo de armazenamento ou a recuperação do banco de dados.

Referências principais: Índice da documentação do Zimbra ; Arquitetura do servidor Zimbra ; Solução de problemas de logs do Zimbra ; Referência do relatório de integridade do banco de dados Zimbra ; Referência do erro 1040 do MySQL no Zimbra ; e Referência da solução de problemas de caixa de correio do Zimbra . Algumas páginas da Central de Tecnologia estão arquivadas ou marcadas como em desenvolvimento, conforme observado no artigo.