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
- 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.
- 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
- 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.
- 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 ( =
ou
) e para PostgreSQL Streaming Replication (
– 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 (
synchronous_commit = on
/off
com synchronous_standby_names
).