Questão de Banco de Dados — Recuperação de falhas — FGV 2025
Banco de Dados›Recuperação de falhas
Código
fg106575
Banca
FGV
Órgão
CGE-SP
Ano
2025
Nível
Superior
Cargo
Auditor Estadual de Controle - Tecnologia da Informação - tarde
Ao usar um serviço gerenciado de Banco de Dados Relacional em Nuvem (ex: AWS RDS ou Azure SQL Database), a arquitetura de Alta Disponibilidade (HA) é essencial para minimizar o downtime em caso de falha de infraestrutura.Em um SGBD em nuvem configurado para Alta Disponibilidade Multi-AZ/Multi-Region, assinale a opção que indica o mecanismo de replicação e failover que permite a transição rápida para uma réplica em caso de falha da instância primária.
AO Failover exige a recriação manual da instância e o restore de um snapshot.
BA replicação de log é feita via File Transfer Protocol (FTP) entre as regiões.
CA replicação é Assíncrona, mas o failover é instantâneo e sem perda de dados (RPO zero).
DApenas o serviço Google Cloud Spanner oferece HA, os demais usam replicação simples.
EÉ usado um modelo de replicação Síncrona entre a instância primária e a secundária em outra Zona de Disponibilidade, permitindo um failover automático e rápido (RTO baixo).
Revelar gabarito e comentário▾
GabaritoE — É usado um modelo de replicação Síncrona entre a instância primária e a secundária em outra Zona de Disponibilidade, permitindo um failover automático e rápido (RTO baixo).
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”.
Alta Disponibilidade (HA) em Bancos de Dados na Nuvem
Gabarito: letra E. A arquitetura Multi-AZ (como AWS RDS) utiliza replicação síncrona entre a instância primária e a secundária em Zonas de Disponibilidade distintas, garantindo que dados sejam confirmados em ambas antes do commit. Isso permite failover automático e rápido (baixo RTO) sem perda de dados (RPO zero). Alternativas equivocam-se ao propor mecanismos manuais, protocolos inadequados, replicação assíncrona com perda zero ou visão restritiva sobre provedores.
A questão testa o conhecimento do modelo de Alta Disponibilidade típico de serviços gerenciados de banco de dados relacional em nuvem (AWS RDS, Azure SQL Database). A chave está em entender que o failover automático exige replicação síncrona para garantir consistência e evitar perda de dados.
Característica
Alternativa A
Alternativa B
Alternativa C
Alternativa D
Alternativa E (Gabarito)
Mecanismo de replicação
Recriação manual + restore de snapshot
Replicação de log via FTP
Replicação assíncrona
Apenas Google Cloud Spanner oferece HA
Replicação síncrona entre primária e secundária
Tipo de failover
Manual
Não especificado
Instantâneo (alegado)
Não se aplica
Automático e rápido
Perda de dados (RPO)
Alto (depende do snapshot)
Alto (sem garantia de entrega)
Zero (alegado, mas inconsistente)
Não se aplica
Zero (RPO zero)
Tempo de inatividade (RTO)
Alto (horas)
Alto
Baixo (instantâneo, alegado)
Não se aplica
Baixo (RTO baixo)
Correção
❌ Incorreta
❌ Incorreta
❌ Incorreta
❌ Incorreta
✅ Correta
HA Multi-AZ (RDS/Azure SQL): Replicação (Síncrona (primária ↔ secundária), Mesma região, AZ diferente); Failover (Automático, RTO baixo (1-2 min), RPO zero (sem perda)); Não é (Manual (snapshot), Assíncrona (perde dados), FTP)
Alternativa A — ❌ Incorreta
Afirma que o failover exige recriação manual da instância e restore de snapshot. Isso descreveria um procedimento de recuperação de desastre (DR) com tempo de inatividade elevado, e não o mecanismo de HA automático. Em Multi-AZ, o failover é automático, sem intervenção manual.
Alternativa B — ❌ Incorreta
Menciona replicação de log via FTP entre regiões. FTP não é um protocolo adequado para replicação de banco de dados (baixa segurança, sem garantia de entrega). Serviços cloud usam canais criptografados e protocolos próprios (ex: TCP/IP com SSL). Além disso, a replicação entre regiões normalmente é assíncrona, mas o failover automático multi-AZ ocorre dentro da mesma região, entre AZs.
Alternativa C — ❌ Incorreta
Alega que a replicação é assíncrona, mas o failover é instantâneo e sem perda de dados (RPO zero). Replicação assíncrona implica que a réplica pode estar alguns passos atrás; se a primária falha, transações não confirmadas no secundário são perdidas (RPO > 0). Somente replicação síncrona pode garantir RPO zero. Além disso, failover “instantâneo” é um exagero; há um curto intervalo (tipicamente 1-2 minutos) para detecção e promoção.
Alternativa D — ❌ Incorreta
Afirma que apenas Google Cloud Spanner oferece HA, enquanto outros usam replicação simples. Isso é falso: AWS RDS Multi-AZ, Azure SQL Database (com geo-replicação) e outros possuem HA com failover automático. Spanner tem características próprias, mas não é exclusivo.
Alternativa E — ✅ Correta ⟵ GABARITO
Descreve corretamente: replicação síncrona entre instância primária e secundária em outra Zona de Disponibilidade, com failover automático e rápido (RTO baixo). Esse é o mecanismo padrão de HA em serviços como RDS Multi-AZ: cada transação é aplicada simultaneamente na primária e na réplica síncrona; se a primária falha, a réplica é promovida automaticamente com perda zero de dados (RPO=0) e downtime de cerca de 1-2 minutos.
NÃO CAIA NESSA!
A banca explora a confusão entre replicação síncrona e assíncrona. O candidato pode achar que “failover rápido” combina com replicação assíncrona, mas isso sacrificaria o RPO zero. Lembre-se: HA com RPO zero exige replicação síncrona.