Case:
Tuning em banco de dados MySQL para uma das maiores empresas brasileira na gestão e operação de estacionamentos

Setor: Logística

Tecnologias:

Sobre o cliente

O cliente é uma das maiores empresas do Brasil na gestão e operação de estacionamentos, presente na maior parte do território brasileiro com mais de 90.000 vagas administradas. Atua em shopping centers, edifícios comerciais, hospitais, concessões públicas, aeroportos e universidades. Recentemente fez a aquisição de empresa que realiza a gestão inteligente para estacionamentos públicos rotativos – popularmente conhecidos como Zona Azul – em 9 cidades brasileiras.

  • Sobre o projeto
  • Desafios na implantação
  • Solução implementada
  • Benefícios e resultados

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).

  • 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.

  • 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.
small_c_popup.png

Quer receber todos os cases da 4Linux em formato de e-book?

Ele pode servir de inspiração ou rumo para o seu próximo projeto utilizando software open source.

Ao clicar em enviar você estará de acordo com nossa Política de Privacidade e Termos LGPD.