Perda de dados do MySql - análise post mortem - RackSpace Cloud Server

Question

Após uma recente 'migração de emergência' de um servidor de nuvem RS, os bancos de dados mysql em nossa imagem de instantâneo do servidor mostraram-se desatualizados a partir da data de backup. E, no entanto, os arquivos que foram enviados por upload pelo aplicativo da Web afetado foram gravados no sistema de arquivos. Metadados relacionados que foram gravados no banco de dados foram perdidos, mas os próprios arquivos foram submetidos a backup.

Uma vez consegui acessar manualmente os arquivos de dados mysql antes do servidor mysql iniciar (o servidor foi configurado para iniciar o mysql na inicialização), pude ver que o tempo de atualização para ib_logfile1, ib_logfile0 e ibdata1 era de alguns dias. / p>

Assim como este pôster, perda de dados do mysql após o travamento do servidor , é como se algum controlador de armazenamento em cache tivesse dito ao servidor OS / mysql que tinha dados confirmados que ainda estavam no cache, e foi perdido em vez de liberado.

Eu não consigo entender como os arquivos enviados foram escritos, mas os dados do banco de dados não. Eu teria pensado que qualquer cache teria liberado todo o sistema, em vez de processo por processo.

Alguma sugestão de como isso pode ter acontecido?

UPDATE TWO:

Veja minha resposta abaixo que explica o que aconteceu.

ATUALIZAÇÃO:

Detalhes da configuração, conforme solicitado.

RackSpace Cloud Server Details:
OS: Ubuntu 10.04 LTS (Lucid)
RAM: 1024 MB
Disk Space: 40 GB
Datacenter: ORD1
Service Level: unmanaged

root@restore-testing:~# dpkg -s mysql-server
...
Architecture: all
Source: mysql-dfsg-5.1
Version: 5.1.61-0ubuntu0.10.04.1
...

root@restore-testing:~# cat /etc/fstab
proc            /proc       proc    defaults    0 0
/dev/xvda1       /           ext3    defaults,errors=remount-ro,noatime    0 1
/dev/xvdc1       none        swap    sw          0 0

    

Answer 1

Embora algumas configurações de innodb_flush_method combinadas com determinado hardware possam resultar em perda de dados com uma falha de hardware, nenhuma combinação de innodb_flush_method e innodb_flush_log_at_trx_commit explica como o ib_logfile1 & ib_logfile2 pode ser dias obsoletos.

Eu migrei os servidores por volta do registro de data e hora dos arquivos do banco de dados. Eu trouxe o mysql para baixo lentamente em ambos os servidores e rsync / var / lib / mysql de um para o outro. Os webapps surgiram e fizeram check-out no novo servidor.

Mas, e se eu esqueci de monit unmonitor mysql no servidor alvo e ele reiniciou o mysql? Talvez eu tivesse substituído os dados e arquivos de log em um servidor mysql em execução? O mysql continuaria a liberar dados para inodes obsoletos?

Um teste rápido depois, e a resposta é sim. O MySql não percebe que está gravando em identificadores de arquivos inválidos quando seus dados e arquivos de log foram substituídos, mas o buffer pool na memória é capaz de satisfazer todas as consultas. Dado o tamanho do nosso banco de dados (pequeno) e volume de consulta (baixo), o pool de buffer provavelmente teria continuado a lidar com nossos pedidos por algum tempo.

    

Answer 2

Eu posso ver isso acontecendo dependendo do método que Innodb libera dados.

Por favor, procure em innodb_flush_method usado pela sua instalação do MySQL. Dependendo do valor definido (O_DSYNC ou O_DIRECT), o InnoDB poderia tanto buffer duplo para o sistema operacional quanto para o buffer pool do InnoDB ou apenas o buffer pool do InnoDB. Se a variável estiver configurada para armazenar em cache apenas no conjunto de buffers, eu posso ver rapidamente os dados desaparecendo se a restauração do SO tiver massacrado o conjunto de buffers no processo. Eu escrevi uma postagem no DBA StackExchange sobre isso .

Aqui está outro link sobre o uso do MySQL na nuvem versus bare-metal ( Clique aqui ). Ele nomeia três possíveis problemas / desafios que acompanham o movimento do MySQL em um ambiente de nuvem:

• IPs virtuais
• Configuração de memória
• discos lentos

Mesmo que essas limitações tenham sido superadas desde esse artigo, é prudente repensar onde os dados de missão crítica residirão. Isso é especialmente verdadeiro, considerando o que aconteceu com seus dados.

BTW O StackOverflow tem um bom post sobre os prós e contras do MySQL na nuvem .

Para aprofundar esse ponto a partir de outro aspecto, o Cloud Environments fornece replicação geográfica de uma instância do mysql de East Coast para West Coast. Quando eu pessoalmente fiz uma avaliação de 30 dias do Serviço de Banco de Dados XEROUND (recebi dois IPs Públicos), vi uma intermitência muito ruim (cerca de 5-6 minutos) entre os IPs. Você poderia imaginar a perda de dados durante essa janela devido a um travamento em ambas as extremidades? Sua perda de dados foi devido a uma intervenção manual de emergência.

RECOMENDAÇÃO

IMHO gostaria de mudar seus bancos de dados MySQL para bare-metal e usar DRBD ou MySQL Replication para redundância de dados. Você pode manter todos os serviços na nuvem para servidores da Web e de aplicativos.