O que uma réplica realmente é

Uma réplica de leitura é um segundo banco que copia tudo o que o primeiro faz, um pouco depois. As duas metades dessa frase importam, e a segunda é de onde vem todo problema de réplica.

O mecanismo

O primário grava cada mudança num log antes de aplicá-la. No Postgres, esse é o write-ahead log, um registro durável e ordenado de cada modificação.

Uma réplica se conecta ao primário, recebe esse log em fluxo contínuo e o reaplica. Ela não roda as suas queries de novo. Ela aplica as mesmas mudanças, byte a byte, na mesma ordem, e é por isso que uma réplica não consegue ir parar num estado diferente. Ela só consegue ficar atrasada.

flowchart LR
  W["uma escrita chega"] --> P["o primário a aplica"]
  P --> L["e a anexa ao write-ahead log"]
  L --> S["a réplica transmite o log"]
  S --> R["a réplica o reaplica, um pouco depois"]
  R --> B["mesmo estado, alguns milissegundos atrás"]

Uma réplica é somente leitura, e isso é garantido. Uma escrita tentada nela levanta um erro, em vez de divergir em silêncio.

Assíncrona por padrão

O primário não espera a réplica. Ele aplica uma escrita, acrescenta ao log e responde ao cliente. Se a réplica já alcançou ou não, isso não faz parte daquela transação.

Essa é uma troca proposital, e é o padrão certo. A alternativa, a replicação síncrona, em que o primário espera uma confirmação, deixa cada escrita tão lenta quanto a réplica mais lenta e transforma uma queda da réplica numa queda do primário.

O que você ganha com essa velocidade é uma janela em que os dois discordam. Essa janela se chama atraso de replicação, e costuma ser de milissegundos. O "costuma" carrega muito peso nessa frase, e a lição 3 trata do que acontece quando não é assim.

O que uma réplica não é

Ela não é um backup. Um backup é uma cópia de um momento para a qual você pode voltar. Uma réplica aplica tudo, inclusive o DELETE de que você se arrepende, em milissegundos, nas duas máquinas.

Ela não é um shard. O sharding divide os dados para que cada servidor guarde uma parte diferente. Uma réplica guarda tudo, então não faz nada por um banco grande demais para uma máquina. Ela só ajuda quando o problema são leituras demais, e não dados demais.

Ela não é failover automático. Uma réplica pode ser promovida a primário, mas alguma coisa precisa decidir promovê-la, apontar a aplicação para ela e garantir que o primário antigo nunca volte achando que ainda está no comando. Essa maquinaria é separada, e é a parte difícil.

Para que ela serve

Ela faz uma coisa: tira o tráfego de leitura do primário.

Vale dizer isso de forma estreita, porque é comum recorrer a uma réplica como um jeito genérico de "deixar o banco mais rápido". Ela não deixa nenhuma query isolada mais rápida, já que a réplica roda a mesma query nos mesmos dados com o mesmo plano. Ela deixa o primário menos ocupado, e isso deixa mais rápidas as queries que continuam rodando nele.

Pontos-chave

• Uma réplica recebe o write-ahead log do primário e o reaplica. Ela pode estar atrasada, mas nunca diferente.
• A replicação é assíncrona por padrão: o primário responde ao cliente sem esperar a réplica.
• A diferença entre os dois é o atraso de replicação, normalmente de milissegundos.
• Uma réplica não é backup, nem shard, nem failover. Ela aplica os seus erros também, guarda todos os dados e não se promove sozinha.
• Ela não deixa uma query mais rápida. Ela deixa o primário menos ocupado.