Questão de Banco de Dados — Banco de Dados Distribuídos — CESPE / CEBRASPE 2025
Banco de Dados›Banco de Dados Distribuídos
Código
ce417236
Banca
CESPE / CEBRASPE
Órgão
PC DF
Ano
2025
Cargo
GAAPC ( )
Acerca de linguagens de consulta e de banco de dados distribuídos, julgue o item a seguir. Em um banco de dados distribuído, a replicação de dados garante que todas as réplicas permaneçam sincronizadas automaticamente, eliminando a necessidade de mecanismos adicionais de controle de consistência.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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 em Banco de Dados Distribuídos
Gabarito: Errado. A replicação de dados em um banco de dados distribuído não elimina, por si só, a necessidade de mecanismos adicionais de controle de consistência. Pelo contrário, a replicação introduz o desafio de manter as réplicas sincronizadas, o que exige protocolos de controle de concorrência e de consistência, como os baseados em transações ACID ou em modelos de consistência eventual (BASE).
A replicação é uma técnica fundamental em bancos de dados distribuídos, que consiste em manter cópias dos dados em diferentes nós do sistema. O objetivo principal é aumentar a disponibilidade, a confiabilidade e o desempenho das operações de leitura. No entanto, a replicação cria um problema clássico: como garantir que todas as cópias reflitam as mesmas atualizações, especialmente quando há escritas concorrentes em diferentes nós? A resposta é que isso não acontece automaticamente. É necessário implementar mecanismos de controle de consistência, como protocolos de commit atômico (ex.: two-phase commit), controle de concorrência distribuído (ex.: bloqueios distribuídos, timestamps) e políticas de replicação (síncrona ou assíncrona).
A replicação síncrona, por exemplo, tenta garantir que todas as réplicas sejam atualizadas na mesma transação, mas isso não elimina a possibilidade de inconsistência em cenários de falha de rede ou de nó. Já a replicação assíncrona, comum em sistemas NoSQL, aceita um atraso na propagação das atualizações, o que pode levar a leituras de dados desatualizados (consistência eventual). Portanto, a afirmação de que a replicação "elimina a necessidade de mecanismos adicionais de controle de consistência" é incorreta. Na verdade, a replicação exige esses mecanismos para funcionar corretamente.
A banca explora aqui uma confusão comum: o candidato pode pensar que, por haver cópias, o sistema se auto-ajusta. Mas a replicação é apenas a cópia dos dados; a sincronização e a consistência são problemas que precisam ser resolvidos por outros componentes do SGBD distribuído. A replicação, inclusive, é uma das principais fontes de complexidade em sistemas distribuídos, pois é preciso decidir como propagar as atualizações, como resolver conflitos e como garantir que todos os nós cheguem a um estado consistente.
NÃO CAIA NESSA!
A banca tenta fazer o candidato acreditar que a replicação é uma solução mágica que resolve a consistência automaticamente. Na prática, a replicação é o problema que cria a necessidade de mecanismos de consistência. Lembre-se: replicação = cópia; consistência = controle. São coisas distintas.
A afirmação está incorreta porque a replicação de dados não garante a sincronização automática das réplicas. Pelo contrário, a replicação introduz a necessidade de mecanismos adicionais de controle de consistência, como protocolos de commit atômico, controle de concorrência e políticas de replicação. A replicação síncrona pode reduzir a janela de inconsistência, mas não a elimina completamente, especialmente em cenários de falha. A replicação assíncrona, por sua vez, aceita a consistência eventual, o que significa que as réplicas podem ficar temporariamente desatualizadas. Portanto, a replicação não elimina a necessidade de controle de consistência; ela a cria.