O cliente enfrentava sérios problemas de performance com o banco de dados MySQL; o ambiente apresentava instabilidade em alguns momentos do dia, travando o funcionamento da aplicação e fazendo com que – por exemplo – consultas simples ao banco de dados que demoravam 52ms, começassem a retornar em 30s. Além deste problema de instabilidade, suas rotinas de backup eram baseadas apenas em dumps, levando horas para restaurar e – além disso – o servidor de réplica estava desativado pois apresentava conflitos de duplicidade de chaves. Além destes problemas o cliente gostaria de implementar uma forma de backup mais direta utilizando – se necessário – o conceito de PITR (Point-in-time recovery).
Sobre o projeto
Desafios na implementação
- O banco de dados não poderia parar e no máximo poderia ser reiniciado durante as madrugadas.
- O hardware deveria ser o mesmo, evitando custos adicionais com novas aquisições, isso significava que os problemas apresentados deveriam ser resolvidos apenas com configurações no MySQL e não com a aquisição de hardware mais potentes.
- A réplica deveria estar pronta para uso caso o servidor principal apresentasse algum problema.
- A restauração dos dumps levavam horas e por isso não poderia haver erros pois caso isso acontecesse a janela da madrugada seria perdida e teríamos que esperar pela próxima janela.
Solução implementada
A atualização do banco (V5.6) não foi possível pois algumas aplicações utilizavam uma versão do driver que não era compatível com versões mais novas. Atualizar o banco seria uma boa solução pois as novas versões apresentam uma melhor performance para o comportamento concorrente da base de dados e também porque seria possível extrair métricas mais avançadas. Não sendo possível, o foco de atuação virou-se completamente para configurações e análise de queries que poderiam estar causando problemas no servidor. As configurações foram simplificadas e apenas as importantes e relevantes foram modificadas.
Como outras alternativas de backup configuramos rotinas do Percona XtraBackup para realizar “hot backups” completos e incrementais, além de ativamos o log binário para a replicação, configurando uma janela de uma semana para PITR.
Benefícios e resultados
- Nenhuma aplicação precisou ser alterada. O servidor do banco de dados continuou com as mesmas configurações físicas e a máquina passou a não apresentar a lentidão de antes, economizando recursos em relação a um “scaling” vertical.
- As rotinas de backup garantiram um grande ganho operacional ao cliente pois agora as rotinas levam muito menos tempo para finalizarem e podem ser restaurados em minutos, ao invés de horas.
- O servidor de réplica passou a operar normalmente sem os problemas de duplicidade de chaves e está pronto para assumir caso ocorra algum problema com o servidor principal.
