Questão de Banco de Dados — Arquitetura de Banco de Dados — FGV 2025
Banco de Dados›Arquitetura de Banco de Dados
Código
fg106569
Banca
FGV
Órgão
CGE-SP
Ano
2025
Nível
Superior
Cargo
Auditor Estadual de Controle - Tecnologia da Informação - tarde
Um órgão estadual de finanças migrou sua base de dados relacional crítica para um serviço gerenciado em nuvem (ex: AWS RDS ou Azure SQL Database) e configurou o recurso de Alta Disponibilidade (HA).O objetivo é garantir que, em caso de falha completa da Zona de Disponibilidade (AZ) onde a instância primária reside, o serviço possa ser restaurado rapidamente com perda mínima de dados.Assinale a opção que indica o principal mecanismo arquitetural usado por esses serviços gerenciados para Alta Disponibilidade, que minimiza o RPO (Recovery Point Objective) em um cenário Multi-AZ e garante a rápida transição (failover) sem a necessidade de intervenção manual.
AA utilização de Snapshots diários para reconstrução da instância em outra AZ.
BO uso de um Load Balancer, distribuindo a carga de escrita (writes) entre as réplicas em todas as AZs.
CA replicação dos dados para uma instância standby (secundária), localizada em uma AZ diferente, com o uso de replicação síncrona ou semi-síncrona para garantir RPO próximo a zero.
DA configuração de Read Replicas em diversas regiões geográficas com replicação assíncrona para o tráfego de leitura.
EA estratégia de Sharding (fragmentação) de dados entre diversas instâncias para escalabilidade de escrita.
Revelar gabarito e comentário▾
GabaritoC — A replicação dos dados para uma instância standby (secundária), localizada em uma AZ diferente, com o uso de replicação síncrona ou semi-síncrona para garantir RPO próximo a zero.
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 Multi-AZ em Banco de Dados Gerenciado (Cloud)
Gabarito: letra C. O principal mecanismo para garantir failover automático com RPO próximo de zero em cenário Multi-AZ é a replicação síncrona ou semi-síncrona para uma instância standby (secundária) em uma Zona de Disponibilidade (AZ) diferente. Essa configuração mantém os dados do standby sempre atualizados com o primário, permitindo failover imediato sem intervenção manual e perda mínima de dados.
A banca testa o conhecimento sobre a arquitetura de Alta Disponibilidade (HA) dos serviços gerenciados de banco de dados em nuvem (ex.: AWS RDS Multi-AZ, Azure SQL Database). O foco está no mecanismo que minimiza o RPO (Recovery Point Objective) – a quantidade máxima de dados que pode ser perdida em uma falha. A replicação síncrona garante que toda transação confirmada no primário também seja confirmada no standby antes de retornar sucesso ao cliente, resultando em RPO teoricamente zero.
Mecanismo
Descrição
RPO (Recovery Point Objective)
Failover Automático
Adequação para HA Multi-AZ
Snapshots diários
Backup pontual da instância
Alto (horas)
Não
❌ Incorreta
Load Balancer com réplicas
Distribuição de carga de escrita entre réplicas em múltiplas AZs
Alto (divergência de dados)
Não
❌ Incorreta
Replicação síncrona/semi-síncrona para standby em outra AZ
Dados replicados em tempo real para instância secundária
Próximo de zero
Sim
✅ Correta (Gabarito)
Read Replicas em múltiplas regiões
Réplicas de leitura assíncronas em regiões geográficas distintas
Alto (atraso de replicação)
Não
❌ Incorreta
Sharding entre instâncias
Fragmentação horizontal de dados para escalabilidade de escrita
Variável
Não
❌ Incorreta
Alternativa A — ❌ Incorreta
Snapshots diários são backups pontuais e não fornecem HA em tempo real. Em caso de falha completa de AZ, a reconstrução a partir de um snapshot levaria tempo e perderia todos os dados alterados desde o último snapshot, resultando em RPO alto (horas). Não atende ao requisito de "perda mínima de dados" e "rápida transição".
Alternativa B — ❌ Incorreta
Um Load Balancer distribui tráfego de leitura/escrita entre réplicas, mas não garante consistência forte nem failover automático. Réplicas assíncronas podem ter dados divergentes; escrever em múltiplas AZs com replicação assíncrona aumenta o risco de conflitos e não resolve o RPO. Além disso, a rápida transição sem intervenção manual não é um atributo direto de um Load Balancer.
Alternativa C — ✅ Correta ⟵ GABARITO
A replicação síncrona (ou semi-síncrona, conforme o serviço) para uma instância standby em outra AZ é o mecanismo padrão em serviços como AWS RDS Multi-AZ (usando replicação síncrona para o standby) e Azure SQL Database (geo-replication ou failover groups com replicação síncrona). As transações só são confirmadas após serem gravadas no primário e no standby, garantindo RPO próximo de zero. O failover é automático e transparente para a aplicação.
Alternativa D — ❌ Incorreta
Read Replicas em regiões geográficas com replicação assíncrona são utilizadas para descarregar tráfego de leitura, não para HA com alta disponibilidade de escrita. A replicação assíncrona pode resultar em RPO de segundos ou minutos (dados não replicados podem ser perdidos). Além disso, o failover de escrita para uma réplica em outra região não é automático e requer intervenção manual ou configuração complexa.
Alternativa E — ❌ Incorreta
Sharding (fragmentação) de dados em múltiplas instâncias é uma estratégia de escalabilidade horizontal, não de HA. Embora possa aumentar a resiliência em nível de partição, não elimina a necessidade de replicação para cada fragmento. Além disso, o sharding não trata diretamente do RPO nem do failover automático para uma instância standby.
NÃO CAIA NESSA!
A banca tenta confundir o candidato com termos que, embora relacionados à nuvem, não são o mecanismo principal de HA Multi-AZ. Muitos candidatos associam "Alta Disponibilidade" a backups (snapshots) ou a réplicas de leitura (Read Replicas). A chave é lembrar que o que minimiza o RPO em um failover automático é a replicação síncrona para um standby em outra AZ, e não qualquer outra forma de replicação assíncrona ou ferramenta auxiliar.