a. Visão geral

Todos os hands-on até aqui rodaram um único container db. Quando ele para, todo serviço que depende dele para também: ele é um ponto único de falha. Escalar o gateway para três réplicas (hands-on 7) e adicionar um cache (hands-on 8) tirou carga do banco de dados, mas não removeu esse ponto único. Um cluster de banco de dados mantém cópias dos dados em vários servidores, de modo que um deles pode assumir quando outro falha.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Por que um cluster de banco de dados

Escalar as escritas exige outra técnica, o sharding (dividir os dados entre primários independentes, como fazem o Citus ou o Vitess). Este hands-on trata de replicação: cada nó guarda todos os dados.

Como o PostgreSQL replica: o WAL

Antes de alterar uma página de dados, o PostgreSQL grava a alteração no WAL (write-ahead log), um log em disco que só recebe acréscimos (append-only). Depois de um crash, o servidor reexecuta o WAL para se recuperar. A replicação reaproveita o mesmo log: o primário envia o seu WAL às réplicas, que o reexecutam, byte a byte, e terminam com cópias idênticas.

sequenceDiagram
    participant App as Serviço
    participant P as Primário
    participant R1 as Réplica 1
    participant R2 as Réplica 2
    App->>P: INSERT INTO orders ...
    P->>P: acrescenta a alteração ao WAL
    P-->>App: COMMIT ok
    P->>R1: envia registros do WAL (stream)
    P->>R2: envia registros do WAL (stream)
    R1->>R1: reexecuta o WAL
    R2->>R2: reexecuta o WAL
    App->>R1: SELECT * FROM orders
    R1-->>App: linhas (até o último registro reexecutado)

Este hands-on usa replicação física por streaming: a base da alta disponibilidade no PostgreSQL e de serviços gerenciados como o Amazon RDS.

Assíncrona ou síncrona?

A pergunta é quando o primário responde COMMIT ok:

Este é o teorema CAP na prática: a replicação síncrona prefere a consistência (nenhuma escrita confirmada é perdida) e abre mão da disponibilidade das escritas quando a réplica está inacessível; a replicação assíncrona prefere a disponibilidade e aceita que quem lê de uma réplica veja dados desatualizados e que um failover perca as últimas escritas.

Arquitetura

flowchart LR
    app["serviço\n(account, order...)"]
    subgraph cluster [Cluster PostgreSQL]
        p[("pg-primary\n:5432\nleitura e escrita")]
        r1[("pg-replica1\n:5433\nsomente leitura")]
        r2[("pg-replica2\n:5434\nsomente leitura")]
        p e1@-->|"stream do WAL"| r1
        p e2@-->|"stream do WAL"| r2
    end
    app e0@==>|"escritas + leituras"| p
    app e3@-.->|"leituras"| r1
    app e4@-.->|"leituras"| r2
    e0@{ animate: true }
    e1@{ animate: true }
    e2@{ animate: true }

• Os três nós rodam a imagem oficial postgres:17. Um pequeno entrypoint decide o papel: um nó vazio com PRIMARY_HOST clona o primário com pg_basebackup e sobe como hot standby (ele aceita leituras).
• A aplicação decide para onde vai cada consulta. Aqui, o roteamento fica na connection string: a libpq e o driver JDBC do PostgreSQL aceitam uma lista de hosts e escolhem o que tem o papel certo (target_session_attrs / targetServerType).

Failover

Quando o primário falha, uma réplica precisa ser promovida a primário, as outras réplicas precisam segui-la e os clientes precisam encontrá-la. Neste hands-on, você faz cada passo à mão, para ver o que uma ferramenta automática faz por você: