Questão de Banco de Dados — PostgreSQL — Quadrix 2026
Banco de Dados›PostgreSQL
Código
qa432965
Banca
Quadrix
Órgão
CRF PR
Ano
2026
Cargo
Ana ( )
O Conselho Regional de Farmácia do Estado do Paraná (CRF‑PR) mantém um sistema corporativo que armazena dados cadastrais de profissionais, registros de empresas farmacêuticas, processos administrativos, multas e informações financeiras. O ambiente utilizou PostgreSQL em servidores Linux, com exigência de alta disponibilidade, controle de acesso com base em papéis, auditoria de operações sensíveis, rotinas de backup automatizadas e otimização de desempenho para relatórios estatísticos enviados ao Conselho Federal. A equipe de TI precisou garantir a continuidade dos serviços, conformidade com normas de proteção de dados e integridade das informações institucionais.
Com base nessa situação hipotética, julgue o item a seguir.
A execução do comando pg_ctl promote no servidor principal do CRF realiza a promoção automática da réplica em modo streaming para nó primário, mantendo a sincronização bidirecional entre os dois servidores.
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 no PostgreSQL: pg_ctl promote e o mito da sincronização bidirecional
Gabarito: ERRADO (letra E). O comando pg_ctl promote é executado no servidor réplica (standby), não no primário, e promove essa réplica a um novo nó primário — mas a replicação em modo streaming é unidirecional (do primário para a réplica), jamais bidirecional. A afirmação erra em dois pontos: quem executa o comando e o sentido da sincronização.
A replicação em streaming no PostgreSQL é um mecanismo de alta disponibilidade em que um servidor primário (master) envia continuamente os registros do WAL (Write-Ahead Log) para uma ou mais réplicas (standby). Essas réplicas aplicam esses registros, mantendo uma cópia atualizada dos dados. O fluxo é sempre do primário para a réplica — a réplica não envia dados de volta ao primário. Isso é uma replicação assíncrona (por padrão) ou síncrona (se configurada), mas em ambos os casos o sentido é único.
O comando pg_ctl promote é utilizado para transformar uma réplica em um novo primário. Ele é executado na réplica, não no servidor primário. Quando executado, a réplica para de aplicar o WAL recebido e passa a aceitar conexões de escrita, tornando-se o novo nó primário. Esse processo é conhecido como failover — uma operação de recuperação de desastres, não uma operação de manutenção da sincronização.
A confusão que a banca explora é dupla: primeiro, inverte o sujeito do comando (diz que é executado no primário, quando é na réplica); segundo, inventa uma "sincronização bidirecional" que não existe na replicação em streaming padrão do PostgreSQL. Para haver sincronização bidirecional, seria necessário configurar uma replicação lógica bidirecional (BDR) ou outra solução de replicação multi-mestre, que não é o caso da replicação em streaming tradicional.
Na prática, o fluxo de um failover típico é: (1) o primário falha; (2) a réplica é promovida com pg_ctl promote; (3) a réplica vira o novo primário; (4) se houver outras réplicas, elas passam a seguir o novo primário. Não há retorno de dados do novo primário para o antigo — o antigo, se recuperado, pode voltar como réplica do novo.
NÃO CAIA NESSA!
A banca inverte o sujeito do comando e inventa uma sincronização bidirecional. O candidato que sabe que pg_ctl promote promove uma réplica pode marcar "certo" sem perceber que o comando é executado na réplica, não no primário. E a "sincronização bidirecional" é um termo que não existe na replicação em streaming — ela é sempre unidirecional. Fique atento a esses dois detalhes: quem executa o comando e o sentido do fluxo de dados.
1Primário falha
2Réplica promovida (pg_ctl promote)
3Réplica vira novo primário
4Demais réplicas seguem o novo primário
LEVEL · soulevel.com.br
Item — ❌ ERRADO
A afirmação contém dois erros técnicos graves:
pg_ctl promote é executado na réplica, não no primário. O comando serve para promover uma réplica standby a nó primário, tipicamente em um cenário de failover após a falha do primário original. Executá-lo no primário não faz sentido — o primário já é primário.
A replicação em streaming é unidirecional, não bidirecional. O fluxo de dados é sempre do primário para a réplica, via WAL. A réplica não envia dados de volta ao primário. A "sincronização bidirecional" exigiria uma solução de replicação multi-mestre (como BDR), que não é o caso da replicação em streaming padrão.
Portanto, a afirmação está errada em ambos os pontos.