Estou tentando mover nosso ambiente de desenvolvimento para um vagrant box (máquina virtual usando o Oracle virtualbox). Atualmente estou preso em um problema:
O ambiente precisa de um servidor MySQL e alguns bancos de dados. Eu tenho todos os scripts configurados que instalam o MySQL, criam e preenchem os bancos de dados, etc. Isso funciona.
Como os desenvolvedores provavelmente configurarão mais dados por conta própria, minha ideia foi colocar a pasta de dados do MySQL em uma pasta de caixa virtual compartilhada. Dessa forma, quando a máquina vagrant é destruída/recriada, a pasta de dados permanece e pode ser reutilizada sem perda de dados.
No entanto, às vezes (mas nem sempre, não sei o que o aciona) quando eu simplesmente suspendo e retomo a máquina virtual, o MySQL começa a reclamar que muitas de suas tabelas (mas não todas) estão corrompidas. A correção das tabelas resulta na perda de todos os dados nelas contidos. Obviamente isso é inaceitável.
Alguém tem alguma idéia de por que isso acontece e como evitá-lo?
Algumas pistas possíveis ou pistas falsas - desde que li que as pastas compartilhadas do virtualbox são lentas, aumentei o tamanho do pool de buffer do InnoDB para 1 GB, para que ele tenha muito espaço em cache. Nós usamos InnoDB e MyISAM em proporções de cerca de 50/50. Ainda não verifiquei se todas as tabelas com falha pertencem ao mesmo mecanismo - prestarei atenção a ele quando ele travar novamente.
Atualizar
Ha, eu consegui pegá-lo em flagrante! É realmente... suspense... TANTO InnoDB quanto MyISAM.
Selecionando de uma tabela MyISAM dá o erro
A tabela 'xxx' está marcada como travada e deve ser reparada
Tentando executar mysqlcheck -A -a(analisar todas as tabelas) na verdade TRAVA o MySQL. Os arquivos de log contam a história (editados para maior clareza):
[Warning] InnoDB: Retry attempts for writing partial data failed.
[ERROR] InnoDB: Write to file ./ib_logfile0failed at offset 29885952, 1024 bytes should have been written, only 0 were written. Operating system error number 71. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
[ERROR] InnoDB: Error number 71 means 'Protocol error'
[ERROR] mysqld got signal 6
Query (0x7fbc12501b50): ANALYZE TABLE `yyy`
E então, em um momento, systemctl reinicia o serviço e tudo funciona perfeitamente novamente.
Meu palpite é que a suspensão da máquina virtual libera os bloqueios que o virtualbox estava segurando nos arquivos abertos e, quando o virtualbox é iniciado novamente, ele não os adquire novamente. Então, do ponto de vista do MySQL, ele mantém um arquivo aberto, mas o virtualbox perdeu esse controle, então quando o MySQL tenta acessar o arquivo novamente, ele recebe um erro.
Quando a caixa de produção trava, e você descobre que as tabelas MyISAM estão corrompidas lá , e você descobre quantas horas (ou dias) leva para
REPAIRelas, você pode repensar se a mudança para o InnoDB é justificada.Em algum momento, sua 'suspensão' + corrupção pode tornar as tabelas MyISAM tão confusas que o desenvolvimento é afetado.
OK, palestra terminada; de volta às suas perguntas.
Qual o tamanho da VM? Se você for 50/50 InnoDB/MyISAM nessa caixa, use essas configurações se a VM tiver pelo menos 4 GB:
Se menos de 4 GB, diminua um pouco essas porcentagens. O objetivo é evitar sempre a troca.
Talvez você possa estabilizar seu sistema colocando os arquivos de banco de dados em um disco rígido virtual dedicado. Etapas: configure um VHD de bom tamanho, dê a ele um ponto de montagem, formate-o, adicione seu ponto de montagem a /etc/fstab, copie todos os arquivos de banco de dados para o novo VHD. Em seguida, edite os arquivos de configuração (do servidor de banco de dados) para que eles apontem para os arquivos no novo disco rígido virtual.
Sim, podemos definir permissões etc. para proteger os arquivos em uma pasta compartilhada, mas um disco rígido virtual pode ser um "contêiner" melhor para o banco de dados, talvez mais adequado às suas necessidades. M Hashimoto executou alguns testes, comparando o desempenho de pastas compartilhadas/ambientes virtuais/NFS (veja o relatório: http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines ). Não que você estivesse reclamando do desempenho como tal, mas as pastas compartilhadas com o VirtualBox parecem ter algumas "dificuldades" (ou: parecem tê-las no passado).
Se você realmente precisar "suspender" a VM, há algumas dicas aqui ( https://askubuntu.com/questions/63524/whats-the-best-way-to-pause-my-work-in-virtualbox-with -ubuntu-como-convidado ). Posso imaginar que isso funcione melhor quando todos os arquivos (associados ao servidor db) estão localizados em discos rígidos virtuais conectados à VM.
Você também pode desanexar (e manter) o disco virtual que contém os arquivos de banco de dados, criar uma nova VM e anexar o disco a uma nova VM, se necessário.