Acerca das tecnologias que atendem a PDPJ-Br, julgue o próxi...

Vamos analisar a questão sobre a replicação por fluxo do banco de dados PostgreSQL, que é um tema relevante para concursos públicos na área de Noções de Informática. A alternativa correta é E - errado.

No PostgreSQL, a replicação por fluxo (streaming replication) é um método de replicação assíncrona. Isso significa que as alterações feitas no servidor primário (principal) não são aplicadas simultaneamente no servidor em espera (replica ou standby). Em vez disso, as mudanças são enviadas do primário para a réplica, onde são aplicadas de forma assíncrona.

Vamos entender isso com mais detalhes:

Replicação Assíncrona: Na replicação por fluxo, o servidor primário envia as alterações feitas no banco de dados para o servidor em espera em tempo real, mas essas alterações são aplicadas na réplica com um pequeno atraso. Isso ocorre porque o servidor primário continua seu funcionamento normal sem esperar que o servidor de réplica confirme a aplicação das alterações. Portanto, não há simultaneidade nas mudanças entre os servidores.

A alternativa mencionada na questão afirma que as alterações são simultâneas nos dois servidores, o que está incorreto. Na prática, pode haver um pequeno atraso, conhecido como "lag", entre o momento em que a alteração é feita no servidor primário e o momento em que ela é refletida no servidor em espera.

Resumo: A replicação por fluxo no PostgreSQL é assíncrona, o que significa que não há simultaneidade perfeita entre as alterações no servidor primário e no servidor em espera. As mudanças são enviadas em tempo real, mas aplicadas com um pequeno atraso.

Por isso, a alternativa correta é E - errado.

Gostou do comentário? Deixe sua avaliação aqui embaixo!

A afirmação não é inteiramente correta. Na replicação por fluxo (ou **streaming replication**) do PostgreSQL, as alterações **não são simultâneas** no servidor primário (master) e no servidor em espera (standby). Em vez disso, o processo funciona de forma assíncrona ou, em alguns casos, quase síncrona, dependendo da configuração específica.

### Como funciona a replicação por fluxo no PostgreSQL:

- **Servidor Primário (Master):** É o servidor principal onde todas as operações de escrita ocorrem. Quando uma transação é confirmada (committed) no primário, as mudanças são registradas nos arquivos de log de escrita adiantada (WAL - Write-Ahead Logging).

- **Servidor em Espera (Standby):** Este servidor replica os dados do servidor primário. Ele recebe as alterações via WAL transmitido pelo primário e aplica essas mudanças. A replicação pode ser:

- **Assíncrona:** O standby pode estar levemente atrasado em relação ao primário porque ele aplica as mudanças após o commit no primário. Isso pode resultar em uma pequena diferença temporal entre o estado dos dois servidores.

- **Síncrona (quase simultânea):** O primário espera uma confirmação do standby antes de considerar uma transação como concluída. Isso garante que os dados estão em ambos os servidores após o commit, mas pode introduzir latência dependendo da rede e da carga.

### Conclusão:

Portanto, as alterações **não são aplicadas simultaneamente** nos dois servidores. Na replicação assíncrona, o standby pode estar um pouco atrasado. Na replicação síncrona, há uma tentativa de minimizar esse atraso, mas ainda não é exatamente simultâneo, já que o primário precisa esperar a confirmação do standby.

Gab: Errado

Em uma linguagem mais simples.

A replicação por fluxo em um banco de dados é um método que permite copiar e manter dados sincronizados entre diferentes instâncias de banco em tempo real...

Vamos para o ERRO da questão:

O servidor primário é o banco de dados de origem ele tem que fazer uma série de processos até que os dados possam ser enviados para o secundário, logo, não é em tempo real.

Em outras palavras o primário recebe, processa, faz registros, logs e depois envia para o secundário.

Concluindo, na replicação por fluxo do banco de dados PostgreSQL, as alterações realizadas no servidor primário são replicadas quase em tempo real para o servidor em espera.