O que podemos entender com evolução do tipo síncrona e assíncrona em uma RP? Dê exemplos de configurações para configurar cada um dos tipos.

Passo 1

O enunciado pergunta sobre “evolução do tipo síncrona e assíncrona em uma RP”, ou seja, sobre os dois modos de replicação de dados (Primary→Replica) em sistemas distribuídos. Vamos entender a diferença conceitual entre ambos e, em seguida, ver exemplos de como configurar cada modo em duas bases populares—SQL Server Always On Availability Groups e PostgreSQL Streaming Replication.

Passo 2

Evolução síncrona significa que, no nó primário, a transação só é considerada confirmada (COMMIT) depois que pelo menos uma réplica secundária reconhece ter recebido e gravado o log de transação. Isso garante zero (ou mínima) perda de dados em caso de falha do primário, porém introduz latência extra pois o primário aguarda confirmação da réplica.

Passo 3

Exemplo de configuração síncrona
  1. SQL Server Always On Availability Group
ALTER AVAILABILITY GROUP [MinhaAG]
MODIFY REPLICA ON N'NoSecundario' 
WITH (
\(AVAILABILITY_MODE\) = \(SYNCHRONOUS_COMMIT\),
\(FAILOVER_MODE\) = AUTOMATIC
);
Aqui definimos que o nó secundário trabalhará em modo de commit síncrono e poderá assumir automaticamente em caso de falha do primário.
  1. PostgreSQL (no primary)
    No arquivo postgresql.conf:
\(synchronous_commit\) = on
\(synchronous_standby_names\) = 'standby1,standby2'
E no recovery.conf (ou postgresql.auto.conf) do standby:
\(primary_conninfo\) = 'host=10.0.0.1 port=5432 user=replicator password=senha'
Com synchronous_standby_names definido, o primary só libera o COMMIT depois de ao menos um standby ACK.

Passo 4

Evolução assíncrona significa que o nó primário confirma o COMMIT local imediatamente, sem esperar qualquer confirmação da réplica. Isso reduz a latência de gravação no primário mas aceita o risco de perder transações não propagadas caso ele falhe.

Passo 5

Exemplo de configuração assíncrona
  1. SQL Server Always On Availability Group
ALTER AVAILABILITY GROUP [MinhaAG]
MODIFY REPLICA ON N'NoSecundario' 
WITH (
\(AVAILABILITY_MODE\) = \(ASYNCHRONOUS_COMMIT\),
\(FAILOVER_MODE\) = MANUAL
);
Aqui o primário faz COMMIT sem aguardar réplica; o failover será manual.
  1. PostgreSQL (no primary)
    No arquivo postgresql.conf:
\(synchronous_commit\) = off
E no standby mantém o mesmo
\(primary_conninfo\) = 'host=10.0.0.1 port=5432 user=replicator password=senha'
Com synchronous_commit = off, o primary não bloqueia o COMMIT para aguardar ACK de standbys.

Resposta

– Em evolução síncrona a réplica secundária confirma gravação antes do COMMIT no primário, garantindo maior segurança de dados.
– Em evolução assíncrona o primário confirma localmente sem esperar réplica, reduzindo latência à custa de risco de perda de dados não propagados.
– Exemplos de configuração foram mostrados para SQL Server Always On ( AVAILABILITY_MODE = SYNCHRONOUS_COMMIT ou ASYNCHRONOUS_COMMIT) e para PostgreSQL Streaming Replication (synchronous_commit = on/off com synchronous_standby_names).

Exercícios relacionados