Airbnb Inova ao Reproduzir Cargas de Trabalho de Banco de Dados para Testes e Otimização

A estratégia do Airbnb para testar bancos de dados é um case interessante para engenheiros de plataforma e DevOps. Em vez de se basear em benchmarks sintéticos, a empresa optou por capturar o tráfego SQL real da produção, usando o ProxySQL como ponto de interceptação. Essa escolha é estratégica: o ProxySQL já atua como um proxy de banco de dados, entende o protocolo MySQL e, o mais importante, não exige alterações nas aplicações. Isso resolve o problema de capturas fragmentadas e dependentes de linguagem que o Airbnb tinha antes, conforme detalhado no artigo.

O sistema funciona em três fases: um Log Mover coleta logs do ProxySQL para armazenamento em nuvem, um Log Processor decodifica, agrupa e reordena as transações por cluster e pod de ProxySQL, e um Log Replayer executa esses logs contra os bancos de dados de teste. Um ponto crucial é como o Log Processor manipula IDs auto-incrementais: ele reescreve instruções INSERT para incluir explicitamente o last_insert_id original. Isso garante a consistência em testes de compatibilidade, evitando falsos positivos que poderiam surgir de diferentes comportamentos de auto-incremento entre versões de MySQL ou bancos compatíveis. Essa abordagem se diferencia de métodos como o apresentado para PostgreSQL 18, que no artigo do CEVIU de 10 de março de 2026, foca em exportar apenas estatísticas do otimizador para testes, sem a reprodução exata da carga de trabalho transacional.

Para equipes de DevOps, a solução do Airbnb é um divisor de águas na gestão de infraestrutura de dados em escala. A capacidade de reproduzir com precisão o timing e a sequência das transações de produção em ambientes de teste permite um planejamento de capacidade muito mais acurado. É possível simular picos de tráfego, como temporadas de alta demanda, e identificar gargalos antes que afetem usuários reais, otimizando o uso de recursos e, consequentemente, custos.

Além disso, a detecção proativa de regressões de desempenho e problemas de compatibilidade, como os encontrados na transição do MySQL 5.7 para o 8.0 (com a remoção do cache de query e mudanças na ordenação de linhas), minimiza riscos em upgrades de banco de dados. Isso garante que a confiabilidade do sistema não seja comprometida, economizando tempo valioso da equipe de engenharia e evitando incidentes em produção. É a diferença entre testar o que se imagina e testar o que realmente acontece.