Analista Administrativo - Tecnologia da Informação, com especialidade em Banco de Dados
Um sistema de banco de dados baseado em PostgreSQL possui três servidores, sendo um primário e dois em espera (standby). O servidor primário executa comandos de escrita e leitura (readonly), enquanto os servidores em standby resolvem apenas requisições de leitura. A replicação é realizada utilizando-se write-ahead log (WAL).A cada atualização do banco de dados do servidor primário, um WAL é encaminhado diretamente para os dois servidores em standby. O processo de replicação se encerra após o recebimento de respostas de todos os servidores em standby.Com relação ao sistema de banco de dados em questão, é correto afirmar que
Apossui balanceamento de carga, os servidores estão conectados na configuração multiespera (multi-standby) e a replicação do banco de dados é síncrona.
Bpossui balanceamento de carga, os servidores estão conectados na configuração multiespera (multi-standby) e a replicação do banco de dados é assíncrona.
Cnão possui balanceamento de carga, os servidores estão conectados na configuração cascata e a replicação do banco de dados é assíncrona.
Dnão possui balanceamento de carga, os servidores estão conectados na configuração multiespera (multi-standby) e a replicação do banco de dados é síncrona.
Epossui balanceamento de carga, os servidores estão conectados na configuração cascata e a replicação do banco de dados é síncrona.
Revelar gabarito e comentário▾
GabaritoA — possui balanceamento de carga, os servidores estão conectados na configuração multiespera (multi-standby) e a replicação do banco de dados é síncrona.
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 Síncrona e Assíncrona no PostgreSQL
Gabarito: letra A. O sistema descrito possui balanceamento de carga de leitura (já que os servidores em espera atendem requisições de leitura), configuração multi-standby (dois servidores conectados diretamente ao primário) e replicação síncrona, pois o primário só finaliza a transação após receber a confirmação de todos os standbys. A alternativa A é a única que combina corretamente esses três elementos.
A banca testa o conceito de replicação síncrona versus assíncrona e as topologias de standby: multi-standby (vários servidores ligados ao primário) versus cascata (um standby conecta-se a outro standby). A descrição do enunciado é clara: "o processo de replicação se encerra após o recebimento de respostas de todos os servidores em espera" — isso define a replicação síncrona. Além disso, os standbys recebem o WAL diretamente do primário, caracterizando multi-standby, e como eles resolvem requisições de leitura, há balanceamento de carga.
Característica
Balanceamento de Carga
Configuração
Replicação
Sistema descrito
Possui (leituras nos standbys)
Multi-standby (envio direto do primário)
Síncrona (aguarda confirmação de todos)
Alternativa A
Possui
Multi-standby
Síncrona
Alternativa B
Possui
Multi-standby
Assíncrona
Alternativa C
Não possui
Cascata
Assíncrona
Alternativa D
Não possui
Multi-standby
Síncrona
Alternativa E
Possui
Cascata
Síncrona
Replicação PostgreSQL
1Síncrona
Primário aguarda confirmação
Latência maior
2Assíncrona
Primário não aguarda
Menor latência
3Topologia
Multi-standby
Standbys conectados ao primário
Cascata
Standby conecta a outro standby
4Balanceamento de carga
Leituras distribuídas nos standbys
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
Os três atributos estão de acordo com a descrição: balanceamento de carga (leituras distribuídas entre os standbys), configuração multi-standby (dois standbys conectados diretamente ao primário) e replicação síncrona (primário aguarda acuse de todos os standbys).
Alternativa B — ❌ Incorreta
Troca a replicação síncrona por assíncrona. No modelo assíncrono, o primário não aguarda a confirmação dos standbys para concluir a transação, o que contraria o enunciado.
Alternativa C — ❌ Incorreta
Afirma que não há balanceamento de carga, que a configuração é cascata e a replicação é assíncrona. Todos os três elementos estão errados: há balanceamento de carga (leituras nos standbys), a topologia é multi-standby (envio direto do primário para ambos) e a replicação é síncrona.
Alternativa D — ❌ Incorreta
Erra ao dizer que não há balanceamento de carga. Como os standbys atendem requisições de leitura, há distribuição da carga de leitura, caracterizando balanceamento.
Alternativa E — ❌ Incorreta
Confunde a topologia ao afirmar que os servidores estão em cascata. Em cascata, um standby recebe dados de outro standby, não diretamente do primário, o que não é o caso descrito.
NÃO CAIA NESSA!
A banca tenta confundir o candidato com trocas clássicas: (1) síncrona ↔ assíncrona — a chave está em "o processo se encerra após o recebimento de respostas de todos"; (2) multi-standby ↔ cascata — no enunciado o WAL é enviado "diretamente para os dois servidores em espera", o que exclui cascata; (3) presença de balanceamento de carga — como os standbys fazem leitura, há sim balanceamento, mesmo que o primário também leia.
PEGA ESSA DICA!
Memorize a diferença prática entre replicação síncrona e assíncrona no PostgreSQL:
Síncrona: primário aguarda confirmação de pelo menos um standby (ou todos, conforme configurado) antes de confirmar a transação. Garante zero perda de dados, mas aumenta a latência.
Assíncrona: primário não espera confirmação; o standby pode ficar atrasado. Menor latência, mas risco de perda de dados em falha.
Quanto à topologia: multi-standby = vários standbys ligados ao primário; cascata = um standby ligado a outro standby (economia de conexões, mas maior latência).