Replication: streaming, logical, failover

• → escreve
• → confirma já
• → confirma depois desta

• Compute
• Conceito de arquitetura
• Segurança e identidade

A decisão inteira cabe numa pergunta: você aceita perder as últimas transações confirmadas se o primário morrer agora? Se não aceita, paga a ida e volta em toda escrita — não existe terceira opção.

1. 1 · A replicação reaproveita o registro de durabilidade. O banco já grava toda mudança num registro antes de aplicá-la. A réplica é apenas mais um leitor desse registro — não há mecanismo separado.
2. 2 · Assíncrono é rápido e tem janela de perda. O primário confirma assim que grava localmente. Se ele morrer antes de a réplica receber, aquelas transações confirmadas desaparecem.
3. 3 · Síncrono elimina a perda e cobra latência. A confirmação espera a réplica. Toda escrita passa a custar uma ida e volta de rede — e com réplica em outra região isso é dezenas de milissegundos por transação.
4. 4 · Dá para escolher por transação. Nem tudo precisa da mesma garantia. Confirmação de pagamento pode ser síncrona e registro de auditoria assíncrono, no mesmo banco.
5. 5 · Réplica serve leitura, e leitura fica atrasada. É o ganho de escala mais direto e a origem do "não vejo o que acabei de gravar". A janela é pequena e visível para o usuário.
6. 6 · Promover réplica é decisão, não automatismo. Promover a réplica errada — atrasada — perde dado. E promover duas cria duas verdades. É por isso que a troca automática precisa de árbitro externo, e não de heurística local.