Os backups de banco de dados MySQL do Zenoss são enormes após a atualização multiversão

Question

O contexto:

Nós rodamos o Zenoss 2.2 por muito tempo, e decidimos que era hora de atualizar para a versão atual, 3.2. Segui as etapas de atualização aqui e verifiquei se tudo estava funcionando após cada teste incremental atualização de versão. Certifiquei-me de reiniciar quando não tinha certeza e verifiquei que todas as migrações de banco de dados (e o ZenPack de pré-atualização) foram aplicadas corretamente. Tudo funcionou, com a exceção de alguns ZenPacks desatualizados que não estávamos usando muito de qualquer maneira. Nós rodamos o CentOS 5, então eu usei as versões antigas do rpm disponíveis no sourceforge para as atualizações intermediárias, e então fiz o último "salto" para o 3.2 usando o yum. Por alguma razão, o yum não instalou os zenpacks centrais para o 3.2, então eu fiz isso manualmente, e então tudo estava bem: o zenoss funcionava muito bem, sem problemas. Bem ... exceto um.

O problema:

Nós agendamos backups usando o cron / mysqldump do banco de dados de eventos do Zenoss. Esses backups saem diariamente e geralmente ocupam cerca de 7-800 MB de espaço. Após a atualização do Zenoss, esses backups estão ocupando mais de 200 GB (com um 'G'!) De espaço, embora eu ainda não tenha visto um final. Para executar o backup, estamos usando

mysqldump -A | gzip > dump-12-28-2011.sql.gz 

Nós temos o MySQL 5, então --extended-insert é um parâmetro padrão para o mysqldump. O Zenoss é a única coisa que usa o banco de dados (e o banco de dados de "eventos" é o único presente além do do mysql), e eu desliguei o Zenoss pela duração do despejo. Meu arquivo ibdata1 (só temos 1) tem cerca de 13 GB agora. Eu não sei o quão grande foi antes da atualização. Eu tentei esta solução para excluir entradas de detalhes de eventos antigos. A consulta foi executada para sempre, mas depois os dumps aumentaram de tamanho da mesma forma que antes. Por que isso está acontecendo? Eu tenho backups de antes da atualização, devo reverter?

TL; DR:

Por que meus bancos de dados "eventos" do Zenoss descarregam 1000X maiores após uma atualização multiversão?

    

Answer 1

Após alguns dias de escavação, descobri o problema: corrupção do InnoDB. O banco de dados de eventos de fora realmente era bem grande (estávamos retendo o equivalente a um ano de eventos antigos, e tínhamos uma tonelada de computadores com janelas relatando pequenas coisas, então tínhamos muitos dados), mas esse não era o problema. Eu comecei a correr $ZENHOME\Products\ZenUtils\ZenDeleteEvents.py -n 60 para cortar o histórico de eventos de volta para 60 dias, e o MySQL caiu depois que ficou na metade do caminho. Eu olhei nos logs do MySQL, e havia uma tonelada de erros de corrupção do InnoDB. Esta foi a solução final:

1. Pare o Zenoss
2. Pare o MySQL
3. Coloque o MySQL no modo de recuperação 2 do InnoDB
4. Inicie o MySQL
5. Descarregar o banco de dados de eventos via mysqldump -uzenoss -pzenoss events > dump.sql Por algum motivo, após a remoção via ZenDeleteEvents.py, o despejo funcionou, e não cresceu de forma incontrolável.
6. Pare o MySQL
7. Retire as definições do esquema de arquivos de log / eventos do ibdata / innodb / var / lib / mysql, e colocá-los em algum lugar para guarda (no caso de etapas subsequentes não funcionaram)
8. Retire o MySQL do modo de recuperação
9. Inicie o MySQL
10. Como usuário do zenoss, execute zeneventbuild localhost zenoss zenoss events (esses parâmetros podem ser diferentes para outros: a sintaxe  é zeneventbuild <dbhost> <dbuser> <dbpassword> <dbname>
11. Como root, execute mysql e, em seguida, grant super on *.* to 'zenoss'@'localhost' identified by 'zenoss';
12. Reinicie o MySQL
13. Restaurar o despejo do banco de dados de eventos, via mysql -uzenoss -pzenoss events < dump.sql
14. Reinicie o MySQL novamente (provavelmente desnecessário, mas estou paranóico)
15. Iniciar o Zenoss

Depois disso, tudo funcionou bem, embora eu não tivesse muitos eventos históricos (que eu não estava usando de qualquer maneira). Este tópico nos fóruns do zenoss foi fundamental para me ajudar a descobrir o que estava acontecendo.