Questão de Banco de Dados — Administração de banco de dados — FGV 2025
Banco de Dados›Administração de banco de dados
Código
fg104511
Banca
FGV
Órgão
AL-AM
Ano
2025
Nível
Superior
Cargo
Analista Legislativo - Analista de Redes de Comunicação de Dados
Um ambiente MySQL tem replicação master-multi-slave com 6 réplicas.O slave de relatórios apresenta lag de 5 horas durante processamento batch. Para resolver lag de replicação sustentavelmente, a abordagem mais eficaz é
Adesabilitar binary logging no master para reduzir overhead.
Bimplementar parallel replication ajustando slave_parallel_workers, otimizar queries pesadas no slave e considerar semi-sync para escritas críticas.
Cremover todos os índices das tabelas replicadas.
Dconfigurar replicação apenas para tabelas pequenas.
Eaumentar apenas innodb_buffer_pool_size.
Revelar gabarito e comentário▾
GabaritoB — implementar parallel replication ajustando slave_parallel_workers, otimizar queries pesadas no slave e considerar semi-sync para escritas críticas.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Replicação MySQL – Resolvendo Lag no Slave de Relatórios
Gabarito: letra B. A replicação master-multi-slave com lag sustentado no slave de relatórios exige uma abordagem combinada: paralelismo na aplicação dos eventos (parallel replication), otimização das consultas pesadas que causam o atraso e, para escritas críticas, semi-sync replication – que reduz a chance de perda de dados e ajuda no controle do fluxo. Essa é a solução mais completa e eficaz listada.
A questão testa a capacidade de diagnosticar e propor a solução correta para lag de replicação. O atraso costuma ser causado por consultas lentas no slave (especialmente em processamento batch) ou pela aplicação serial dos eventos do relay log. As alternativas incorretas propõem ações drásticas ou ineficazes.
1Parallel replication (slave_parallel_workers)
2Otimizar queries pesadas no slave
3Semi-sync replication (escritas críticas)
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Desabilitar o binary logging no master impediria que qualquer slave recebesse os dados – quebra a replicação por completo. O binary log é indispensável para o funcionamento do master em qualquer topologia com slaves.
Alternativa B — ✅ Correta ⟵ GABARITO
A combinação é a mais adequada:
Parallel replication (slave_parallel_workers): permite que o slave aplique transações em paralelo, reduzindo o acúmulo de eventos.
Otimizar queries pesadas no *slave: ataca a causa raiz (processamento *batch lento); índices apropriados, ajuste de consultas e particionamento podem diminuir drasticamente o tempo de execução.
Semi-sync replication: garante que uma das réplicas confirme cada transação antes de o master finalizá-la, protegendo dados críticos e, indiretamente, ajudando a monitorar o lag.
Alternativa C — ❌ Incorreta
Remover todos os índices das tabelas replicadas tornaria as consultas no slave extremamente lentas, agravando o lag em vez de resolvê-lo. Índices são fundamentais para performance de leitura.
Alternativa D — ❌ Incorreta
Restringir a replicação apenas a tabelas pequenas é inviável para um slave de relatórios que precisa de dados completos - e não resolve o lag das tabelas grandes que continuariam ausentes.
Alternativa E — ❌ Incorreta
Aumentar innodb_buffer_pool_size pode ajudar a performance geral, mas não ataca diretamente a causa do lag (consultas lentas e aplicação serial). É uma medida paliativa e insuficiente isoladamente.
PEGA ESSA DICA!
Ao enfrentar questões de lag de replicação, pense em três frentes: (1) paralelismo na aplicação, (2) otimização das consultas que rodam no slave e (3) configurações de rede e binlog (como semi-sync). Alternativas que quebram a replicação ou pioram a performance são sempre erradas.